Cybersecurity researchers have uncovered a Microsoft 365 campaign that uses stolen sign-in tokens to bypass repeated authentication checks and break into email accounts across dozens of organizations.

The attackers compromised 97 accounts and registered 48 unauthorized devices in Microsoft Entra ID after targeting 79 organizations, according to an investigation by cybersecurity firm Huntress.

The activity was observed between July 14 and September 22, 2026. During that period, Huntress detected 497 successful Microsoft 365 sign-in events among the affected organizations, alongside more than 200,000 login attempts associated with the campaign. Rather than relying on repeated password guesses, the attackers used stolen authentication tokens to access accounts without having to complete the entire sign-in process again.

The technique, described as token spraying, involves replaying stolen authentication tokens at scale across multiple organizations. It resembles password spraying, but instead of testing commonly used passwords against numerous accounts, attackers reuse tokens obtained from previously compromised sign-in sessions.

The campaign relied partly on adversary-in-the-middle (AitM) phishing pages that sit between victims and Microsoft’s legitimate login infrastructure. When users enter their credentials and multifactor authentication (MFA) codes, the phishing infrastructure relays the information to Microsoft while capturing authentication data exchanged during the process.

The attackers then obtain access tokens issued after successful authentication. These tokens can serve as proof of an already authenticated session, allowing the attackers to replay them from their own infrastructure and access Microsoft 365 services without repeating the original MFA challenge, provided the tokens remain valid and usable.

READ
Hackers Claim SBI Customer Data Leak, but Breach Remains Unverified

Huntress researchers Andrea Hatcher, Susannah Matt, Matt Poto, and Andrew Schwartz traced more than 200,000 failed login attempts during the campaign window to the IP range 193.26.115[.]0/24. The researchers said the attackers also obtained tokens through other methods, including device-code phishing and social engineering during legitimate sign-in processes.

After gaining access to an account, the attackers attempted to establish persistent access by registering their own authenticator applications. This allowed them to complete MFA challenges for subsequent sign-ins, including situations where an original session token expired or was revoked.

In at least 19 organizations, the attackers removed existing MFA methods and registered new ones within three hours of the first observed sign-in. In one incident on July 21, 2026, they registered an authenticator application named “iPhone 13” less than 51 minutes after hijacking a session.

The attackers also registered at least 48 unauthorized devices in victims’ Microsoft Entra directories. These devices appeared as computers associated with the affected organizations and could provide another route for requesting authentication tokens. Unlike a stolen session token, a rogue device registration may remain in the directory until administrators identify and remove it.

The campaign also involved changes to compromised mailboxes. Researchers found suspicious inbox rules with unusual names, including “.”, “sss”, “ss”, “iT”, “,.”, “……..”, “s”, and “d”. These rules were designed to delete or conceal incoming messages containing terms related to payroll, deposits, and bonuses, potentially hiding financial communications from account owners.

READ
UAE-Led Operation Uncovers $39 Billion in Scam-Linked Assets, Arrests 960

Some messages were redirected to obscure folders, including RSS Feeds and Conversation History. In one case, an inbox rule marked all incoming messages as read and deleted them. The compromised mailbox was subsequently used to send spam to hundreds of external recipients before Microsoft Entra ID Protection classified the account as high risk.

The campaign’s infrastructure also raised concerns. Researchers initially observed activity from the Romanian IP address 193.26.115[.]221, which VirusTotal associates with detections involving the AsyncRAT remote access trojan. The address is hosted by German provider 1337 Services GmbH.

GreyNoise data cited in the investigation listed 29 IP addresses associated with the hosting provider, including 10 classified as malicious and five marked suspicious. The provider has also been linked to remote server rental services, including StarkRDP and rdp.sh, now operating under the exy.sh name. These infrastructure associations do not, by themselves, establish that the hosting provider or the services’ operators were responsible for the Microsoft 365 campaign.

The incident highlights how stolen authentication tokens can undermine security measures that depend on users completing multifactor authentication. Even when MFA is enabled, an attacker who captures a valid authenticated session may be able to access services without triggering another challenge. Registering unauthorized authentication methods and devices can make such access more difficult to detect and remove.

Organizations that suspect a token-replay attack should immediately revoke active sessions and refresh tokens where possible, reset affected passwords, and investigate unfamiliar sign-in activity. Administrators should review registered devices, remove unauthorized MFA methods, and inspect inbox rules for hidden or suspicious forwarding, deletion, and message-handling actions. They should also check for unexpected enterprise applications and other changes that could allow attackers to retain access.


Buy ExpressVPN with PayPal or Credit Card
READ
PHP Releases Emergency Patches for Two Critical Flaws That Could Let Hackers Take Over Servers

Huntress recommends strengthening Microsoft Entra Conditional Access policies to require MFA or block access for all users, cloud applications, and client application types, with appropriate exceptions for legitimate operational requirements. Organizations should also evaluate device-code authentication and apply suitable Conditional Access restrictions to reduce exposure to device-code phishing.

Advertisement