Secretus logo
newsmicrosoft-365token-replayaitm

Microsoft 365 Token Spraying: 79 Organisations Where MFA Was Passed Once and the Session Reused

Huntress describes a campaign that captured Microsoft 365 sessions and replayed the tokens from hosting infrastructure, then added its own authenticator and rogue devices. A password reset alone does not end it.

·8 min read·Secretus Editorial

The sign-in worked exactly as designed. The victim passed MFA; a stranger got the session that came out of it. Huntress reports a campaign it calls token spraying, observed from 14 July to 22 September, in which stolen Microsoft 365 authentication tokens were replayed from hosting infrastructure to break into business email accounts at 79 organisations.

Because the tokens are issued after MFA, replaying one does not trigger another MFA prompt. That is the whole trick, and it changes what recovery has to include.

What Huntress reports

Huntress counts 497 successful Microsoft 365 sign-ins against more than 200,000 failed attempts across the 79 organisations. The Hacker News's headline puts 97 accounts compromised; Huntress's own post, as we read it, gives organisation and sign-in counts and no separate account count, so treat 97 as a single-source figure.

  • How tokens were obtained. Adversary-in-the-middle login pages that relay credentials and MFA to the real sign-in and keep the resulting session; device-code phishing, where the victim enters a code on Microsoft's genuine page and hands over valid tokens; and social engineering during legitimate sign-ins.
  • How replay worked. The attacker replayed stolen sessions from hosting infrastructure, sometimes within minutes of capture (Huntress cites cases of four and twelve minutes). Replay came from six addresses in a block owned by a German hosting provider. Conditional Access blocked some attempts: one address logged 1,052 blocked sign-ins, all against four organisations.
  • Persistence. The attacker registered their own authenticator app, which survives a password reset. In 19 organisations existing MFA methods were removed and replaced, often within three hours of the first sign-in. At least 48 rogue devices with names in a “DESKTOP-” pattern were registered in Entra, giving a more durable way to request new tokens.
  • Hiding. Inbox rules with forgettable names such as “sss” or “d” moved or deleted mail about payroll, deposits and bonuses, sometimes into obscure folders. Four mailboxes had rules created through the Outlook REST API.
  • One concrete outcome. In one case the attacker emailed a payroll request to an outside accountant and set a rule to hide the replies.

What is not known

  • The operator. Huntress does not identify them and says it cannot state with certainty why they rotated addresses.
  • The full objective and what data was read. The observed actions point at payroll fraud, but Huntress does not describe a full account of data access.
  • Which controls would have stopped it. The report does not discuss token protection, so we cannot say whether it would have blocked these replays. Conditional Access stopped some attempts but not all.
  • Internal counts. Huntress's figures for the later phase differ between two sections of its post, so we have not used them.

Why a password reset is not enough

Huntress states it plainly: a reset alone leaves attacker-registered devices and MFA methods in place, and does not invalidate access tokens. A stolen session stays valid until it expires or is revoked. An attacker-added authenticator lets them sign in again after you think the account is clean, and a rogue device lets them request fresh tokens.

What to do

  1. Revoke sessions first, then reset the password. Both, in that order, for any account you suspect.
  2. Audit MFA methods. Look for authenticators nobody on the user's side added, and for accounts whose methods were removed and replaced in a short window.
  3. Audit Entra devices. Review recently registered devices, particularly “DESKTOP-” names you cannot match to a person. Huntress notes the pattern is rare but not unique, so confirm before deleting.
  4. Review inbox rules and forwarding on affected mailboxes, including rules created through the API, and any new enterprise applications or consent grants.
  5. Restrict the device-code flow with Conditional Access authentication-flow policies unless you need it.
  6. Close Conditional Access gaps. Require MFA or block for all users, all cloud apps and all client app types, without exceptions. Huntress also suggests ranking responses by credential validity rather than by spray volume.
  7. Move to controls bound to the device or the real site, such as passkeys or hardware keys and, where your licensing supports it, token protection. These are our recommendation, not Huntress's: they address the relay step that this campaign relied on.
  8. Check what a mailbox could hold. Search compromised mailboxes for passwords and keys people emailed, and rotate those.

The step after recovery

Recovering an account means handing the user a new credential or recovery code. If that value goes through the same mailbox, the attacker, who may still have a rule or session there, can read it. Deliver it over a channel that does not depend on the account under suspicion, once, to one person.

Where Secretus fits, and where it does not

Secretus covers that last step: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Send the link and the context by separate channels for anything sensitive.

It is not an identity or email security product. It cannot revoke sessions, remove a rogue device, block device-code phishing or tell you whether your tenant was among the 79. Use Microsoft Entra and your security tooling for that, and a one-time link for the moment one person gives another a recovery credential.

Sources