Attackers Sprayed Stolen Microsoft 365 Tokens at 79 Organizations, and a Password Reset Didn't Lock Them Out

Most incident playbooks for a compromised Microsoft 365 account still start with the same move: reset the password and force MFA re-registration. A ten-week campaign documented by Huntress shows why that is no longer enough. The attacker never needed a password at all. It replayed session tokens that victims had earned by passing genuine Microsoft MFA prompts, sprayed them across dozens of tenants from one block of rented servers, and then quietly installed its own devices and authenticators so that the next password reset would change nothing important.

MFA Worked. The Session It Produced Was the Prize

In its October 22 report, Huntress counts 497 successful sign-ins across 79 organizations between July 14 and September 22, set against more than 200,000 failed attempts. Most tokens were captured through adversary-in-the-middle relays: fake sign-in pages that passed the real Microsoft login and MFA challenge through to the victim, then kept the session token Microsoft issued at the end. As the researchers put it, "Because that token is minted after MFA, whoever holds it doesn't need to pass MFA again." Other tokens came from device-code phishing, where the victim types a code into Microsoft's own sign-in page and unknowingly approves an attacker's session, and from social engineering during ordinary logins.

Huntress calls the replay pattern token spraying, which Help Net Security summarises as the same pattern as password spraying with stolen tokens in place of guessed passwords. The replays came from servers at 1337 Services GmbH, a Hamburg hosting provider, and the attacker rotated among six addresses in a single /24 range across four phases with gaps of a week or two, so blocking any one address would have stopped at most one phase. Speed improved as the campaign went on: on July 21 a hijacked session appeared 12 minutes after the victim reached the MFA prompt, and on September 22 the gap was four minutes.

What Stays Behind After the Reset

The persistence is the part that should change response procedures. Huntress found at least 48 rogue computers registered in victims' Entra directories, named "DESKTOP-" followed by eight hexadecimal characters, and a registered device stays until someone deletes it. In 19 organizations the attacker wiped the existing MFA methods and registered its own within three hours of the first sign-in from a campaign address. In one July case, an authenticator labelled "iPhone 13" was activated less than an hour after the session was hijacked. A password reset alone, the researchers warn, leaves all of that in place.

Inside the mailboxes, the attacker set inbox rules with names such as ".", "sss" and "iT" that deleted mail or marked it read and moved it into RSS Feeds and Conversation History. Cyber Security News reports that one compromised account sent a payroll-related email to an external accountant, and Help Net Security describes how the attacker then edited a rule to catch messages mentioning payroll, direct deposit, bank or bonus, and five minutes later hid all mail from that accountant. That is the classic setup for payment fraud, run from a mailbox the owner still believed was theirs.

The Control That Actually Held

On September 11 the attacker moved to a new address and ran an automated program that reused captured tokens, producing hundreds of successful sign-ins at nearly 30 organizations over four days. That same address was blocked 1,052 times, all at four organizations whose Conditional Access policies refused the sign-ins. Huntress is blunt about the lesson: token replay "can be prevented with properly implemented Conditional Access Policies," and it advises treating error AADSTS53003, a valid credential stopped by policy, as a warning rather than a sign the attack failed.

Microsoft's own guidance points the same way. Its documentation on blocking authentication flows recommends that organizations get as close as possible to a unilateral block on device code flow, allowing it only for documented cases such as legacy tooling. Its token protection control goes further, accepting only sign-in session tokens cryptographically bound to a registered device, so a stolen token cannot be used elsewhere. It is generally available for native apps on Windows, but limited to Exchange Online, SharePoint Online and Teams for native applications, and Microsoft advises piloting it in report-only mode first.

What to Do This Week

• Rewrite the compromised-account runbook. Revoke all sessions, reset the password, then remove every device and MFA method the user cannot vouch for, and review inbox rules. Treat a reset without those steps as incomplete.
• Audit Entra for rogue devices now. Search for recently registered devices named "DESKTOP-" plus eight hex characters, and for MFA methods added shortly after a sign-in from hosting infrastructure.
• Block device code flow. Run Microsoft's authentication-flows policy in report-only mode, confirm who genuinely uses it, then block it for everyone else with narrow, documented exceptions.
• Close Conditional Access gaps. Huntress recommends policies covering all users, all cloud apps and all client app types. Look for exclusions and legacy clients that leave a token usable from an unknown host.
• Pilot token protection. Start with privileged users and finance staff on supported Windows devices, where binding sessions to hardware removes the value of a stolen token.
• Investigate blocks, not just successes. A burst of AADSTS53003 errors means someone holds a working credential for that user. Respond as if the account is compromised, because elsewhere it probably is.

Nothing in this campaign defeated MFA cryptographically, and nothing required a zero-day. It worked because a signed-in session is worth as much as the person who earned it, and because most response playbooks still assume the password is what needs changing. The four organizations that blocked 1,052 replays did not detect the attacker faster than anyone else. Their policy simply refused a valid token from the wrong place, and that is the posture worth copying before the next wave arrives.