Detection engineering for token replay should start with successful request shape
A token replay campaign can generate hundreds of thousands of failed sign-ins while the decisive events are a smaller number of successful token exchanges. Huntress made that point directly in its Microsoft 365 investigation. One address produced 1,052 blocked sign-ins across four organizations and 232 successful sign-ins across 28 different organizations, with no overlap between the groups. Ranking tenants by failed-spray volume would have directed responders away from the organizations where authentication succeeded.
The campaign ran from July 14 to September 22, 2026. Huntress reported 497 successful sign-ins across 79 organizations, more than 200,000 failed attempts, 97 compromised accounts, 48 rogue Entra devices, and MFA replacement at 19 organizations. These figures describe one provider's customer cases, not the full population of Microsoft 365 tenants.
What to detect
Huntress grouped the replay activity around OAuth2 token requests and the node user agent, with Microsoft Office and Microsoft Authentication Broker client IDs. It also reported Cmsi:Cmsi sign-ins for device-code and broker flows, including bare Mozilla/5.0 user agents in one phase. The actor requested access to Microsoft Graph, Exchange Online, SharePoint Online, and the Device Registration Service.
Those attributes are useful only in context. Many legitimate automation processes use node, Microsoft client IDs, and Graph. Build a baseline by application, user population, device type, network, and time of day. Then prioritize successful token activity from hosting infrastructure that is unusual for the account and followed by mailbox, device, or MFA changes.
The campaign's AADSTS53003 blocks deserve careful treatment. Huntress notes that a Conditional Access block happens after authentication succeeds. It can indicate a valid credential reached policy. That makes the block useful evidence of token validity, even though the attempt failed. A detection that counts only success may miss it, while a detection that treats every block as noise may hide a strong signal.
Separate volume from consequence
Failed password spray is noisy. Token replay starts with a session that already passed authentication and MFA. The defender should look for the point where identity material becomes usable: token issuance, interactive or non-interactive sign-in, token exchange, and application access. The severity rises when the session produces a mailbox operation, device registration, MFA change, or new application consent.
Use a sequence model rather than a single-event alert. A possible sequence is AiTM authentication, a short delay, token use from hosting, mailbox access, and an authentication-method change. Another is device-code authorization, broker sign-in, device registration, and token use. The actual order and timing must come from the tenant's logs, not from a generic playbook.
Add external infrastructure context
ZoomEye returned 2,601 all-scope observations for cidr="193.26.115.0/24" at 2026-11-10T14:39:47Z. The exact hosts ip="193.26.115.221" and ip="193.26.115.72" returned 13 and 12 observations. The AiTM relay ip="185.238.2.195" returned 15, and asn="210558" returned 29,079.
These observations help an analyst decide which network scopes to retain in detection content. The exact hosts support high-confidence lookup. The CIDR supports campaign-level correlation. The ASN supplies provider context and a much broader review scope. None of the counts describe a successful authentication or prove current ownership.
Store the query, timestamp, and result with the detection record. Infrastructure changes quickly, and a later analyst needs to know whether a rule used a count from the campaign window or a review months afterward. Keep tenant evidence and public observations in separate fields so one cannot silently replace the other.
Tests that show whether the rule works
Build test cases for the sequence, not only the indicator. Include a successful token request from a known hosting range followed by mailbox access. Include a device-code sign-in followed by a new device. Include a Conditional Access block after a valid token was presented. Include legitimate automation from the same client application so the team can measure false positives.
Run the tests against historical telemetry without changing production alerts. Record which rule fired, which evidence fields were available, and what the analyst would need to confirm the event. A rule that depends on a user agent alone will be weak because user agents can be changed. A rule that depends on a single IP will age quickly. A sequence that combines identity context, application access, and post-authentication change gives the analyst a stronger decision point.
Finally, assign an owner and a review date to every detection. If the rule fails its sequence test or cannot retrieve the required log fields, it is not ready for production. The goal is not to reproduce the campaign's IOC list. It is to detect the behavior that makes a stolen session useful.
Top comments (0)