M365 Token Spraying and Token Replay (Huntress)

Looks for: Any Entra sign-in (interactive or non-interactive) whose source address sits in 193.26.115.0/24, the block Huntress traced 200,000+ failed and 497 successful token-replay sign-ins to (2026-07-14 to 2026-09-22). Six addresses in the block were used one after another, so match the range, not one address. A hit with a success result means a stolen session was accepted; treat the user as compromised until sessions, MFA methods and devices are audited.

// HUNT: Entra sign-ins from the 193.26.115.0/24 token-replay range
// MITRE: T1550.001, T1078.004 | CONF: high  FP: low  COST: low
// REQUIRES: Microsoft Entra ID sign-in logs (interactive AND non-interactive) ingested into Next-Gen SIEM
// ⚠ validate in tenant: Entra sign-in field names and the repo are parser-dependent. Names below follow crowdstrike-logscale-v3 (Entra: appId, appDisplayName, userPrincipalName, ipAddress, conditionalAccessStatus, clientAppUsed). Confirm on one real row before trusting a zero result.
// FALSE POSITIVES: low. A legitimate customer of the same hosting provider is possible but rare; confirm business ownership of the address
// LOOKBACK: 90d or more (campaign ran 2026-07-14 to 2026-09-22); set with the time picker
cidr(ipAddress, subnet="193.26.115.0/24")
| sort(@timestamp, order=asc, limit=200)
| table([@timestamp, userPrincipalName, appDisplayName, appId, clientAppUsed, ipAddress, conditionalAccessStatus, "status.errorCode"], limit=200)

Looks for: Sign-ins from the other addresses Huntress named: three 1337 Services addresses outside the /24 (one continued a hijacked session, two failed to replay a revoked one), the two AiTM relay addresses, and the Interserver address that created the payroll-hiding inbox rules. The Interserver address is ordinary shared hosting, so it is a pivot, not a verdict. FP: the Interserver address can be shared by unrelated customers. Drop it from the list if your tenant sees legitimate traffic from it.

// HUNT: Entra sign-ins from named replay hosts and AiTM relays outside 193.26.115.0/24
// MITRE: T1550.001, T1557, T1090.003 | CONF: medium  FP: medium  COST: low
// REQUIRES: Microsoft Entra ID sign-in logs (interactive AND non-interactive) ingested into Next-Gen SIEM
// ⚠ validate in tenant: Entra sign-in field names and the repo are parser-dependent. Names below follow crowdstrike-logscale-v3 (Entra: appId, appDisplayName, userPrincipalName, ipAddress, conditionalAccessStatus, clientAppUsed). Confirm on one real row before trusting a zero result.
// ⚠ validate in tenant: IPv6 text may be logged in expanded form; if the relay IPv6 never matches, compare against the expanded spelling
// FALSE POSITIVES: 167.148.41.96 is shared Interserver hosting; the rest are rented or provider addresses reported by one vendor
// TUNING: remove 167.148.41.96 from values if it produces unrelated hits; treat hits on it as a pivot to the mailbox, not as proof
in(ipAddress, values=["124.198.132.33", "45.83.31.44", "192.159.99.172", "185.238.2.195", "167.148.41.96", "2400:8d60:2::1:841d:5dd"])
| sort(@timestamp, order=asc, limit=200)
| table([@timestamp, userPrincipalName, appDisplayName, clientAppUsed, ipAddress, conditionalAccessStatus, "status.errorCode"], limit=200)

Looks for: Huntress's scripted-replay tool (Build A) signed in with the Microsoft Office or Microsoft Authentication Broker client IDs, a user agent of node or a bare Mozilla/5.0, and targeted Exchange Online or the Device Registration Service. The client IDs are Microsoft constants, not campaign indicators; the discriminator is the combination. Build B (browser session replay) uses a current Chrome or Edge user agent and is not caught here: use Q1 and Q2 for it. FP: legitimate Node.js automation that uses the Office client ID against Exchange Online, and some management agents that send a bare Mozilla/5.0. Huntress says to expect some automation.

