Microsoft 365 Token-Replay Campaign Compromises 97 Accounts Across 79 Organizations, Exposing MFA Security Gaps
A large-scale identity attack campaign targeting Microsoft 365 has compromised 97 accounts across 79 organizations, demonstrating how cybercriminals can bypass conventional multifactor authentication (MFA) protections by stealing and replaying legitimate authentication tokens.
Cybersecurity researchers at Huntress identified the campaign after investigating suspicious Microsoft 365 authentication activity between July 14 and September 22, 2026. During that period, attackers generated more than 200,000 login attempts, resulting in 497 successful sign-in events and the registration of 48 unauthorized devices in victims' Microsoft Entra ID environments.
Rather than relying primarily on password guessing, the attackers used stolen authentication tokens to impersonate legitimate users. The technique, described by Huntress as token spraying, allowed them to reuse authenticated sessions across multiple organizations, access corporate mailboxes, and establish additional persistence mechanisms.
The campaign illustrates a fundamental weakness in traditional identity security strategies: successfully completing MFA does not guarantee that the resulting authenticated session remains under the legitimate user's control.
Once attackers obtain a reusable session token, they may be able to access protected services without repeating the original authentication challenge. This creates opportunities for account takeover even in organizations that have deployed MFA across their workforce.
How Token Spraying Turns Stolen Sessions Into Account Takeovers
Token spraying differs from conventional password spraying in both its initial requirements and its method of accessing targeted accounts.
Password spraying involves testing a small number of commonly used passwords against multiple accounts, often to avoid triggering account lockout mechanisms. Token spraying instead relies on authentication material that has already been issued during a legitimate or attacker-mediated sign-in.
In the observed campaign, attackers collected tokens through several methods, including adversary-in-the-middle (AitM) phishing pages, device-code phishing, and social engineering during legitimate authentication workflows.
AitM phishing infrastructure acts as an intermediary between a victim and the genuine Microsoft sign-in service. When the victim enters credentials and completes an MFA challenge, the phishing system relays those interactions to Microsoft while capturing authentication material generated during the process.
The attacker can subsequently attempt to reuse the stolen session token from a separate device or network location.
This is particularly dangerous because the token represents a session that has already passed authentication. Depending on the token type, its validity, and the organization's access policies, Microsoft 365 services may accept the token without requiring the user to complete MFA again.
Huntress observed attackers replaying stolen tokens within minutes of obtaining them, using automated authentication attempts to identify which tokens remained usable.
The activity generated more than 200,000 failed login attempts originating from the IP range 193.26.115[.]0/24, demonstrating the scale of the attackers' infrastructure and their willingness to test authentication material repeatedly.
However, those failed attempts should not be confused with the number of compromised accounts. Huntress documented 497 successful sign-in events, which ultimately involved 97 compromised accounts across 79 organizations.
The difference between authentication attempts, successful sign-ins, and distinct compromised accounts is important when evaluating the scope of an identity-based campaign.
Attackers Exploit the Gap Between MFA and Session Security
Multifactor authentication is one of the most effective controls for reducing account compromise caused by stolen passwords. However, its effectiveness depends on the authentication method and the protections applied to sessions after login.
Traditional MFA methods, including one-time passcodes and push notifications, can be vulnerable to sophisticated phishing workflows that relay authentication challenges in real time.
An attacker operating an AitM phishing page does not necessarily need to know or predict the victim's MFA code. Instead, the attacker can forward the challenge to the legitimate user and capture the authenticated session once the process succeeds.
This changes the security problem from credential theft to session hijacking.
A stolen password may be insufficient to access an account protected by MFA. A stolen session token, however, may already carry evidence that the required authentication steps were completed.
Huntress found that the attackers exploited this distinction to access Microsoft 365 services without repeatedly interacting with the original victims.
The campaign also demonstrates why the phrase MFA bypass requires technical precision. The attackers did not necessarily break Microsoft's cryptographic authentication mechanisms or defeat every available MFA method.
Instead, they exploited phishing-susceptible authentication workflows and the subsequent reuse of valid authentication material.
Phishing-resistant authentication methods, including appropriately deployed FIDO2 security keys and passkeys, can substantially reduce exposure to conventional AitM credential-relay attacks because authentication is bound to the legitimate service origin.
Nevertheless, organizations must also consider token protection, device trust, session revocation, and the possibility of authentication material being stolen through other mechanisms.
Rogue Authenticator Apps Provide Persistence Beyond Stolen Tokens
After obtaining access to compromised accounts, the attackers frequently attempted to establish persistence by registering their own authentication methods.
This step is especially significant because stolen session tokens have limited lifetimes and may eventually expire or be revoked.
By adding an attacker-controlled authenticator application to a victim's account, the adversary can potentially complete future MFA challenges without needing continued access to the original session.
Huntress observed that attackers removed existing MFA methods and registered replacements within three hours of the initial compromise at no fewer than 19 organizations.
In one incident on July 21, 2026, the attackers registered a new authenticator application labeled iPhone 13 less than 51 minutes after hijacking a session.
The rapid sequence suggests that persistence was an operational priority rather than an occasional post-compromise action.
It also demonstrates how quickly an account takeover can evolve. A security team investigating suspicious authentication activity several hours later may discover that the attacker has already modified the account's authentication configuration.
Simply resetting the password may not be sufficient if unauthorized authentication methods remain registered.
For effective recovery, administrators must review the complete authentication configuration, revoke active sessions, and remove any methods that the legitimate user did not authorize.
The incident also highlights the importance of monitoring changes to MFA registration, particularly when they occur shortly after suspicious sign-ins or originate from unfamiliar locations.
Unauthorized Entra Devices Extend Attacker Access
The campaign included another persistence technique involving the registration of unauthorized devices in victims' Microsoft Entra ID directories.
Huntress documented at least 48 rogue devices added across affected organizations.
Registering a device can provide an attacker with additional opportunities to obtain authentication tokens and interact with organizational resources, depending on the tenant's device registration and Conditional Access configuration.
Unlike a stolen session token, which may expire or become invalid after revocation, an unauthorized device registration can remain present in the directory until administrators identify and remove it.
This creates a potentially longer-lasting foothold within the identity environment.
The technique is particularly concerning in organizations where device registration is insufficiently restricted or where access policies treat registered devices as more trustworthy than unmanaged endpoints.
However, registration alone does not necessarily mean that a device satisfies every compliance or device-trust requirement. Microsoft Entra distinguishes between registered, joined, and compliant devices, and the privileges available to each depend on organizational policies.
The attackers' use of rogue registrations nevertheless demonstrates why identity incident response must extend beyond user accounts.
Administrators should investigate unfamiliar devices, their registration timestamps, associated users, and subsequent authentication activity.
A compromised identity can become significantly harder to secure if attackers are allowed to modify both authentication methods and device records.
Hidden Inbox Rules Turn Account Access Into Business Email Compromise
The attackers did not limit their activity to obtaining valid sessions and maintaining access. Huntress also observed modifications to mailbox rules designed to conceal communications and interfere with legitimate business processes.
In several compromised accounts, the attackers created inbox rules with deliberately inconspicuous names, including ., sss, ss, iT, ,., ........, s, and d.
These rules automatically moved messages into folders such as RSS Feeds, RSS Subscriptions, and Conversation History. Some marked messages as read, while others deleted incoming mail entirely.
The behavior was especially concerning when the rules targeted messages containing financial terminology, including payroll, direct deposit, banking information, and bonuses.
By hiding specific messages, attackers could potentially prevent employees from noticing suspicious financial communications or responses from business partners.
In one documented incident, the attackers accessed a compromised mailbox and sent a payroll-related message to an external certified public accountant.
They subsequently configured rules to conceal messages associated with the accountant and financial topics. This could interfere with the legitimate account owner's ability to identify unauthorized communications or detect attempts to manipulate payment-related processes.
Huntress also observed a compromised mailbox being used to distribute spam to hundreds of external recipients before Microsoft Entra ID Protection classified the account as high risk.
These activities demonstrate how session hijacking can evolve into business email compromise (BEC), where attackers exploit trusted business communications to support fraud, impersonation, or unauthorized information gathering.
Importantly, Huntress did not establish that every compromised account was used for financial fraud or that the campaign resulted in confirmed monetary losses.
The observed mailbox manipulation nevertheless demonstrates the attackers' interest in maintaining covert access to communications that could support financially motivated operations.
Two Attack Toolsets Supported the Campaign
Huntress identified two distinct technical implementations used to replay stolen Microsoft 365 authentication material.
The first, designated Build A, relied on scripted token replay. Its requests frequently used a node user-agent string and interacted with Microsoft Office or Microsoft Authentication Broker authentication clients.
This toolset targeted services including Microsoft Graph, Exchange Online, SharePoint Online, and the Device Registration Service.
Build A was also associated with the registration of rogue Windows-style devices in Microsoft Entra ID.
The second implementation, Build B, focused on browser session replay and presented itself as a conventional Chrome or Edge browser running on Windows.
Rather than relying on the same scripted authentication patterns, Build B interacted with browser-oriented authentication flows, including OfficeHome and Exchange Online.
These differences matter because a detection rule targeting one implementation might fail to identify the other.
For example, unusual node user-agent strings may be useful when investigating scripted authentication activity, but they would not necessarily identify a session replay attempt that appears to originate from a conventional browser.
Huntress tracked both implementations across four phases of activity, with the attackers rotating between several IP addresses.
The principal token-replay infrastructure was concentrated in the 193.26.115[.]0/24 range, associated with German hosting provider 1337 Services GmbH.
The use of hosting infrastructure should not be interpreted as evidence that the provider itself directed or knowingly participated in the attacks. Threat actors frequently rent legitimate infrastructure to conduct malicious operations.
The campaign also involved separate phishing relays and additional VPN or hosting services used for post-compromise mailbox activity.
This separation made the operation more resilient because blocking an individual replay address would not necessarily prevent attackers from capturing new sessions through unrelated infrastructure.
Attackers Rotated Infrastructure Across Four Phases
The campaign began on July 14, 2026, when Huntress observed suspicious authentication activity involving 193.26.115[.]221.
During the initial phase, the attackers registered unauthorized devices and accessed Microsoft 365 environments using stolen tokens.
By early August, the infrastructure had been associated with successful sign-ins at 37 organizations and the registration of 37 rogue Entra devices.
A second phase began in mid-August, introducing additional replay addresses and expanding the use of device-code phishing.
Device-code phishing exploits a legitimate Microsoft authentication workflow intended to authorize devices or applications that may not have conventional browser interfaces.
In a malicious scenario, attackers persuade a victim to enter a device authorization code on Microsoft's genuine sign-in page. The victim may believe they are completing a legitimate request, while the authorization actually grants access to a session controlled by the attacker.
This technique differs from conventional fake-login phishing because the victim may interact directly with Microsoft's legitimate authentication service.
The third phase, beginning September 11, featured a concentrated burst of automated authentication activity from 193.26.115[.]72.
Over four days, Huntress recorded 303 successful sign-ins across 29 organizations from that address.
The final observed phase involved browser session replay, including an incident on September 22 in which a stolen session was reused approximately four minutes after the victim encountered an AitM authentication relay.
The speed of these operations is particularly important. Attackers were able to move from session capture to unauthorized access within minutes, leaving limited time for traditional alerting and manual response processes.
Conditional Access Policies Blocked Attacks Where Properly Enforced
One of the most significant findings from Huntress involved the effectiveness of Microsoft Entra Conditional Access policies.
During the September campaign, the attackers generated 1,052 blocked sign-in attempts from one replay address. Those blocked attempts occurred across only four organizations.
Meanwhile, successful authentication activity was observed in other organizations where equivalent restrictions did not prevent access.
This difference demonstrates that Conditional Access can provide an important security boundary beyond the initial MFA challenge.
Conditional Access allows organizations to evaluate factors such as device state, application, authentication method, user risk, and other contextual signals before granting access to protected resources.
When properly configured, these policies can prevent authentication material from being reused in environments that do not satisfy the organization's access requirements.
However, their effectiveness depends on coverage and configuration.
Policies that apply only to selected users, applications, or client types may leave alternative authentication paths available.
Huntress recommended configuring Conditional Access to require MFA or block access across all users, cloud applications, and client application types, while also restricting device-code authentication where it is unnecessary.
Organizations should additionally evaluate phishing-resistant authentication and device-based access requirements appropriate to their environments.
A crucial operational detail is that a Conditional Access block may occur after the authentication system has already recognized valid credentials or authentication material.
Consequently, blocked sign-ins should not automatically be dismissed as harmless failures. They may indicate that an attacker possesses valid authentication material but has been prevented from using it by an additional security control.
Why Failed Login Counts Can Mislead Security Teams
The campaign also exposed a limitation in security monitoring strategies that prioritize incidents primarily by the number of failed authentication attempts.
Huntress observed that organizations generating large numbers of blocked sign-ins were not necessarily the organizations experiencing successful account compromise.
In fact, the concentration of blocked attempts at a small number of tenants indicated that their Conditional Access policies were preventing the attacker from obtaining access.
Other organizations recorded fewer conspicuous failures but experienced successful unauthorized sign-ins.
This creates a detection challenge for security operations centers.
Traditional password-spraying alerts often focus on high failure volumes, repeated attempts against multiple accounts, and unusual authentication patterns.
Token replay changes that relationship because the attacker may already possess valid authentication material.
A relatively small number of successful sign-ins from suspicious infrastructure may represent a more serious incident than thousands of blocked attempts against well-protected accounts.
Security teams should therefore correlate authentication outcomes with token usage, device registration, changes to MFA methods, and suspicious mailbox activity.
Indicators such as unfamiliar hosting-provider addresses, unusual authentication clients, and unexpected device registrations may provide stronger evidence of compromise when evaluated together.
Indicators of Compromise and Defensive Priorities
Huntress published technical indicators that organizations can use to investigate potential exposure to the campaign.
The principal token-replay IP addresses included:
193.26.115[.]221193.26.115[.]199193.26.115[.]16193.26.115[.]21193.26.115[.]72193.26.115[.]210
Additional infrastructure associated with session capture or mailbox manipulation included 185.238.2[.]195, 124.198.132[.]33, and 167.148.41[.]96.
These indicators should be treated as investigation leads rather than definitive proof of malicious activity in isolation.
The researchers also identified recognizable behavioral patterns, including rogue device names beginning with DESKTOP- followed by eight hexadecimal characters, unusual MFA registration events, and inbox rules that silently delete or relocate messages.
Organizations investigating suspected compromise should prioritize several actions:
Revoke active sessions and reset affected passwords. Password changes alone may not immediately invalidate every existing access token.
Audit Microsoft Entra device registrations. Identify unfamiliar devices and investigate registrations associated with suspicious authentication activity.
Review MFA methods. Remove unauthorized authenticator applications and investigate cases where existing methods were cleared and replaced.
Inspect mailbox rules. Search for suspicious rules that delete messages, mark them as read, or move financial communications into obscure folders.
Strengthen Conditional Access. Apply appropriate restrictions across users, applications, and authentication flows, including device-code authentication.
Investigate suspicious OAuth activity. Review token exchange events and unexpected access to Microsoft Graph, Exchange Online, SharePoint Online, or device registration services.
Audit enterprise application permissions. Identify unauthorized applications and restrict unnecessary user consent to new integrations.
Huntress also recommended reviewing authentication events involving OAuth2:Token requests, unusual node or minimal Mozilla/5.0 user-agent strings, and Microsoft Office authentication clients originating from hosting infrastructure.
Because some legitimate applications use similar authentication mechanisms, these indicators should be correlated with other suspicious behavior before administrators take disruptive action.
Token Replay Redefines the Microsoft 365 Identity Threat
The campaign demonstrates that identity compromise increasingly extends beyond stolen passwords.
Attackers can capture authenticated sessions, reuse tokens, register unauthorized devices, modify MFA methods, and manipulate business communications without needing to repeatedly defeat the original authentication challenge.
The observed activity also highlights the speed with which an initial compromise can become persistent. In some cases, attackers registered new authentication methods within an hour of obtaining access, while stolen sessions were replayed only minutes after victims completed their sign-ins.
For organizations relying on Microsoft 365, these findings reinforce the need to treat identity security as a continuous process rather than a single authentication event.
MFA remains essential, but it must be supported by phishing-resistant authentication, properly configured Conditional Access, device governance, session monitoring, and effective incident response procedures.
The investigation also demonstrates that successful authentication events deserve as much scrutiny as failed attempts, particularly when they originate from unexpected infrastructure or are followed by changes to security settings.
The central lesson is that attackers no longer need to steal a password if they can steal the authenticated session that follows it.
With 97 accounts compromised across 79 organizations, the Huntress findings provide concrete evidence of how token replay can undermine poorly protected Microsoft 365 environments and create opportunities for persistent account access and business email compromise.
As adversaries continue refining identity-based attacks, organizations must move beyond simply verifying who completed MFA and focus on whether the resulting session, device, and account activity remain trustworthy.