Huntress: Microsoft 365 token replay hit 79 orgs

Attackers didn’t need to break passwords to slip into Microsoft 365. They just re‑used what victims had already earned: valid session tokens.

Cyber firm Huntress says it watched an adversary‑in‑the‑middle (AitM) campaign replay stolen Microsoft 365 tokens to log 497 successful sign‑ins, ultimately compromising 97 accounts across 79 organizations between July 14 and September 22, 2026, according to The Hacker News.

What happened

Huntress attributes the intrusions to an AitM relay that captured sign‑in sessions and then replayed those tokens to impersonate users inside Microsoft 365, The Hacker News reports. The endgame included breaking into targeted email accounts, where access typically unlocks high‑value threads and sensitive attachments.

The telemetry window Huntress cites—July 14 through September 22, 2026—frames the campaign’s active phase. Within that period, Huntress counted 497 successful sign‑ins tied to replayed tokens, a number that doesn’t just tally attempts but sessions that actually cleared Microsoft 365’s checks.

The scope Huntress lists is concrete: 97 individual accounts at 79 separate organizations. That split matters, because it hints at broad targeting with modest depth per tenant rather than a single deep breach, shifting the response from a one‑off cleanup to many small, urgent hunts.

Token replay changes the usual login story. Instead of stealing a password, the attacker pockets a valid session cookie or access token mid‑flow and reuses it, skipping the fresh MFA challenge a normal login would have triggered. Huntress’s findings show that this approach was enough to pass Microsoft 365’s gate for hundreds of sessions.

Email access has outsized leverage inside 365. With a mail account, attackers can rifle through invoices, pull down attachments, and reset access to other apps that trust that mailbox. Huntress’s report to The Hacker News makes clear the prize in this campaign was inboxes, not just identity trophies.

The AitM relay piece describes how the theft worked. A relay sits between the user and Microsoft, luring the user to a phishing page that proxies the real login. The attacker harvests the token issued to the real session, then replays it elsewhere. Huntress’s numbers show that tactic paid off repeatedly in mid‑2026.

The background

Microsoft 365 tokens exist to smooth user experience: they let you skip fresh logins for email and other apps once you’ve proved who you are. That convenience becomes risk when a token isn’t tightly bound to a device or context and can be replayed from somewhere else.

Adversary‑in‑the‑middle phishing has been hammering MFA for years by proxying real login flows, then stealing what comes after. We’ve covered similar playbooks aimed at Google accounts in our report on AitM kits stealing Google MFA, which showed how convincing invites fuel successful relays.

Campaigns that replay tokens can multiply their damage without tripping obvious alarms. There may be no password failure and no new MFA prompt—just a quiet, valid‑looking session. Huntress’s 497 successful sign‑ins highlight how replay can turn a single phish into many authenticated entries.

The 79‑organization spread echoes the “many tenants, light touch” pattern we saw when a compromised credential let actors touch 173 Microsoft 365 tenants in our coverage of ConnectWise Cloud Backup fallout. The through line: attackers favor breadth when credentials or tokens scale easily.

Threat crews have also blended automation to push broader, faster hits. Microsoft recently tied a China‑linked group to automated runs at thousands of tenants via ConnectWise, as we covered in Microsoft naming Storm‑0940’s AI‑assisted hits. Automation plus replayable tokens shortens the gap between first phish and inbox access.

For defenders, token theft shifts the focus from just login enforcement to session governance. Controls that bind tokens to device posture, network location, or real‑time risk can make a replayed token less portable—and less valuable to an attacker who isn’t on the original path.

What people are saying

Huntress told The Hacker News it saw 497 successful Microsoft 365 sign‑in events attributable to the campaign, a count that maps to real access rather than blocked attempts. That detail underscores how AitM token replay can look indistinguishable from legitimate user behavior.

The firm also tied the campaign to 97 compromised accounts spanning 79 organizations, numbers that suggest a targeted but distributed approach. Those figures push incident responders to check for lateral movement inside each affected tenant while also coordinating a cross‑tenant picture of the indicators.

Security teams we’ve spoken with in prior, similar incidents prioritize purging tokens and forcing re‑authentication across suspected accounts. While password resets matter, token invalidation is the step that actually cuts off a replay attacker mid‑session.

Vendors have been tuning detection for these telltale signs: clustered successful sign‑ins, repeated user agents, and geography hops that don’t come with fresh MFA prompts. We’ve noted this shift toward intent and behavior analysis in our look at Proofpoint’s “intent” push, where signals around what an actor tries to do can outweigh clean login telemetry.

Help desks and manual processes can also be unwitting on‑ramps when a token thief wants persistence. We recently showed how AI‑smoothed social calls can pierce MFA, reminding teams that policy exceptions and human‑verified resets need the same rigor as automated login gates.

What happens next

If your tenant overlaps the July 14–September 22, 2026 window, start with scoping. Pull sign‑in logs for those dates, highlight successful sessions from new locations, and trace mailbox activity during and after those sign‑ins for sensitive access.

Next, kill any stolen leverage. Revoke refresh tokens for accounts with suspicious sessions, sign out of all locations, and force re‑authentication. A replay attack lives on borrowed time; taking away token validity ends it.

Then, raise the bar for portability. Tighten conditional access to bind sessions to device compliance and known networks, and turn on risk‑based controls that challenge unusual sign‑ins even when a token looks valid.

Finally, rehearse the playbook. Build detections for clusters of successful sign‑ins without corresponding MFA prompts, and pre‑stage a response that pairs token revocation with mailbox forensics. Put that runbook where your on‑call can grab it—in the same place you track other security coverage in Email Vox’s hub.