A stolen Microsoft 365 session token lets an attacker sign in without a password or a second factor, and the access can outlast a password reset. Huntress tracked a ten-week campaign, from 14 July to 22 September 2026, that replayed such tokens at 79 organizations and named the pattern token spraying, after password spraying.

The sign-in was the start of the attack, not the loss. The money-making steps ran through the mailbox: inbox rules that deleted or hid mail, and in one case a payroll email to an outside accountant with a second rule to bury the replies.

How does email account takeover work when a stolen session token skips MFA?

A session token is issued only after a user has entered a password and completed MFA. Whoever holds it has already satisfied both checks, so a replayed token produces a sign-in that looks like a continuation of a verified session. Huntress calls this token spraying: many stolen tokens replayed across many organizations, the way password spraying tries one guessed password across many accounts.

Huntress names three ways the tokens were obtained and gives no breakdown between them.

The pace is the point. Huntress documented one relay on 21 July in which the hijacked session appeared 12 minutes after the victim reached the MFA prompt, and a case on 22 September that took 4 minutes.

Replay came from six addresses in one range, in four phases

The replay traffic came from six addresses in 193.26.115.0/24, hosted by 1337 Services GmbH (AS210558), a provider incorporated in Hamburg. Huntress notes the provider offers legitimate hosting and that attackers rent such space, an approach it abbreviates as BYOIP. The addresses were used one after another, and Huntress says it cannot state why the operator rotated them.

The four phases

Blocking the /24 would have covered all six main replay hosts, but Huntress says the operator also used a few other 1337 Services addresses outside it, and that blocking any single address would have stopped one phase at most. Blocking the relay does not stop replay of tokens already stolen.

What did the attacker do inside the mailbox after the replay?

A stolen token eventually expires, so the attacker worked to outlast it and then to profit. Huntress found three persistence methods: rogue devices, replaced MFA methods and hidden inbox rules.

Devices and authenticators

At least 48 rogue devices were registered in victims' Entra directories, named "DESKTOP-" followed by eight uppercase hexadecimal characters, a pattern that differs from the seven-character default Windows names. The first detection was a sign-in on 14 July from a device with such a name (MITRE T1098.005).

In 19 organizations the attacker cleared the existing MFA methods and registered a new authenticator within three hours of the first campaign sign-in (MITRE T1556.006).

Inbox rules that hide mail

Every suspicious rule Huntress saw was created from a VPN or rented hosting address, never from the 1337 Services range. In four mailboxes the rules were created through the Outlook REST API rather than Outlook itself, and two were created within minutes of the first campaign sign-in (MITRE T1564.008).

The payroll case

In one mailbox the attacker sent a payroll-related email to an external accountant's address. A rule named s hid any message mentioning payroll, direct deposit, bank or bonus, and about five minutes later a second rule, d, moved all mail from that accountant to Conversation History and marked it read. The victim never saw the replies. The email's content is not described. In a separate mailbox, a rule named sss deleted all mail while the account was used to send spam to hundreds of external recipients, until Entra ID Protection rated the account high risk.

Why do password resets and MFA not remove the attacker?

A reset changes one credential. Huntress states that a password reset alone does not remove attacker-registered devices or MFA methods, and does not invalidate the access token, which it puts at roughly 90 minutes of life. The refresh token and session cookie expire, but the access token stays valid until the identity sessions are revoked or disabled.

Revocation does work when it is used. Replays of sessions that had been revoked failed with error AADSTS50133 (SsoArtifactRevoked), including a retry of the same stolen session three times from three addresses in August. Microsoft's documentation describes continuous access evaluation as enforcing session revocation in near real time after events such as a password reset, for supported clients and services (Microsoft Learn). Neither mechanism removes a registered device or an authenticator the attacker added.

Sign-in-time controls also see only the sign-in. The rules that hide fraud are created after it, sometimes through an API, from addresses that never appear in the replay range. Only a control that watches the mailbox itself sees the new rule and the message that was never meant to be answered.

Where Conditional Access stopped the campaign

On the 11 September burst, Conditional Access policies blocked the campaign address 1,052 times across four organizations. The organizations without such a policy were compromised. Huntress advises requiring MFA, or blocking access, for all users, all cloud apps and all client app types, unconditionally.

It also warns against reading a block as a win. Error AADSTS53003 (blocked by Conditional Access) fires after authentication succeeds, so it indicates a valid credential. Ranking tenants by failed attempts would have pointed responders at the four where the policy was already working, and away from the organizations being compromised.

Two Microsoft controls address the token itself. Token protection binds sign-in session tokens to a registered device, so a stolen token cannot be used from another device, but its documented coverage is native applications for Exchange Online, SharePoint Online and Teams on supported platforms, with browser support limited to selected web apps (Microsoft Learn). One of the two replay builds Huntress observed used a browser session against OfficeHome. For device code phishing, an authentication flows policy can restrict the flow, and Microsoft recommends blocking it wherever possible (Microsoft Learn).

How AegisAI protects against it

The lure emails were not published, so how the victims were reached is not known. For the email-borne routes, the relay and device code lures, the approach below applies.

AegisAI's agents evaluate the message and the destination it points to together, and pull a malicious message out of mailboxes before users see or click it.

When a lure or a compromised session is caught, the response compounds: the message is withheld at classification, copies already delivered are retracted, rewritten links refuse a late visit, the account's outbound and internal mail gets rescanned, and lateral phishing attempts to colleagues are blocked at the same bar rather than treated as a fresh, unrelated message.

More on how that works: inbound email security.

What the reporting does not tell us

Delivery. Huntress does not publish the lure emails, subject lines or sender domains used to reach victims, so detection of the first message cannot be built from this report.

Token sources. Huntress names three routes and gives no split between them.

Counts. Two sections of the report give different totals for the 11 September burst, 303 successful sign-ins across 29 organizations in one and 232 across 28 in the other, and the report does not reconcile them. The 79 organizations are described as related incidents, and Huntress does not say how many were its customers.

Attribution. No threat actor is named, and the operator's reason for rotating addresses is not known.

MITRE ATT&CK mapping

Recommendations for defenders

FAQ

References