Stolen M365 Sessions Hit 79 Organisations — Check Devices, MFA Methods and Inbox Rules

On 22 October 2026 Huntress published a write-up on a Microsoft 365 campaign it tracked between 14 July and 22 September. It responded to incidents at 79 organisations, counting at least 497 successful sign-ins and more than 200,000 failed attempts.

The attacker didn’t need passwords. Staff signed in through adversary-in-the-middle (AiTM) relays behind fake sign-in pages, or were talked into approving a device-code sign-in on Microsoft’s real page. The relay kept the session token Microsoft issues after MFA, and within minutes that token was replayed from rented hosting. Because the token already carries the MFA claim, the attacker didn’t have to pass MFA again. Huntress calls this “token spraying”: the same idea as password spraying, but with stolen sessions.

What happened next is the part worth reading slowly:

• Rogue devices. At least 48 fake computers were joined to victims’ Entra directories, named DESKTOP- plus eight hex characters. A registered device can keep requesting tokens long after the stolen session dies.
• Swapped MFA methods. In 19 organisations the victim’s MFA methods were wiped and a new authenticator registered within three hours of the first malicious sign-in. That access survives a password reset.
• Hidden inbox rules. Rules with forgettable names like ., sss or s moved mail to RSS Feeds or Conversation History. One rule hid anything mentioning payroll, direct deposit, bank or bonus, and the mailbox then sent a payroll-related email to an outside accountant.

Why NZ organisations should care

This is business email compromise with the MFA box already ticked. Payroll and supplier-payment changes made over email are a familiar fraud path for New Zealand businesses, and a hidden rule means the real staff member never sees the reply that would have tipped them off.

If the compromised mailbox holds personal information, you may be looking at a notifiable privacy breach under the Privacy Act 2020. You need to be able to show what the attacker could reach and when access was cut off, and that is much harder if no one is reviewing sign-in logs, device registrations and mailbox rules.

The encouraging part: Huntress says Conditional Access “did real work”. In one burst, 1,052 sign-ins from the same address were blocked, but all of those blocks came from just four organisations. The 29 organisations it got into had nothing in the way.

What to check this week

• Entra devices. Look for recently registered devices named DESKTOP- plus eight hex characters, especially ones registered from hosting or VPN addresses. The pattern isn’t unique to this campaign, so confirm before deleting.
• MFA methods. Look for accounts where methods were cleared and re-registered within minutes, and remove any authenticator the user doesn’t recognise.
• Inbox rules. Review rules with one- to three-character or punctuation-only names, rules that move mail to RSS Feeds, RSS Subscriptions or Conversation History, and rules keyed on payroll or banking words.
• Sign-in logs. Treat Conditional Access blocks (AADSTS53003) as a sign the credential or token was valid, not as a save. Hunt for token sign-ins from hosting providers using the Microsoft Office or Authentication Broker client with a node or bare Mozilla/5.0 user agent.

What to tighten

• Require MFA for all users, all cloud apps and all client app types in Conditional Access, with break-glass accounts excluded and monitored.
• Block device-code flow with a Conditional Access authentication-flows policy unless you have a named business exception.
• Require compliant or hybrid-joined devices for Exchange, SharePoint and Graph-heavy apps where you can, so a replayed token from an unknown machine doesn’t get far.
• Lock down security-info registration and device join. Put registering MFA methods and joining devices behind their own Conditional Access policies, and limit who can join devices to Entra.
• Move admins and finance staff to phishing-resistant MFA (passkeys, FIDO2 or Windows Hello for Business). AiTM relays can’t replay what they can’t phish.
• Restrict user consent to apps and review new enterprise applications. Huntress flags new app grants as a persistence path.

If you find a compromised account

Revoke the user’s sessions and reset the password. A reset alone doesn’t remove attacker-registered devices or MFA methods, and doesn’t cancel an access token that is already issued. Then delete the rogue device, remove the rogue MFA method, remove hidden inbox rules, and check what the mailbox sent while the attacker had it. If personal information was exposed, start your Privacy Act breach assessment.

If you want a starting point for the policies above, see our Conditional Access Starter Checklist, and the earlier note on passkey-themed lures that lead to AiTM and device-code compromise.

Sources: Huntress: M365 Token Spray and Replay Campaign Compromises Business Email Accounts (22 Oct 2026), Help Net Security summary (23 Oct 2026).