Researchers at Huntress uncovered a large-scale campaign to compromise Microsoft 365 accounts in which attackers replayed stolen authentication tokens instead of guessing passwords. According to Huntress, from July 14 to September 22, 2026, there were 497 successful logins to systems across 79 organizations amid more than 200,000 failed attempts. The attackers also registered at least 48 fake devices in the Microsoft Entra ID directories of affected companies. The campaign bypassed multi-factor authentication (MFA) and requires organizations to immediately review registered devices, MFA methods, and inbound mail rules.
Attack mechanism: from interception to replay
The campaign used an adversary-in-the-middle (AitM) technique — the attacker placed an intermediary login page between the victim and Microsoft’s legitimate infrastructure. When the user authenticated, including entering an MFA code, the intermediary server intercepted the access token issued by Microsoft — the “proof of login.” This token was then replayed from the attackers’ infrastructure within a few minutes, without the need to pass MFA again.
According to Huntress, tokens came from several sources: AitM relays behind fake login pages, phishing via the device code mechanism (device-code phishing), and social engineering during a legitimate login process. The researchers dubbed this approach token spraying — by analogy with password spraying, but instead of passwords, stolen tokens are massively replayed across many organizations.
The attack infrastructure was split into two tiers: AitM relays used to intercept sessions, and separate hosts for token replay. Replay activity originated from the range 193.26.115[.]0/24, associated with German hosting provider 1337 Services GmbH. Over 10 weeks, the attackers sequentially used six IP addresses in this block.
Persistence and post-exploitation
After gaining access, the attackers immediately established persistence in compromised environments. According to Huntress, in 19 organizations existing MFA methods were removed and replaced with new ones within three hours of the first login. In one case, recorded on July 21, 2026, a new authenticator app named “iPhone 13” was activated in less than 51 minutes after session takeover.
In parallel, the attackers registered fake devices in victims’ Entra ID directories. As the researchers note, a registered device provides a more durable way to request tokens than a stolen session and remains in the directory until it is manually removed.
At the post-exploitation stage, the attackers created hidden inbound mail processing rules with names like “.”, “sss”, “s”, “d”, “iT”. These rules deleted or moved to low-visibility folders (RSS Feeds, Conversation History) any emails containing keywords related to salary, bonuses, and direct deposits. In one compromised mailbox, a rule marked all incoming messages as read and deleted them, after which the mailbox was used to send spam to hundreds of external recipients.
Effectiveness of Conditional Access
Huntress data for the September phase of the campaign show a telling picture: from a single address, there were 303 successful logins across 29 organizations, while the same address received 1,052 blocked attempts — but all of those blocks occurred at just four organizations that had Conditional Access Policies configured. In the remaining 29 organizations, nothing prevented logins. This demonstrates that MFA alone does not protect against token replay — additional Conditional Access policies are required.
Connection to previous campaigns
The described campaign fits into a persistent trend of attacks on Microsoft cloud services through session hijacking. We have previously written about the Payroll Pirates campaign, which used AitM phishing against Microsoft 365, as well as the NovaCookies platform for stealing Microsoft 365 sessions. The current campaign stands out for its degree of automation and the separation of interception and replay infrastructure, which complicates detection.
Indicators of compromise
Huntress published the following IP addresses associated with the token replay infrastructure:
193.26.115[.]221— replay and device registration host (phase 1, July–August)193.26.115[.]199— session replay host (phase 1)193.26.115[.]16— replay and device-code phishing host (phase 2)193.26.115[.]21,193.26.115[.]72,193.26.115[.]210
Additional addresses linked to the campaign: 124.198.132[.]33, 45.83.31[.]44, 192.159.99[.]172, 185.238.2[.]195, 167.148.41[.]96.
Response recommendations
Huntress emphasizes that resetting the password alone is not enough — it does not remove devices and MFA methods registered by the attacker, and the access token remains valid for about 90 minutes after the reset. Recommended actions:
- Revoke all active sessions and then reset the password — in exactly that order
- Review Entra ID devices — delete unfamiliar entries of the form
DESKTOP-* - Audit MFA methods — remove unknown authenticator apps
- Check mail processing rules — look for rules with single-letter or dot-only names
- Review registered enterprise applications for any unauthorized entries
- Configure Conditional Access policies — unconditionally require MFA (or block access) for all users, all cloud apps, and all client app types
- Restrict device-code authentication via Conditional Access
Organizations using Microsoft 365 should immediately review sign-in logs for authentications from the 193.26.115[.]0/24 range, audit registered devices and MFA methods in Entra ID, and ensure that Conditional Access policies cover all application types and users without exceptions. Blocking only the replay IP range will not eliminate the threat — the token interception infrastructure is hosted on separate addresses, and the attackers regularly change hosts.