// HUNT: Scripted token replay (Build A): Office or Broker client with node or bare Mozilla/5.0 user agent against Exchange Online or Device Registration
// MITRE: T1550.001, T1098.005 | CONF: medium  FP: medium  COST: medium
// REQUIRES: Microsoft Entra ID sign-in logs, NON-interactive stream included, ingested into Next-Gen SIEM
// ⚠ validate in tenant: Entra sign-in field names and the repo are parser-dependent. Names below follow crowdstrike-logscale-v3 (Entra: appId, appDisplayName, userPrincipalName, ipAddress, conditionalAccessStatus, clientAppUsed). Confirm on one real row before trusting a zero result.
// ⚠ validate in tenant: userAgent and resourceId are Graph signIn property names; your parser may spell them differently
// Client IDs: d3590ed6... = Microsoft Office, 29d9ed98... = Microsoft Authentication Broker (Microsoft constants, not IOCs)
// Resources: 00000002-0000-0ff1-ce00-000000000000 = Exchange Online, 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 = Device Registration Service
// FALSE POSITIVES: sanctioned Node.js automation and management agents using the Office client ID
// TUNING: exclude known automation egress with | !cidr(ipAddress, subnet=["192.0.2.0/24"]) and replace the documentation range with your own; focus on rows that touch user mailboxes or the Device Registration Service
in(appId, values=["d3590ed6-52b3-4102-aeff-aad2292ab01c", "29d9ed98-a469-4536-ade2-f981bc1d605e"])
| userAgent = /^(node|Mozilla.5\.0)$/i
| in(resourceId, values=["00000002-0000-0ff1-ce00-000000000000", "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9"])
| groupBy([userPrincipalName, ipAddress, userAgent, appDisplayName], function=[count(as=Events), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)], limit=500)
| sort(Events, order=desc, limit=200)

Looks for: Sign-ins to the Device Registration Service (resource 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9), the endpoint Huntress saw used to join 48 rogue computers. Group by user and source address and read the addresses: hosting or VPN space joining a device is the signal, an office or Autopilot range is not. FP: normal device joins from corporate, home or Autopilot provisioning networks.

// HUNT: Device Registration Service sign-ins grouped by user and source address
// MITRE: T1098.005 | CONF: medium  FP: medium  COST: low
// REQUIRES: Microsoft Entra ID sign-in logs, NON-interactive stream included, ingested into Next-Gen SIEM
// ⚠ validate in tenant: Entra sign-in field names and the repo are parser-dependent. Names below follow crowdstrike-logscale-v3 (Entra: appId, appDisplayName, userPrincipalName, ipAddress, conditionalAccessStatus, clientAppUsed). Confirm on one real row before trusting a zero result.
// FALSE POSITIVES: ordinary device joins and Autopilot provisioning
// TUNING: replace the documentation range below with your corporate egress and provisioning ranges (REPLACE_WITH_CORPORATE_EGRESS_RANGES)
resourceId = "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9"
| !cidr(ipAddress, subnet=["192.0.2.0/24"])
| groupBy([userPrincipalName, ipAddress], function=[count(as=Events), count(appId, distinct=true, as=Clients), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)], limit=500)
| sort(Events, order=desc, limit=200)

Looks for: Entra audit events that add or register a device whose display name is DESKTOP-, Device- or Work Pc followed by exactly eight hex characters. Huntress counted 48 distinct DESKTOP- plus eight uppercase hex names (for example DESKTOP-54521F46); Windows' own out-of-box default is DESKTOP- plus seven alphanumerics. Huntress warns the pattern is rare but not unique to this campaign, so confirm with the device owner before deleting.

