Microsoft 365 token theft: an account recovery checklist

Huntress reported responding to incidents at 79 organizations, observing 497 successful sign-in events and more than 200,000 failed attempts. The observed campaign ran July 14–September 22, 2026. These are findings from Huntress’s investigation, not worldwide totals or evidence that 79 organizations were compromised this week.^[1]

The attacker replayed captured Microsoft 365 sign-in sessions. Huntress also observed at least 48 rogue Entra devices, changes to victims’ MFA registrations, and inbox rules that hid communications. One incident involved a payroll-related email to an outside CPA. Those observations do not establish that a fraudulent payment occurred.^[1]

After a successful sign-in, services use tokens or session cookies to recognize authenticated access. In an adversary-in-the-middle phishing attack, a relay can pass the real sign-in and MFA prompts to the victim while capturing the resulting session. An attacker may then reuse that authenticated session without completing the same MFA challenge again.^{[1] [6]}

This is a reason to strengthen authentication and session controls, not turn MFA off. Huntress also described device-code phishing and social engineering. Investigate how access was obtained and what happened afterward rather than assuming every incident started with the same phishing page.^[1]

Assign an incident owner and involve an administrator or response provider with appropriate access. Preserve readily available evidence without delaying urgent containment. Microsoft recommends disabling a compromised account during investigation, then addressing sessions and the settings that could allow continued access.^{[2] [6]}

Microsoft distinguishes access tokens, refresh tokens and application-issued session cookies. Password resets affect these differently depending on the reset method and identity setup. An application can control its own session cookie, which Microsoft Entra cannot directly revoke. Hybrid or federated accounts also require the correct identity-source procedures.^{[3] [5]}

Revoke sessions explicitly, then verify the result. Microsoft says supported continuous access evaluation aims for near-real-time enforcement, but critical-event propagation can take up to 15 minutes. That is not a guarantee that all applications end access within 15 minutes. Token types, clients and resource controls differ.^{[4] [3]}

Look for rules that mark messages read, delete them, move them to obscure folders, or match payroll and banking terms. Also inspect mailbox-level forwarding. Huntress found suspicious rules created from infrastructure different from the main replay addresses, so an investigation limited to one IP could miss later activity.^{[1] [2]}

Compare unfamiliar rules, devices and authentication methods with the owner’s expected activity. A short rule name, hosting address or unfamiliar location alone does not prove compromise. Review events from before the first suspicious activity through containment, and record retention gaps. Missing evidence is not proof that no data was accessed.^{[2] [6]}

Keep MFA enabled. Ask IT to assess phishing-resistant authentication, appropriate Conditional Access coverage, device-code-flow restrictions and application-consent controls. Test policy changes and review exceptions so recovery does not create a lockout. Available protections and investigation data depend on your tenant, licensing and supported clients.^{[2] [1] [4]}

Close the incident against recorded checks, not a reassuring message. Keep a named owner for unresolved questions, retain the response timeline, and confirm that suspected payment changes were independently reviewed. The Microsoft documentation linked below was reviewed on October 23, 2026; follow its current instructions when responding.^[2]