Microsoft 365 token-replay campaign hits 79 organizations via AitM relays

Between July 14 and September 22, 2026, attackers used adversary-in-the-middle relays to steal Microsoft 365 sign-in tokens and replay them against victim tenants. Huntress tracked the activity, which hit 79 organizations and compromised 97 accounts while registering dozens of rogue Entra devices.

What happened

Huntress observed more than 200,000 login attempts tied to the campaign, resulting in 497 successful Microsoft 365 sign-ins. From those sessions, the threat actors ultimately took over 97 user accounts and registered at least 48 fake computers in victims’ Microsoft directories. The researchers traced the bulk of failed attempts to the IP range 193.26.115[.]0/24, with initial observations pointing to a Romanian address, 193.26.115[.]221.

After gaining access, the attackers added their own authenticator apps to maintain persistence and bypass future MFA challenges. In at least 19 organizations, existing MFA methods were removed and new ones registered within three hours of the first unauthorized sign-in. In one case on July 21, 2026, an authenticator labeled “iPhone 13” appeared less than 51 minutes after hijack.

The intruders also created hidden inbox rules with names like “.,” “sss,” and “d” to delete or redirect messages containing keywords such as payroll, deposit, and bonus. Some rules moved mail into obscure folders like RSS Feeds and Conversation History, and in one mailbox all incoming messages were marked read and deleted before the account was used to send outbound spam.

How it works

The core technique is an adversary-in-the-middle relay that presents a fake Microsoft login page to the victim. As the user enters credentials and completes multi-factor authentication, the relay forwards those inputs to the real Microsoft service. The goal is not to keep the password but to capture the access token Microsoft issues after a successful sign-in.

Once the token is captured, the attacker replays it from their own infrastructure within minutes. Huntress calls this pattern “token spraying” because many stolen tokens are reused at scale across multiple organizations, similar to how password spraying tests one password against many accounts. Because the token already proves authentication, the attacker does not need to solve MFA again during the replayed session.

Tokens came from several vectors, including AitM relays behind fake sign-in pages, device-code phishing flows, and social engineering during legitimate logins. Registered rogue devices give attackers a durable path to request new tokens even if a stolen session expires or is revoked.

Key details

• Timeline: July 14 to September 22, 2026, per Huntress observations.
• Scope: 79 organizations affected; 97 accounts compromised; 497 successful sign-ins from over 200,000 attempts.
• Infrastructure: Failed attempts linked to 193.26.115[.]0/24; initial IP 193.26.115[.]221 associated with AsyncRAT and German host 1337 Services GmbH.
• Persistence: Attackers registered at least 48 rogue Entra devices and added their own authenticator apps; in 19 orgs, MFA methods were replaced within three hours.
• Evasion: Hidden inbox rules with short or dot-based names deleted or redirected mail referencing payroll, deposit, and bonus.
• Mitigation guidance: Revoke sessions, reset passwords, audit Entra devices and MFA methods, review inbox rules and enterprise apps, and restrict device-code flows with Conditional Access.

Why it matters

For teams managing Microsoft 365, this campaign shows that strong MFA alone may not stop account takeover when tokens are intercepted and replayed. The attack bypasses the usual second factor by reusing a valid proof-of-login token, then cements access by registering new devices and authenticators. That combination makes detection harder and increases the window for data theft or abuse.

The operational impact is immediate: compromised mailboxes can be silenced with stealthy rules, financial communications can vanish, and outbound spam can damage sender reputation. Because rogue devices persist in the directory until manually removed, cleanup requires careful auditing of Entra registrations, MFA enrollments, and conditional policies rather than just password resets.

What you can do

• Revoke active sessions and reset passwords for any suspected accounts, then force re-authentication.
• Audit Entra device registrations and remove unknown or suspicious entries, including recently added computers.
• Review MFA methods for affected users and remove unfamiliar authenticator apps or phone numbers.
• Search for unexpected inbox rules with short or unusual names and check for mail redirection to obscure folders.
• Restrict device-code authentication flows using Conditional Access policies to reduce AitM and phishing risk.
• Apply Conditional Access broadly: require MFA or block access for all users, all cloud apps, and all client app types.