// HUNT: Entra device registered with a DESKTOP-/Device-/Work Pc plus eight hex character name
// MITRE: T1098.005 | CONF: high  FP: low  COST: low
// REQUIRES: Microsoft Entra ID audit logs ingested into Next-Gen SIEM
// ⚠ validate in tenant: Entra audit and Exchange audit field names are parser-dependent and arrays may be flattened differently. Confirm on one real row.
// ⚠ validate in tenant: activityDisplayName values and the flattened targetResources/initiatedBy field names
// FALSE POSITIVES: low. The pattern is rare but not unique to this campaign (Huntress); confirm with the device owner before deleting
// LOOKBACK: 90d or more; set with the time picker
activityDisplayName = /^(Add device|Register device)$/i
| "targetResources.displayName" = /^(DESKTOP-|Device-|Work Pc[- ]?)[0-9A-F]{8}$/i
| table([@timestamp, activityDisplayName, "targetResources.displayName", "initiatedBy.user.userPrincipalName", "initiatedBy.user.ipAddress", result], limit=200)

Looks for: Per user, a security-info deletion followed by a registration inside a three-hour span. In 19 organizations Huntress saw existing MFA methods removed and a new one registered within three hours of the first campaign sign-in; in the second wave the wipe ran through the security-info registration service and the new authenticator appeared minutes later. FP: helpdesk MFA resets and phone replacement. Check who initiated the change and whether the user asked for it.

// HUNT: Security info deleted and re-registered for the same user within 3 hours (MFA wipe and replace)
// MITRE: T1556.006, T1098.005 | CONF: high  FP: medium  COST: medium
// REQUIRES: Microsoft Entra ID audit logs ingested into Next-Gen SIEM
// ⚠ validate in tenant: Entra audit and Exchange audit field names are parser-dependent and arrays may be flattened differently. Confirm on one real row.
// ⚠ validate in tenant: the activity strings "User deleted security info" / "User registered security info" (and the Admin variants) come from the Entra Authentication Methods audit service, not from the campaign reports
// FALSE POSITIVES: helpdesk-driven MFA resets, phone replacement, new-hire registration
// TUNING: exclude helpdesk admin accounts by initiator, and require the change to follow a sign-in from an unfamiliar address (join with Q1/Q2/Q4 output)
activityDisplayName = /^(User|Admin) (deleted|registered) security info$/i
| case {
    activityDisplayName = /deleted/i | Wiped := 1 | Added := 0;
    * | Wiped := 0 | Added := 1;
  }
| groupBy(["targetResources.userPrincipalName"], function=[sum(Wiped, as=WipedCount), sum(Added, as=AddedCount), min(@timestamp, as=FirstTs), max(@timestamp, as=LastTs)], limit=500)
| WipedCount >= 1
| AddedCount >= 1
| SpanMs := LastTs - FirstTs
| test(SpanMs <= 10800000)
| sort(LastTs, order=desc, limit=200)

Looks for: Exchange audit events that create or change an inbox rule whose name is exactly one of the eight names Huntress listed. The names are case sensitive here: iT is the attacker's, IT may not be. None of these rules were created from the 1337 Services network; each came from a different rented or VPN address, so a source-address hunt will miss them. FP: a real user who names a rule s or d. Confirm with the mailbox owner and check the rule action and destination folder (Q8).

// HUNT: Inbox rule created or changed with a campaign rule name (., sss, ss, iT, ,., ........, s, d)
// MITRE: T1564.008 | CONF: high  FP: medium  COST: medium
// REQUIRES: Exchange Online audit events (Unified Audit Log) ingested into Next-Gen SIEM; mailbox auditing on
// ⚠ validate in tenant: Entra audit and Exchange audit field names are parser-dependent and arrays may be flattened differently. Confirm on one real row.
// ⚠ validate in tenant: this reads the rule name out of the raw JSON (Parameters: {"Name":"Name","Value":"..."}). UpdateInboxRules events from the Outlook client may carry the name elsewhere
// FALSE POSITIVES: a real user with a one-letter rule name
// TUNING: confirm the rule action (MarkAsRead, DeleteMessage, MoveToFolder) and destination before escalating; pair with Q8
// ⚠ validate in tenant: the normalized names event.action, user.email and source.ip (CrowdStrike Parsing Standard, ECS-aligned) depend on your tenant's M365 parser and connector version. Confirm them against your own ingested rows before trusting a zero result.
// UAL raw record names if your parser preserves them instead: Operation (event.action), UserId (user.email), ClientIP (source.ip)
event.action = /^(New-InboxRule|Set-InboxRule|UpdateInboxRules)$/i
| @rawstring = /"Name"\s*:\s*"Name"\s*,\s*"Value"\s*:\s*"(?<ruleName>[^"]+)"/
| ruleName = /^(\.|sss|ss|iT|,\.|\.{8}|s|d)$/
| table([@timestamp, user.email, event.action, ruleName, source.ip], limit=200)

