Between July 14 and September 22, 2026, a sweeping attack targeting Microsoft 365 platforms has compromised at least 97 user accounts across 79 organizations, according to cybersecurity firm Huntress. Instead of cracking passwords, attackers captured valid sign-in tokens—a method known as “token replay”—to infiltrate inboxes and register unauthorized devices. Once inside, they bypassed multi‐factor authentication (MFA) and maintained long-term access.
AitM Relays, Token Spraying & Device Persistence
The attack chain begins with an adversary-in-the-middle (AitM) relay setup, which intercepts user credentials and MFA codes from a fake sign-in page served between victims and Microsoft’s legitimate login portal. Once Microsoft issues a “proof of login” access token, attackers reuse it within minutes—often from different locations—to access Microsoft 365 services without needing to re-enter credentials.
In total, roughly 200,000 failed login attempts were tied to this campaign, all traced back to the IP range 193.26.115.0/24. Despite the huge volume of failures, attackers managed nearly 500 successful sign-in events and ultimately compromised 97 accounts.
To solidify their foothold, the threat actors added their own authenticator apps in many of the targeted organizations—replacing existing MFA methods so they could respond to future challenges themselves. In at least 19 organizations, MFA settings were altered within three hours of the first unauthorized access. One example: a “new” authenticator app labeled “iPhone 13” appeared just 51 minutes after a session was hijacked.
Moreover, attackers registered at least 48 rogue devices in affected Microsoft environments, which act as durable entry points beyond a stolen session. Beyond technical takeover, they manipulated email infrastructure—adding hidden inbox rules (named things like “s,” “ss,” “iT,” etc.) to delete messages with keywords such as “payroll” or “bonus,” or to reroute them to obscure folders. In some cases, mailboxes were misused to send spam once compromised.
Origins, Sources, and Recommended Defenses
The campaign drew from multiple infection vectors: AitM relays, device-code phishing, and social engineering during legitimate logins. One IP in particular—193.26.115.221—was flagged as associated with the remote access Trojan AsyncRAT and hosted via a German provider tied to known virtual server services like StarkRDP.
Huntress has urged organizations suspecting they’ve been hit by token replay to take several steps: revoke all active sessions, reset passwords, audit registered devices in Entra directories, check MFA configurations, look for odd inbox rules, and limit device-code workflows via Conditional Access Policies (CAPs). CAPs should demand MFA for all users across all cloud apps and block or tightly restrict client application types.
This attack exposes a weakness in traditional MFA defense models. With stolen tokens and registered devices, attackers can circumvent many protections. It underscores a broader trend: adversaries evolving beyond password theft toward more subtle, invisible intrusions. Microsoft-based environments, especially those not enforcing least-privilege policies or device vetting, are at elevated risk. Going forward, defenders should scrutinize enrolled devices, emerging sign-in contexts, and expiry/revocation practices. Conditional Access may no longer be optional—it’s the frontline.
