Huntress has detailed a ten-week Microsoft 365 campaign that replayed stolen sign-in tokens at 79 organizations, then registered rogue Entra devices and replaced MFA methods. For responders, the main lesson is that a password reset is not containment.
What happened
In an October 22 post, Huntress dates the activity from July 14 to September 22, 2026. Across its customers, at least 497 sign-ins succeeded while more than 200,000 login attempts failed. The Hacker News puts compromised accounts at 97. Huntress names no actor.
Victims reached an adversary-in-the-middle (AitM) relay or a device-code phishing page. The relay passed the real MFA prompt through and kept the resulting token, which reappeared from a 1337 Services GmbH address (AS210558) within minutes: 12 minutes later on July 21, four on September 22.
Huntress then saw:
- Rogue devices: at least 48 fake Entra-joined devices.
- MFA tampering: 19 organizations saw a victim's existing methods wiped and replaced no more than three hours after a campaign address first signed in. One July 21 incident also produced a new authenticator named "iPhone 13."
- Mailbox abuse: hidden inbox rules with short or punctuation-only names, such as
.andsss, deleted or concealed mail, including payroll and banking messages. One compromised mailbox emailed an outside CPA about payroll, and another spammed hundreds of recipients outside the organization.
The operator rotated through six main hosts in 193.26.115[.]0/24 plus a few other 1337 Services addresses. Device-code phishing joined in the wave that began August 17.
Why it matters
A token captured after the victim completes MFA gives the attacker a working session without another prompt, and the new devices and authenticators provide a way back after that session ends. Huntress is direct about the response gap:
A password reset alone does not remove attacker-registered devices or MFA methods. — Huntress
Huntress adds that resetting the password leaves an issued access token valid for the rest of its roughly 90-minute lifetime, which is why sessions must be revoked as well.
The most useful triage finding is the blocked traffic. One replay host, 193.26.115[.]72, logged 1,052 blocked sign-ins, all from four organizations, with no overlap with the organizations where it succeeded. Huntress credits Conditional Access, and warns that ranking tenants by failed attempts would have sent responders to the four already protected.
Huntress recommends Conditional Access and does not discuss phishing-resistant MFA. In our view it belongs on the same roadmap; our earlier TA419 coverage explains why origin-bound methods matter against AitM relays.
What to check in your environment
- Update the token theft runbook. For each affected account, pair session revocation with a password reset. Cleanup isn't finished until someone has checked what the attacker left behind: Entra device registrations, MFA methods, inbox rules and newly added enterprise apps.
- Hunt for rogue devices. The naming pattern Huntress gives is one of three prefixes,
DESKTOP-,Device-orWork Pc, followed by eight hex characters. Registration from a hosting IP raises the priority. Huntress calls the pattern rare but seen outside this campaign, so verify each device before removing it. - Review MFA changes. Look for method deletions followed by a new registration. Huntress lists the "iPhone 13" authenticator label as an indicator from its one July 21 case.
- Review sign-in logs for replay. Filter for
OAuth2:TokenandCmsi:Cmsirequests where the source is hosting infrastructure, the user agent isnodeor bareMozilla/5.0, and the client is Microsoft Office or Authentication Broker. Start with those touching mailboxes or the Device Registration Service. Huntress expects some legitimate automation to match. - Treat
AADSTS53003as a signal. Huntress says the Conditional Access block happens after authentication succeeds, so it indicates a valid credential. Prioritize response by credential validity, not spray volume. - Test Conditional Access coverage. Huntress recommends requiring MFA or blocking for All Users, All Cloud Apps and All Client App types, unconditionally. It also advises restricting device-code flow with authentication-flow policies and stopping standard users from consenting to new applications.
- Audit inbox rules. Huntress flags three traits: names of one to three characters or only punctuation, conditions built on payroll or banking terms, and RSS Feeds, RSS Subscriptions or Conversation History as the destination.
- Use the indicators, but do not rely on them. Check logs for the addresses in Huntress's IOC list. Blocking the /24 covers the six main replay hosts but not the other addresses, and it does not stop credentials from being captured.