Looks for: Inbox rule events whose raw record names one of the three obscure folders Huntress saw mail hidden in. These are built-in system folders that users rarely target on purpose, which is what makes the destination a better discriminator than the rule name.

// HUNT: Inbox rule event referencing RSS Feeds, RSS Subscriptions or Conversation History
// MITRE: T1564.008 | CONF: high  FP: low  COST: medium
// REQUIRES: Exchange Online audit events (Unified Audit Log) ingested into Next-Gen SIEM; mailbox auditing on
// ⚠ validate in tenant: Entra audit and Exchange audit field names are parser-dependent and arrays may be flattened differently. Confirm on one real row.
// FALSE POSITIVES: low. A user moving mail to RSS Feeds deliberately, or an RSS-reader rule
// ⚠ validate in tenant: the normalized names event.action, user.email and source.ip (CrowdStrike Parsing Standard, ECS-aligned) depend on your tenant's M365 parser and connector version. Confirm them against your own ingested rows before trusting a zero result.
// UAL raw record names if your parser preserves them instead: Operation (event.action), UserId (user.email), ClientIP (source.ip)
event.action = /^(New-InboxRule|Set-InboxRule|UpdateInboxRules)$/i
| @rawstring = /(?<hiddenFolder>RSS Feeds|RSS Subscriptions|Conversation History)/i
| table([@timestamp, user.email, event.action, hiddenFolder, source.ip], limit=200)

Looks for: The generic form of Q7: any inbox rule named with one to three characters or with only dots, commas and semicolons. Huntress told responders to look for rules with one to three character or punctuation-only names, because the operator varied them. FP: users who label rules with a letter or two. Expect a handful per thousand mailboxes.

// HUNT: Inbox rule with a 1-3 character or punctuation-only name
// MITRE: T1564.008 | CONF: medium  FP: medium  COST: medium
// REQUIRES: Exchange Online audit events (Unified Audit Log) ingested into Next-Gen SIEM; mailbox auditing on
// ⚠ validate in tenant: Entra audit and Exchange audit field names are parser-dependent and arrays may be flattened differently. Confirm on one real row.
// FALSE POSITIVES: users with terse rule names
// TUNING: exclude mailboxes that created the rule from a managed office address; keep rules that also delete, mark as read or move to a system folder
// ⚠ validate in tenant: the normalized names event.action, user.email and source.ip (CrowdStrike Parsing Standard, ECS-aligned) depend on your tenant's M365 parser and connector version. Confirm them against your own ingested rows before trusting a zero result.
// UAL raw record names if your parser preserves them instead: Operation (event.action), UserId (user.email), ClientIP (source.ip)
event.action = /^(New-InboxRule|Set-InboxRule|UpdateInboxRules)$/i
| @rawstring = /"Name"\s*:\s*"Name"\s*,\s*"Value"\s*:\s*"(?<ruleName>[^"]{1,3}|[.,;]{2,})"/
| table([@timestamp, user.email, event.action, ruleName, source.ip], limit=200)

Looks for: Rules whose criteria mention payroll, direct deposit, bank or bonus and whose actions delete, mark read or move mail. Huntress saw rule s catch exactly those words, then rule d hide an outside accountant's replies. The attacker's goal was a payroll-diversion style business email compromise. FP: finance and HR staff who legitimately file payroll mail into folders.

