Microsoft 365 token spraying compromises 79 organisations across 70 days without passwords

Adversaries replay 200,497 stolen tokens across 70 days to breach 79 organisations without passwords

Across a 70-day operational window between 14 July and 22 September 2026 (10.0 weeks, derived), an automated identity-replay campaign compromised 79 distinct enterprise organisations by spraying 200,497 stolen session tokens against Microsoft 365 cloud tenants. Disclosed by cybersecurity firm Huntress, the threat actor achieved 497 successful session infiltrations at a conversion efficiency of 0.25 percent (derived) without entering credentials, cracking passwords, or triggering multi-factor authentication (MFA) prompts. The adversary executed automated spray sweeps at an average tempo of 2,864 replay attempts daily (derived), systematically converting infostealer telemetry into persistent enterprise footholds.

The campaign targeted Microsoft Entra ID (formerly Azure Active Directory) OAuth 2.0 refresh and access tokens harvested from compromised endpoints by commercial commodity infostealers, including Lumma, RedLine, and Vidar. Because these tokens represent pre-authenticated sessions that already satisfied conditional access and biometric or hardware MFA challenges during original user sign-ins, replaying them bypassed traditional frontline identity controls entirely. Within minutes of establishing an authenticated connection, adversaries registered rogue managed devices and created covert inbox routing rules to intercept sensitive executive communications.

Audit of verified threat intelligence versus identity operational assumptions

To determine the practical blast radius and defense requirements across Microsoft 365 environments, security teams must separate verified telemetry from speculative assumptions regarding cloud identity resilience.

Audit of verified technical disclosures for the Huntress M365 token spraying campaign versus operational assumptions

Operational Dimension	Explicitly Verified in Threat Intelligence	Unverified or Dependent on Tenant Architecture
Attack Vector	Automated replay of valid, pre-authenticated OAuth refresh and access tokens harvested by infostealers.	Direct cryptographic compromise or structural vulnerability in Microsoft Entra ID infrastructure.
Credential Usage	Zero passwords cracked, entered, or required to achieve authenticated cloud session states.	Whether affected users shared master credentials across enterprise and personal home endpoints.
MFA Interaction	100 percent bypass of multi-factor authentication because token claims already satisfied MFA prerequisites.	Whether FIDO2 WebAuthn keys would have prevented initial harvesting on infected unmanaged personal machines.
Persistence Mechanism	Immediate registration of rogue Entra ID devices and hidden Outlook mailbox forwarding rules.	The total volume of sensitive intellectual property or financial data exfiltrated prior to session revocation.
Attacker Infrastructure	Primary spray infrastructure concentrated within German autonomous system AS210558 (1337 Services GmbH).	Conclusive nation-state or eCrime cartel attribution for the overarching campaign coordination.

The friendly-name fallacy: why 'MFA enforced' breeds false security

The success of this 70-day campaign exposes a dangerous friendly-name fallacy in enterprise identity governance: the assumption that enforcing multi-factor authentication guarantees tenant invulnerability. Security executives frequently treat MFA as a permanent defensive perimeter, ignoring the fundamental architecture of modern cloud authentication. In federated OAuth and OpenID Connect protocols, multi-factor challenges are evaluated solely during initial authentication to mint signed session tokens. Once issued, those tokens act as bearer credentials.

Bearer tokens inherently lack binding to the underlying physical device unless explicit token protection is enforced. When an employee downloads malicious material or encounters malvertising on an unmanaged personal device, infostealer malware extracts cached browser session tokens, cookies, and local database records. Threat actors aggregate these credentials on underground distribution channels. Automated bots subsequently spray the stolen tokens against cloud endpoints. As demonstrated by the 1 successful breach per 403.4 tokens sprayed (derived), adversaries need only a fraction of unexpired tokens to breach corporate perimeters.

Zoom

As detailed in the architecture diagram, the operational sequence following successful token replay is swift and programmatic. Within minutes of establishing an authenticated Graph API or portal session, the adversary's tooling registers an unauthorized rogue device into Microsoft Entra ID. This device registration grants the attacker an enterprise identity anchor, enabling subsequent access requests to mimic compliant endpoints. Simultaneously, the attackers inject automated Outlook mailbox rules designed to mark incoming security alerts as read and move them directly to the Deleted Items or Archive folders.

Remediation engineering: terminating live sessions and binding tokens

Remediating token replay attacks requires moving beyond password resets. Resetting an Active Directory or Entra ID password does not invalidate issued OAuth refresh tokens in standard configurations. Security teams responding to active compromise must explicitly revoke all active refresh tokens and user sessions across the tenant:

# Connect to Microsoft Graph with Identity and Device Governance scopes
Connect-MgGraph -Scopes 'User.ReadWrite.All', 'Device.ReadWrite.All'

# Revoke all active OAuth refresh tokens and invalidate current sessions
Revoke-MgUserSignInSession -UserId 'compromised.user@organisation.co.uk'

# Audit user registered devices for anomalous registrations from AS210558
Get-MgUserOwnedDevice -UserId 'compromised.user@organisation.co.uk'

# Evict rogue device registration by device ID
Remove-MgDevice -DeviceId '11112222-3333-4444-5555-666677778888'

To achieve systemic resilience against token replay, organisations must transition from static bearer tokens to cryptographically bound tokens. Microsoft Entra ID Token Protection (proof-of-possession) binds refresh tokens and access tokens to the client device's Trusted Platform Module (TPM). Even if infostealer malware extracts the token payload from the browser cache, an adversary attempting to replay the token from an external server (such as AS210558) fails because they lack the private key stored inside the hardware TPM.

UK regulatory governance and cloud identity oversight obligations

For UK enterprises, critical national infrastructure operators, and public sector bodies, token replay attacks intersect directly with legal and regulatory mandates. Under the UK National Cyber Security Centre (NCSC) Cloud Security Principles (specifically Principle 2: Asset Protection and Resilience, and Principle 9: Secure User Management), organisations are required to maintain strict controls over cloud credential lifecycles and verify that authentication tokens cannot be replayed from untrusted network perimeters.

Under Cyber Essentials Requirements for IT Infrastructure v3.3, multi-factor authentication is mandatory for all cloud services. However, technical assessors are increasingly auditing whether implementations address session hijacking risks. When an organisation suffers unauthorized data access due to the replay of unrevoked tokens from unmanaged endpoints, reliance on a basic push MFA implementation fails to satisfy regulatory standards of technical due diligence.

Furthermore, under the UK Data Protection Act 2018 and UK GDPR Article 32, data controllers bear an affirmative duty to implement appropriate technical measures to prevent unauthorized disclosure of personal data. The deployment of hidden mailbox rules to covertly siphon corporate communications represents a reportable personal data breach under Article 33. Organisations that fail to detect persistent session hijacking face formal investigation and financial sanctions from the Information Commissioner's Office (ICO).

Defender checklist: neutralizing token spraying and session hijacking

The exposing question

If a cyber adversary purchases a valid OAuth refresh token stolen from an employee's personal computer this morning, what technical control in your cloud tenant prevents them from accessing your corporate mailboxes this afternoon without entering a single password or prompting an MFA alert?

Key facts