Stealing the session instead of the password
Huntress disclosed a campaign in which an attacker replayed stolen Microsoft 365 session tokens across 79 organizations between July 14 and September 22, logging 497 successful sign-ins against more than 200,000 failed attempts. The researchers' own framing is the detail worth sitting with: the Microsoft accounts were compromised without the attacker ever needing a password, because the thing being stolen was not a credential at all. It was the token a session receives after a user has already typed their password and already completed MFA.
This is the structural weakness every organization that treats MFA as the finish line needs to internalize. MFA proves identity at the moment of login. It says nothing about whether the token issued after that moment gets stolen five minutes later by a phishing page sitting between the user and the real Microsoft login, relaying every step convincingly enough that the user never notices anything happened beyond a normal sign-in.
The mechanics of adversary-in-the-middle at scale
The tokens came from adversary-in-the-middle phishing pages that relay the genuine Microsoft sign-in flow, including the MFA prompt, so the victim completes an authentic-looking login while the attacker's infrastructure captures the session token issued at the end of it. Other tokens arrived through device-code phishing and plain social engineering. Once captured, tokens were used within minutes in some cases. In one documented instance from July 21, a hijacked session surfaced just 12 minutes after the victim reached the MFA prompt.
Huntress describes the bulk reuse pattern as token spraying, the direct descendant of password spraying but built around stolen tokens instead of guessed credentials. The attacker rotated among six IP addresses within a single address block across four distinct phases of the campaign, which meant that blocking any one address only interrupted that phase rather than the operation as a whole, a detail that should inform how any security team scopes its own IP-blocking response.
Persistence that outlives a password reset
Once inside, the attacker registered at least 48 rogue devices in victims' Entra directories, all named with a DESKTOP- prefix designed to blend into a normal corporate device inventory. In 19 of the 79 organizations, existing MFA methods were removed and a new one added within three hours of the initial token theft, and in one case a new authenticator was registered less than an hour after the session was first hijacked.
This is the part that should concern any CTO more than the initial breach itself: a registered device and a newly added MFA method are both durable credentials that survive a password reset untouched. An IT team that resets a compromised user's password and considers the incident closed has left the attacker's own authenticator sitting active in that user's account, ready to authenticate again the next time it is convenient for them to come back.
Hiding in plain sight inside the victim's own inbox
The attacker used inbox rules with deliberately unremarkable names, a period, three letters, two letters, to delete incoming mail or mark it read and move it out of the folders a victim would normally check. In one case, after sending a payroll-related message to an external accountant from the compromised account, the attacker added a rule specifically to catch any reply from that accountant and a second rule hiding all mail from that contact entirely, suppressing the exact conversation a fraud attempt depends on staying invisible.
That level of operational discipline, building bespoke mail-hiding rules around a specific social-engineering attempt in progress, indicates a human operator managing each compromised mailbox individually rather than a fully automated script running blind. Security teams scanning for generic indicators of compromise will miss this kind of tailored rule unless they are specifically auditing inbox rule names and targets rather than just looking for known-malicious rule signatures, and most mail security products are tuned to catch the latter, not the deliberately unremarkable naming this attacker favored throughout the campaign.
Why Conditional Access, not just MFA, is the control that worked
Huntress's own data shows which defense actually interrupted the campaign in practice: four organizations blocked one of the attacker's IP addresses 1,052 times through Conditional Access policies that evaluate sign-in risk signals rather than just confirming MFA was completed. That volume of blocked attempts against a single address shows the attacker kept retrying against organizations whose policies were tuned to catch anomalous sign-in patterns, and kept failing specifically because those policies did not stop at MFA completion.
The lesson generalizes past this one campaign. MFA answers whether someone entered the right second factor at login. Conditional Access, configured to evaluate device compliance, sign-in location, and risk scoring continuously, is what catches a token being replayed from unfamiliar infrastructure after the fact. Organizations running MFA without a correspondingly tuned Conditional Access policy are defending against last decade's credential-stuffing attack while this campaign's token-replay technique walks past them entirely.
What this changes in the next security roadmap
For a CIO or CISO setting next quarter's identity security priorities, this campaign argues for three concrete additions: Conditional Access policies tuned to sign-in risk rather than MFA completion alone, a recurring audit of registered devices and MFA methods rather than a one-time cleanup after an incident, and inbox rule monitoring that flags unusual rule names or targets regardless of whether they match a known malicious pattern. Each of these addresses a specific step in the chain Huntress documented, from initial token theft through weeks of quiet persistence inside a victim's mailbox, and skipping any one of them leaves that same chain intact for the next attacker who tries it.
None of these require new tooling spend for an organization already running Microsoft 365 and Entra ID, since the capability exists inside licenses most enterprises already hold and in many cases sits disabled or loosely configured by default. What is missing in most environments is the operational habit of actually reviewing devices, authenticators, and inbox rules on a schedule rather than only after a breach forces the question, and this campaign is a direct demonstration of how long an attacker can live inside an account, registering their own authenticator and quietly redirecting mail, before that review habit finally catches up to them.