// HUNT: Inbox rule matching payroll / direct deposit / bank / bonus that also deletes, marks read or moves mail
// MITRE: T1564.008, T1114.003 | CONF: medium  FP: medium  COST: medium
// REQUIRES: Exchange Online audit events (Unified Audit Log) ingested into Next-Gen SIEM; mailbox auditing on
// ⚠ validate in tenant: Entra audit and Exchange audit field names are parser-dependent and arrays may be flattened differently. Confirm on one real row.
// FALSE POSITIVES: finance and HR users filing payroll mail
// TUNING: exclude known payroll and finance mailboxes by user.email, or require a hide action plus an unfamiliar source.ip
// ⚠ validate in tenant: the normalized names event.action, user.email and source.ip (CrowdStrike Parsing Standard, ECS-aligned) depend on your tenant's M365 parser and connector version. Confirm them against your own ingested rows before trusting a zero result.
// UAL raw record names if your parser preserves them instead: Operation (event.action), UserId (user.email), ClientIP (source.ip)
event.action = /^(New-InboxRule|Set-InboxRule|UpdateInboxRules)$/i
| @rawstring = /(payroll|direct deposit|bonus|\bbank\b)/i
| @rawstring = /(DeleteMessage|MarkAsRead|MoveToFolder|SoftDeleteMessage)/
| table([@timestamp, user.email, event.action, source.ip], limit=200)

Looks for: Security-info registration events whose raw record carries the label iPhone 13 or the full device token Huntress listed for the attacker's authenticator. The token is the high-confidence half; the label alone matches every legitimate iPhone 13 owner, so correlate with Q6, Q4 and an unfamiliar sign-in before acting. FP: any user with an iPhone 13 enrolling the Authenticator app normally.

// HUNT: Authenticator method registered as "iPhone 13" or with the reported attacker device token
// MITRE: T1556.006, T1098.005 | CONF: medium  FP: medium  COST: low
// REQUIRES: Microsoft Entra ID audit logs ingested into Next-Gen SIEM
// ⚠ validate in tenant: Entra audit and Exchange audit field names are parser-dependent and arrays may be flattened differently. Confirm on one real row.
// FALSE POSITIVES: genuine iPhone 13 owners enrolling the Authenticator app
// TUNING: the apns2- token is the high-confidence match; treat the label alone as a pivot and compare with the user's known devices
activityDisplayName = /security info/i
| @rawstring = /(iPhone 13|apns2-d8a3fedb1a3cd1287ca47c6851a49e6052ab6116b43666e674765ca892d798ce)/
| table([@timestamp, activityDisplayName, "targetResources.userPrincipalName", "initiatedBy.user.ipAddress", result], limit=200)

Looks for: Error 53003 means Conditional Access stopped a sign-in AFTER the credential was accepted, so the credential or token is valid; Huntress says to treat it as a sign of compromise, not a save. Error 50133 (SsoArtifactRevoked) is what a replay of an already-revoked session returns; the operator retried one such session three more times. Rank users by distinct source addresses, and prioritize by credential validity, not by spray volume. FP: 53003 is common for legitimate users who trip a location or device policy. 50133 follows ordinary password changes.

// HUNT: Sign-in errors 53003 (blocked by Conditional Access, credential valid) and 50133 (revoked session replay)
// MITRE: T1550.001, T1078.004 | CONF: medium  FP: medium  COST: medium
// REQUIRES: Microsoft Entra ID sign-in logs (interactive AND non-interactive) ingested into Next-Gen SIEM
// ⚠ validate in tenant: Entra sign-in field names and the repo are parser-dependent. Names below follow crowdstrike-logscale-v3 (Entra: appId, appDisplayName, userPrincipalName, ipAddress, conditionalAccessStatus, clientAppUsed). Confirm on one real row before trusting a zero result.
// ⚠ validate in tenant: the error code may be a string or a number, and its field name varies (status.errorCode, ResultType, resultType)
// FALSE POSITIVES: users tripping location or device Conditional Access; password-change aftermath
// TUNING: raise SrcIPs to 3 or more, or require one of the addresses to be unfamiliar or in the Q1/Q2 lists
"status.errorCode" = /^(53003|50133)$/
| groupBy([userPrincipalName], function=[count(as=Events), count(ipAddress, distinct=true, as=SrcIPs), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)], limit=500)
| SrcIPs >= 2
| sort(Events, order=desc, limit=200)

