Turning token replay indicators into a repeatable exposure review
A case that starts with one suspicious IP often ends with a list of addresses, client IDs, user agents, domains, and mailbox artifacts. The harder task is deciding which observations belong in the next review and which should expire with the case. The Microsoft 365 token replay research from Huntress is a useful example because it gives exact hosts, a campaign CIDR, a hosting provider, and several later-stage identity behaviors.
Huntress observed 497 successful sign-ins at 79 organizations from July 14 to September 22, 2026. It also reported more than 200,000 failed attempts, 97 compromised accounts, 48 rogue Entra devices, and MFA replacement at 19 organizations. The source does not identify the tenants. Any internal comparison must therefore start with the organization's own logs.
Record the question behind each indicator
An exact replay address answers a narrow question: did this account or asset communicate with that host during the relevant period? A campaign CIDR asks whether related addresses appear in the same evidence set. A hosting ASN asks about provider context and broader patterns. A client ID or user agent asks whether the authentication request resembled the observed tooling.
These are different questions and should not share one confidence label. The exact address can produce a high-confidence lookup if it matches the incident. The ASN can produce a large review queue and a high false-positive burden. The CIDR sits between them. Label the scope in the case record so another analyst can reproduce the reasoning.
Keep a dated measurement ledger
ZoomEye returned 2,601 all-scope observations for cidr="193.26.115.0/24" at 2026-11-10T14:39:47Z. Exact-address observations were 13 for ip="193.26.115.221", 12 for ip="193.26.115.72", and 15 for the AiTM relay ip="185.238.2.195". The provider query asn="210558" returned 29,079.
Store the query text, scope, timestamp, count, and interpretation for each row. A later review may produce a different count. That is not necessarily a sign that the infrastructure changed in a meaningful way; indexing, network assignment, and services can all change. The ledger preserves the observation and prevents an analyst from comparing counts taken with different scopes as if they were the same measurement.
The ledger should also state what the count cannot answer. None of these results identifies a victim, a compromised account, or a currently active replay service. A public service in the same range may belong to an unrelated customer. An absent service does not prove that the operator stopped using the address. These limits belong next to the numbers, not in a separate disclaimer section.
Connect infrastructure to identity evidence
Start with the tenant's sign-in and audit logs. Filter by the exact hosts first, then the CIDR, then the ASN as a broader review. Add the request type, client application, user agent, account, device, session, and result. A broad network match becomes meaningful only when the identity record also supports the connection.
For each confirmed or suspected case, record the defensive consequence. A successful token request may require session revocation. A device registration may require a device audit. An MFA change may require user verification and method removal. A mailbox rule may require message and fraud review. The response action depends on the event, not on the public scan count.
The review also needs a decision owner. Security operations can collect the evidence and recommend containment. The identity platform owner can revoke sessions and remove methods. The messaging owner can inspect mailbox configuration. Finance or legal may need to join if the mailbox action involved payment fraud. A list of indicators without named owners tends to stop at the analysis stage.
Review the workflow after the incident
Schedule a short follow-up after the main response. Check whether each source query still answers a useful question, whether the data is retained long enough for an investigation, and whether the detection fields are available without manual collection. Retire indicators that only repeat the same exact-host lookup. Keep the scope relationships that help an analyst move from a specific event to a justified broader review.
Test the workflow with a new fictional case. Give the team one relay address, one replay address, a campaign CIDR, and a set of client attributes. Ask for a written decision about what to query, what internal logs to collect, and what evidence would justify containment. A coherent answer shows that the workflow is usable. A collection of saved searches without decision rules does not.
The final artifact should be a case package: dated ZoomEye observations, source references, internal evidence links, response actions, owners, and verification results. That package helps the next analyst reuse the method without inheriting an unsupported claim about victims.
Top comments (0)