Multi-factor authentication only protects the moment you log in. After that, what keeps you signed in is a session token: a small piece of data that tells Microsoft 365 you already passed the password and MFA checks. Anyone who steals that token and presents it can often walk straight in, with no password and no MFA prompt.

New research from managed security firm Huntress, published October 22, describes an attacker doing exactly that across dozens of businesses. Huntress researchers Andrea Hatcher, Susannah Matt, Matt Poto and Andrew Schwartz traced the activity between July 14 and September 22, 2026. Over that period they recorded 497 successful Microsoft 365 sign-ins at 79 organizations, plus more than 200,000 failed login attempts. All of it came from a single block of IP addresses, 193.26.115[.]0/24, which Huntress tied to AS210558, owned by 1337 Services GmbH, a hosting provider incorporated in Hamburg, Germany.

Huntress calls it a "token spray and replay" campaign. The attacker didn't guess passwords. They had already collected tokens and were testing them in bulk to see which ones still worked.

Where the tokens came from

According to Huntress, the stolen tokens came from several sources: adversary-in-the-middle (AiTM) relays, device-code phishing and social engineering.

An AiTM relay is a phishing proxy. The victim lands on what looks like a Microsoft sign-in page, but the page passes everything back and forth to the real Microsoft service. The victim types their password and approves the MFA prompt as usual. Microsoft issues a session token, and the proxy copies it on the way back. The login is real and so is the MFA approval. The attacker just ends up holding the result.

Device-code phishing abuses a legitimate Microsoft sign-in flow. The victim is persuaded to type a short code into a genuine Microsoft page. That authorizes a session the attacker started.

In ID Tech's summary of the research, the capture relays and the replay servers were separate pieces of infrastructure. The replay side was traced to six addresses inside the 1337 Services block.

What the attacker did once inside

A replayed token gets an attacker into the account, but a token can expire or be revoked. Much of what Huntress documented looks like work to stay in after that happens.

  • Rogue devices. Huntress found at least 48 attacker-controlled devices registered in Microsoft Entra ID, Microsoft's cloud identity service. ID Tech reported they followed a naming pattern: "DESKTOP-" plus eight uppercase hexadecimal characters, which mimics default Windows hostnames.
  • MFA replaced. Huntress says victims' MFA methods were wiped and replaced with the attacker's own. The Hacker News reported that in at least 19 organizations, the existing MFA was removed and a new method registered within three hours. In one July 21 case, it said, an authenticator named "iPhone 13" was registered less than 51 minutes after the session was hijacked. Huntress's own timeline for that incident shows the victim reaching the MFA prompt at 17:18 UTC, the session hijacked at 17:30 (a 12-minute gap, which ID Tech also reported) and the new authenticator active at 18:08, roughly 38 minutes after the hijack.
  • Hidden mail. The attacker created inbox rules to hide messages. The Hacker News reported rule names such as ".,", "sss" and "iT", set to bury mail about payroll, direct deposit and bonuses.
  • Outbound fraud. Huntress noted at least one payroll-related email sent from a compromised account to an outside contact.

That combination of payroll keywords, hidden replies and messages to outside contacts is typical of business email compromise.

About the numbers

Coverage of the campaign has used two different headline figures, and they measure different things. Huntress's post counts 497 successful sign-ins across 79 organizations. The Hacker News headline says 97 accounts were compromised. That figure does not appear in Huntress's post, so it should be read as The Hacker News's number, not Huntress's. Both sources agree on 79 organizations and at least 48 rogue devices.

The Hacker News also reported that the activity was first seen from 193.26.115[.]221. It described that address as Romanian and said VirusTotal associates it with AsyncRAT, a commodity remote-access trojan. None of the sources attributes the campaign to a named group or country.

Why a password reset isn't enough

The most practical point in Huntress's write-up is about cleanup order. A password reset is a common first response to a suspected account takeover. In this campaign, Huntress says, a reset alone leaves the attacker's registered devices and MFA methods in place. The attacker can then come back through a device or authenticator they registered, without ever needing the new password.

What It Means for Defenders

Who is affected: Any organization using Microsoft 365 with Entra ID. The campaign hit 79 organizations in Huntress's visibility. Because it relied on stolen post-MFA tokens, having MFA turned on did not protect those accounts. Organizations that treat "MFA enabled" as the finish line should take note.

Hunt first:

  • Review Entra sign-in logs for activity from 193.26.115[.]0/24 (AS210558, 1337 Services GmbH) between mid-July and late September. Block the range if you have no business with it.
  • Audit registered Entra devices, especially ones named "DESKTOP-" plus eight hex characters that no one in IT recognizes.
  • Audit MFA methods on every account. Look for recently added authenticators, particularly ones registered shortly after an older method was removed.
  • Check mailboxes for inbox rules with meaningless names (".,", "sss", "iT") or rules that move or delete mail mentioning payroll, deposit or bonus.

If you find a compromised account, clean up in this order, per Huntress: revoke all active sessions and reset the password (a reset alone does not invalidate an already-issued access token, Huntress notes), then remove the attacker's devices and MFA methods. Skipping the second step leaves the attacker a way back in.

Harden:

  • Huntress recommends Conditional Access policies that require MFA, or block access, for all users, all cloud apps and all client app types. Gaps in coverage, such as legacy clients or excluded apps, are where replayed tokens get through.
  • The Hacker News recommends restricting the device-code authentication flow. Huntress adds that where the flow is genuinely needed, it should be limited to restricted service accounts.
  • Look at Microsoft's Token Protection for Conditional Access. It accepts only sign-in session tokens bound to the device they were issued to, such as Primary Refresh Tokens, so a token stolen from one machine fails on another. Microsoft describes it as one layer of defense in depth, not a complete fix, and support varies by platform and app. Check coverage before relying on it.

Train for the right thing: Users who know to "never share an MFA code" can still be caught by an AiTM page, because that page asks for nothing unusual. Phishing training should cover lookalike login pages and unexpected requests to enter a device code.

Sources