Looks for: Endpoint telemetry helps here only for the victim side. A managed host that connects to the AiTM relay address 185.238.2.195 (or the IPv6 relay) was used to open the fake sign-in page. The relay's hostname was not published, so an address match is the only anchor, and a clean result does not clear the host. Connections to the 193.26.115.0/24 replay range from a managed host are unexpected for the same reason.

// HUNT: Managed host connecting to AiTM relay or token-replay addresses
// MITRE: T1557, T1566.002 | CONF: medium  FP: low  COST: low
// REQUIRES: Falcon sensor network telemetry (NetworkConnectIP4, NetworkConnectIP6)
// FALSE POSITIVES: low. The addresses are single-vendor, perishable and hosting-provider space; a relay address can be reassigned
// LOOKBACK: 90d or more; set with the time picker
#event_simpleName = /^(NetworkConnectIP4|NetworkConnectIP6)$/
| (RemoteAddressIP4 = /^(185\.238\.2\.195|193\.26\.115\.[0-9]{1,3}|124\.198\.132\.33|45\.83\.31\.44|192\.159\.99\.172)$/ or RemoteAddressIP6 = "2400:8d60:2::1:841d:5dd")
| table([@timestamp, ComputerName, aid, ContextBaseFileName, RemoteAddressIP4, RemoteAddressIP6, RemotePort], limit=200)

Looks for: DNS lookups for exy.sh, rdp.sh and starkrdp.io from managed hosts. These are commercial virtual-server rental services, not malware domains: the sources link the operator's hosting company to them, and The Hacker News says the services were operating again after the January 2025 seizure. A lookup shows someone on the host reached the service, which is an enrichment signal at best. It must never be a block. FP: any admin or developer who legitimately rents a server from these services.

// HUNT: DNS lookups for exy.sh, rdp.sh, starkrdp.io (commercial RDP rental services, enrichment only)
// MITRE: T1090.003 | CONF: low  FP: medium  COST: low
// REQUIRES: Falcon sensor DNS telemetry (DnsRequest)
// FALSE POSITIVES: legitimate use of these rental services
// TUNING: hunt and enrich only, never block; these are legitimate-service domains. Exclude known admin hosts by ComputerName
#event_simpleName = DnsRequest
| DomainName = /(^|\.)(exy\.sh|rdp\.sh|starkrdp\.io)$/i
| groupBy([ComputerName, aid, DomainName], function=[count(as=Lookups), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)], limit=200)
| sort(Lookups, order=desc, limit=200)

Looks for: The 48 rogue devices were fake directory entries, so no sensor runs on them. This query answers the opposite question: which REAL managed hosts already carry a DESKTOP- plus eight uppercase hex name? Use the list to separate genuine machines from rogue Entra registrations when you audit the device list (Q5), so a legitimate host is not deleted by mistake. FP: imaged or renamed fleets that legitimately use this pattern.

// HUNT: Managed hosts with a DESKTOP- plus eight uppercase hex name (reconcile against rogue Entra devices)
// MITRE: T1098.005 | CONF: low  FP: medium  COST: medium
// REQUIRES: Falcon sensor process telemetry (ProcessRollup2)
// FALSE POSITIVES: fleets imaged or renamed to this pattern
// TUNING: this is an inventory reconciliation aid, not a detection; compare its output with Q5 and the Entra device list before deleting anything
#event_simpleName = ProcessRollup2
| ComputerName = /^DESKTOP-[0-9A-F]{8}$/
| groupBy([ComputerName, aid], function=[count(as=Processes), max(@timestamp, as=LastSeen)], limit=500)
| sort(LastSeen, order=desc, limit=200)