Cybersecurity firm **Huntress** has revealed details of a pervasive **Microsoft 365** campaign utilizing an **AitM** relay to capture sign-in sessions and replay stolen tokens. Observed between July 14 and September 22, 2026, the campaign saw 497 successful **Microsoft 365** sign-ins across 79 victim organizations, stemming from over 200,000 login attempts. Ultimately, 97 accounts were compromised, and 48 rogue **Entra** devices were registered. ### How the AitM Attack Unfolds **Huntress** researchers Andrea Hatcher, Susannah Matt, Matt Poto, and Andrew Schwartz detailed that the attackers did not guess passwords. Instead, they replayed stolen sign-in tokens. The campaign's 200,000+ failed login attempts trace back to the **193.26.115[.]0/24** IP range. This attack employs an **AitM** login page, which acts as an intermediary between victims and legitimate **Microsoft** infrastructure. This allows the attackers to capture entered credentials and **MFA** codes, relaying them to the real login page. The primary objective is to collect the access token issued by **Microsoft** post-sign-in, thereby circumventing the need to bypass **MFA** a second time. This "proof of login" token is then replayed by the attacker from their own devices, often within minutes, to automate sign-in attempts against **Microsoft 365** services. ### Token Spraying and Persistence This technique has been dubbed "token spraying" due to its similarity to password spraying, where numerous stolen tokens are replayed at scale across multiple organizations. Upon gaining successful access, the threat actors quickly move to establish persistence. They add their own authenticator app to complete **MFA** challenges for new sign-ins, ensuring continued access even if the stolen session token expires or is revoked. In 19 organizations, existing **MFA** methods were removed, and a new one registered within three hours of the initial sign-in. In one case, a new authenticator app named "iPhone 13" was activated less than 51 minutes after session hijacking. ### Rogue Devices and Malicious Email Rules Beyond **MFA** manipulation, attackers also registered at least 48 fake computers in victim organizations' **Microsoft** directories. These rogue devices provide a more durable method for requesting tokens than relying solely on a stolen session, persisting until manually removed. Furthermore, the attackers established hidden email rules in victims' inboxes. These rules, often with innocuous names like ".", "sss", or "iT", are designed to delete incoming mail containing keywords related to payroll, deposits, or bonuses, or move them to obscure folders like RSS Feeds and Conversation History. In one instance, a compromised mailbox was used to send outbound spam to hundreds of external recipients before **Microsoft Entra ID Protection** flagged the account as high risk. ### Attack Origins and Recommendations **Huntress** indicates that the stolen tokens originate from various sources, including **AitM** relays behind fake sign-in pages, device-code phishing, and social engineering during legitimate login processes. The campaign's initial observations point to a Romanian IP address, **193.26.115[.]221**, which **VirusTotal** links to the **AsyncRAT** remote access trojan. This IP is associated with **1337 Services GmbH**, a German hosting provider. **GreyNoise** data lists 29 IP addresses tied to this provider, with 10 flagged as malicious and five as suspicious. Notably, **1337 Services GmbH** has connections to **StarkRDP** and **rdp[.]sh**, services that allow users to rent virtual servers and were previously targeted in an international law enforcement operation dubbed Talent in January 2025. Organizations suspecting a token replay compromise should immediately: * Revoke sessions and reset passwords. * Audit **Entra** devices for unauthorized registrations. * Review and verify all **MFA** methods. * Check for unexpected inbox rules or new enterprise applications. * Restrict device-code workflows using **Conditional Access Policies (CAPs)**. **Huntress** researchers emphasize the importance of appropriately implemented **CAPs** to address security gaps that **MFA** alone cannot cover. They recommend that businesses configure **CAPs** to require **MFA** (or block access) for all users, all cloud apps, and all client app types, unconditionally.