- Huntress says attackers replayed stolen Microsoft 365 sessions at 79 organizations over ten weeks, needing no password and facing no second MFA check.
- Huntress says sorting tenants by failed logins would have sent responders to four organizations whose Conditional Access worked, and away from the breached ones.
- Resetting a password is not enough. Revoke sessions, then check devices, MFA methods and inbox rules.
In this campaign, the login was clean and the session was taken
Think of a hotel keycard. Staff check your ID once at the desk. After that, the card opens the door for whoever holds it.
A Microsoft 365 session works much the same way. Once you pass the MFA check, Microsoft issues a token. A token is a digital pass that says you have already proved who you are.
The attacker in Huntress's investigation took that pass, not the password. The login looked normal, and the session was what got stolen. This shows why a team should ask what it watches after the login, not only at it.
What Huntress found
Huntress tracked the campaign from July 14 to September 22, 2026. It responded to related incidents at 79 organizations. It logged at least 497 sign-ins that worked, and more than 200,000 that failed.
Those figures come from Huntress's own customers. They do not measure Microsoft 365 as a whole.
How a session gets stolen and reused
The victim lands on a fake sign-in page. Behind it sits an adversary-in-the-middle (AiTM) relay, a go-between server. The victim sees the genuine Microsoft page and answers the real MFA prompt.
The relay quietly copies the token Microsoft sends back. Huntress notes that the token is created after MFA. So whoever holds it does not face MFA again.
Other tokens came from device-code phishing. There, victims type a code into Microsoft's real sign-in page and hand over access. Some came from social engineering during an ordinary login.
The attacker then used the tokens from rented servers at 1337 Services GmbH, a hosting company in Hamburg. Huntress calls this "token spraying". It is password spraying with stolen tokens in place of guessed passwords.
The handoff was fast. On July 21, twelve minutes passed between the victim facing the MFA prompt and the attacker using the stolen session from a rented server. On September 22, the gap was four minutes.
How the attacker stayed in
Tokens expire, so the attacker added ways back in. Huntress found at least 48 fake computers in victims' Microsoft Entra directories. Entra is Microsoft's system for managing who and what may sign in.
Such a device can help the attacker ask for new tokens. It stays until an administrator deletes it.
In 19 organizations, the victim's MFA methods were erased and a new one was added. This happened within three hours of the first campaign sign-in. A password reset does not touch that new method. Only a manual review of the account's sign-in methods removes it.
Hidden inbox rules came next. In one incident, the attacker edited a rule to catch mail mentioning payroll, direct deposit, bank or bonus. Five minutes later, a second rule buried every message from an outside accountant.
The same mailbox was used to email that accountant about payroll. Huntress says the rules were created from VPN or rented hosting addresses, not from the 1337 Services range.
Why the loudest alarm would have misled responders
From September 11, one address racked up 1,052 blocked sign-ins. Just four organizations produced every one of those blocks, because their Conditional Access rules refused the attempts.
Over four days, the same address completed hundreds of successful sign-ins at nearly 30 organizations. Huntress says nothing stood in the way there. Its own passages give slightly different exact counts, so treat the figure as approximate.
Huntress advises against triggering response on spray volume. It says to prioritize by whether the credential was valid. Sorting by failures would have sent responders to the four tenants that were already protected, and away from the breached ones.
One clue helps. A Conditional Access block with error AADSTS53003 means the credential was valid. The block comes after sign-in succeeds.
Blocking single addresses is a weak fix. The operator used six addresses in one /24 block, over four phases. Microsoft flagged them one at a time, not as a range.
Huntress cannot say why the operator rotated them. In its view, a block on one address would have ended only one of the four phases. Blocking the whole /24 would have covered the six main replay hosts. It would not have covered the relays, which sat with other providers, or a few other 1337 Services addresses outside the range.
What to ask your security team
Huntress says well-built Conditional Access policies can stop token replay. Its advice is to demand MFA, or a block, for every user, every cloud app and every client app type, with no exceptions. Ask whether yours do.
Then ask four more questions.
First, when an account is compromised, do we revoke sessions as well as reset the password? Huntress says a reset alone leaves the access token usable for about 90 minutes. Second, after every incident, do we audit Entra devices, MFA methods and inbox rules? Third, have we restricted device-code sign-in? Fourth, can ordinary users approve new enterprise applications on their own?
A password reset changes the lock. It may leave the attacker's key in place.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Huntress.
