Token spraying: 200,000 sign-in attempts and 497 that worked, without a single password

Business email compromise usually starts with something a defender can see: a phishing page, a malicious attachment, a suspicious sign-in from an unusual country. The campaign Huntress described on October 22, 2026 has none of those leading indicators. The attackers stole session tokens after a legitimate login and MFA challenge, then replayed them from their own machines against Microsoft 365 until some of them were accepted.
The numbers from the research are worth setting out plainly. Investigators began from suspicious sign-in events across 79 Huntress customer organisations between July and September 2026. They traced a global adversary-in-the-middle operation that made at least 200,000 login attempts and achieved 497 successful sign-ins. In many cases the attacker was inside the environment minutes after stealing the token.

Why the token is the whole attack

A session token is issued after the real login page has been used and any associated multi-factor authentication has verified the account. Whoever holds it does not need to pass MFA again. An adversary-in-the-middle page takes the token as it is issued, then the attacker presents it from a different machine.
That is the difference between this campaign and a password spray. A password spray fails loudly in the authentication logs, is rate limited, and produces a visible pattern of failures. Token replay produces successful authentications with valid tokens, from infrastructure the identity provider has never seen, against accounts whose credentials were never compromised. Microsoft's own sign-in logs will show the success. What they will not show is a password failure that never happened.
The word "spraying" in the researchers' description refers to the volume and automation of the replay, not to guessing.

What the attackers did after getting in

The research describes a consistent post-compromise routine, and each step is a control the victim had configured.
In several incidents the attackers wiped the victim's MFA settings and registered their own phone to the account. A password reset afterwards did not remove them, because the attacker now held an authenticator for the environment.
Hidden inbox rules moved messages from specific contacts out of sight. This is the classic BEC preparation step: remove the thread where the fraudulent request will be noticed by a colleague.
Entra settings were modified to register the attacker's own devices as legitimate, so further tokens could be requested later.
One compromised mailbox was used to send a payroll-related phishing message. In the reported case the payment did not arrive, but the mechanism is the familiar one: a request from a real internal address, in a real thread, from a mailbox the recipient has corresponded with before.

What the response has to include

The recovery advice in the research is short and it is ordered for a reason.
Revoke the sessions first. Disabling the account or resetting the password leaves existing tokens valid, which is the same failure the researchers documented in the first place. Session revocation is the step that ends the attacker's current access.
Reset the password second, because the token was obtained alongside credentials in many adversary-in-the-middle flows and the attacker may hold both.
Then audit Entra devices and MFA methods. A registered device or a phone number that the user does not recognise is the persistence mechanism, and it has to be removed before the account is trusted again.
Then review inbox rules. A hidden rule that survives the response is a forwarding path to the attacker that needs no further authentication.
Conditional Access is the preventive control the researchers point to, with a caveat that matters: it fills security gaps only when it is implemented properly. Their specific recommendation is to require MFA, or block, for all users, all cloud apps and all client app types, unconditionally. A policy that exempts a client type or a legacy protocol leaves a path for a token replay, because the replay arrives through whatever client the attacker chooses.

Detection that does not depend on the password

Three signals are available in the identity logs, and none of them requires knowing the token value.
A successful sign-in from an autonomous system or device that has never appeared for that user is the first. Enrichment against normal login geography is a weak substitute, because the attacker may use a proxy in the same country; the device and session identifiers are stronger.
A change to MFA methods shortly after a sign-in is the second. Users do add a new phone, but the combination of a new device, a new MFA method and a new inbox rule within a short window is not a normal administrative pattern.
Inbox rule creation that targets a named sender or contains a keyword list is the third. Mail-flow rules are low-volume events in most tenants and they are the mechanism the attackers used to stay hidden.

References

[1] Infosecurity Magazine, "Widespread Token-Spraying Attacks Target Microsoft 365 Accounts For Email Compromise", October 23, 2026. https://www.infosecurity-magazine.com/news/tokenspraying-attacks-target/