Huntress reported that attackers compromised 97 Microsoft 365 accounts across 79 organizations during activity observed from July 14 to September 22, 2026. The campaign’s reported methods included replaying stolen sign-in tokens, changing authentication methods and adding mailbox rules.
What Huntress reported about the campaign
Huntress counted 497 successful sign-in events and more than 200,000 login attempts across the affected organizations. Those are separate measures: the account total was 97, and the organization total was 79.
How a stolen token can keep a session open
A session token is proof that a user has already signed in, which an app can accept to continue that session. Huntress reported that attackers used an adversary-in-the-middle relay, a fake sign-in page that passes a victim’s credentials and multifactor authentication (MFA) codes to Microsoft. After the user completed sign-in, the attacker captured and replayed the resulting token from an attacker-controlled device. Because the token represented an already authenticated session, replay could avoid a new MFA challenge.
Huntress also identified device-code phishing and social engineering during legitimate sign-ins as other ways tokens were obtained. It called large-scale replay across organizations “token spraying.”
The reported persistence reached MFA settings and inboxes
Huntress reported 48 unauthorized Microsoft Entra device registrations. In at least 19 organizations, attackers reportedly removed existing MFA methods and registered a new method within three hours of the first sign-in. In one case on July 21, an authenticator labeled “iPhone 13” was activated less than 51 minutes after a session was hijacked.
The reported mailbox changes included hidden rules that deleted or diverted messages about payroll, deposits or bonuses. In one mailbox, a rule marked all incoming messages as read and deleted them. The account was then used to send spam to hundreds of recipients before Entra ID Protection rated it high risk.
What Microsoft Token Protection covers
Microsoft’s Conditional Access Token Protection binds supported refresh tokens cryptographically to a device. The inspected Microsoft guidance requires a Primary Refresh Token (PRT) and describes support for Windows native applications connecting to Teams, SharePoint and Exchange. Unregistered devices without a PRT fall outside that described scenario. Token Protection therefore does not cover every device, app or sign-in path.
Microsoft recommends layering controls around that protection: harden managed devices, use Conditional Access to require compliant devices, monitor identity and endpoint risk, and apply network controls where Token Protection does not cover an application or identity. Microsoft also recommends allowing device-code flow only when necessary and blocking it wherever possible, since the flow can be abused for phishing or access from unmanaged devices. The relevant controls have different licensing requirements.
A 2024 Microsoft Mechanics explainer covers token theft and includes a walkthrough of Token Protection configuration.
Which sign-in details can help with triage?
A location mismatch alone does not diagnose token theft. A Spiceworks forum responder suggested checking the sign-in’s Authentication Details to see whether MFA was newly challenged or had already been satisfied, then comparing the device ID with a known device. Microsoft also lists “Anomalous Token,” “Attacker in the Middle” and “Unfamiliar sign-in properties” among its identity-risk detections.
For a suspected compromise, Huntress recommended revoking sessions, resetting passwords, auditing Entra device registrations and authentication methods, and reviewing unexpected inbox rules and enterprise applications. Huntress also recommended restricting device-code flow through Conditional Access. Microsoft’s guidance on protecting tokens describes the protection’s scope and additional controls.
