Potential Kerberos SPN Spoofing via Suspicious DNS Query

  1[metadata]
  2creation_date = "2025/06/14"
  3integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/04/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies queries for a DNS name containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern
 11corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is
 12associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse such names to coerce
 13victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate
 14services (often the victim's own identity). Depending on the coerced service and negotiated authentication, this can
 15support Kerberos relay or NTLM reflection/relay paths without relying on normal NTLM fallback behavior.
 16"""
 17from = "now-9m"
 18index = [
 19    "endgame-*",
 20    "logs-crowdstrike.fdr*",
 21    "logs-endpoint.events.network-*",
 22    "logs-sentinel_one_cloud_funnel.*",
 23    "logs-windows.sysmon_operational-*",
 24]
 25language = "eql"
 26license = "Elastic License v2"
 27name = "Potential Kerberos SPN Spoofing via Suspicious DNS Query"
 28references = [
 29    "https://www.synacktiv.com/en/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025.html",
 30    "https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/",
 31    "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html",
 32    "https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md",
 33    "https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md",
 34]
 35risk_score = 73
 36rule_id = "99ac5005-8a9e-4625-a0af-5f7bb447204b"
 37severity = "high"
 38tags = [
 39    "Domain: Endpoint",
 40    "OS: Windows",
 41    "Use Case: Threat Detection",
 42    "Tactic: Credential Access",
 43    "Data Source: Elastic Defend",
 44    "Data Source: Elastic Endgame",
 45    "Data Source: Crowdstrike",
 46    "Data Source: SentinelOne",
 47    "Data Source: Sysmon",
 48    "Resources: Investigation Guide",
 49]
 50timestamp_override = "event.ingested"
 51type = "eql"
 52
 53query = '''
 54network where host.os.type == "windows" and dns.question.name : "*UWhRC*BAAAA*"
 55'''
 56
 57note = """## Triage and analysis
 58
 59### Investigating Potential Kerberos SPN Spoofing via Suspicious DNS Query
 60
 61#### Possible investigation steps
 62
 63- What exact marshaled-target DNS name did the host query, and did it resolve?
 64  - Focus: DNS event subtype and status: `event.action`, `dns.question.name`, `dns.question.type`, `dns.Ext.status`, and `dns.resolved_ip`.
 65  - Hint: record the full case-preserved `dns.question.name`; the UWhRC...BAAAA marker is the marshaled CREDENTIAL_TARGET_INFORMATION SPN-spoofing anchor.
 66  - Implication: escalate when the marker is intact and a successful result returns one or more `dns.resolved_ip` values; treat failed or request-only lookups as unresolved, not benign. Lower suspicion only after FP criteria confirm authorized testing for the exact name and host.
 67
 68- Which local process or Windows component generated the DNS lookup?
 69  - Focus: alert event and same-process start event for `host.id` and `process.entity_id`: `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.executable`.
 70  - Hint: if these fields are sparse on the DNS event, query process events for the same `host.id` and `process.entity_id` around `@timestamp` before judging lineage. $investigate_3
 71  - Implication: escalate when a normal Windows service, browser, RPC client, SMB client, or WebDAV component resolves the marker without test context because it may be a coerced victim; also escalate when `process.command_line` exposes relay or coercion tooling such as RemoteKrbRelay, PetitPotam, krbrelayx, dnstool, Pretender, or wspcoerce. Lower suspicion only when identity and lineage match the same recognized test workflow.
 72
 73- Which host and principal anchors define containment and scope?
 74  - Focus: alert host and principal anchors: `host.id`, `host.name`, `user.id`, `user.name`, and `user.domain`.
 75  - Implication: use these anchors to scope related alerts, connection events, containment, and testing confirmation; do not lower suspicion on a familiar host or user without DNS, process, and destination alignment. Escalate priority when later connection or related-alert evidence uses the same anchors.
 76
 77- Did the host connect to an IP returned by the suspicious DNS lookup?
 78  - Focus: process-scoped network events for `host.id` and `process.entity_id`, correlating `dns.resolved_ip` from DNS results to connection-event `destination.ip`, `destination.port`, and `network.direction`. $investigate_0
 79  - Hint: if a resolver helper, proxy, or service split separates lookup and connection, widen to same-host connections for the recovered IPs after the DNS result.
 80  - Implication: escalate when the same process or host reaches a recovered IP, especially on relay-relevant services such as SMB, LDAP/LDAPS, HTTP/ADCS, RPC, or WinRM. Missing network telemetry is unresolved, not benign; DNS-only evidence still requires process and host explanation.
 81
 82- Does the resolved destination fit a relay path rather than recognized test infrastructure?
 83  - Focus: connection-event `destination.ip`, `destination.port`, `destination.as.organization.name`, and `destination.geo.country_iso_code` for IPs recovered from the prior DNS result.
 84  - Hint: ASN and geo enrichment are expected mainly for public destinations; missing enrichment on private or loopback IPs is unresolved, not benign.
 85  - Implication: escalate when the recovered IP is public or paired with relay-relevant ports that do not match confirmed testing evidence; if enrichment points to private, internal, or familiar infrastructure, carry it into FP validation instead of closing on ownership alone.
 86
 87- If local evidence remains suspicious or unresolved, where else does the same activity appear?
 88  - Focus: related alerts for `host.id` covering credential access, forced authentication, relay, lateral movement, or staging. $investigate_1
 89  - Hint: then check whether the same `dns.question.name` appears on other hosts to separate one-host testing from shared relay infrastructure. $investigate_2
 90  - Implication: broaden scope when the same host shows coercion or staging alerts, or when the exact encoded hostname appears on unrelated hosts; keep the case bounded when recurrence stays inside one confirmed test cohort.
 91
 92- Escalate when the marshaled DNS marker plus process, host, destination, connection, or related-alert evidence indicates unauthorized relay or coercion; close only when DNS, process, host, destination, and scope evidence all align with one confirmed authorized security-testing workflow; preserve evidence and escalate when evidence is mixed or incomplete.
 93
 94### False positive analysis
 95
 96- Authorized red-team, purple-team, relay-lab validation, or security-research harnesses can generate this marker. Confirm only when the exact `dns.question.name`, process identity, parent context, `host.id`, user context, resolved destination, and related-alert scope all align with the same exercise. Use exercise records or owner confirmation as corroboration when telemetry alone cannot prove authorization; do not close solely on recurrence unless it stays inside a confirmed test cohort.
 97- Build exceptions from the minimum confirmed workflow pattern: `process.executable`, `process.pe.original_file_name`, `process.parent.executable`, `host.id`, user or test cohort, and recognized destination pattern. Avoid exceptions on `dns.question.name` alone, host alone, destination ownership alone, or broad tool names.
 98
 99### Response and remediation
100
101- If confirmed benign, reverse temporary containment and document the exact DNS marker, tool identity, parent context, host scope, user or test cohort, and destination pattern. Create an exception only after the same confirmed workflow proves stable across prior alerts.
102- If suspicious but unconfirmed, preserve the alert and DNS events, exact `dns.question.name`, recovered `dns.resolved_ip` values, process tree, host and user context, connection events, and linked alert IDs before containment. Apply reversible containment tied to the findings, such as temporarily blocking the encoded hostname or recovered IPs, tightening outbound access from the affected host, or increasing monitoring; escalate to host isolation only when follow-on connectivity, relay evidence, or privileged-host exposure makes the risk unacceptable.
103- If confirmed malicious, capture volatile endpoint state and process details before termination or cleanup, then isolate the host when identity, destination, or follow-on connection evidence confirms relay or coercion. Block or sinkhole the malicious hostname and recovered IPs, and remove malicious AD DNS records only after confirming record ownership or tampering evidence.
104- If separate asset or incident context confirms the affected host or principal is identity infrastructure or privileged administration scope, activate the identity or Active Directory compromise response plan, scope machine-account or service-account exposure tied to the preserved host, user, destination, and related-alert evidence, and review related relay or forced-authentication activity on surrounding systems.
105- Eradicate only the unauthorized tooling, scripts, scheduled tasks, service changes, or DNS records uncovered during the investigation, then remediate the access path or permissions that allowed the coercion record or tool to be introduced.
106- After containment, hunt for the same encoded hostname pattern, recovered IPs, and process lineage across other hosts.
107"""
108
109setup = """## Setup
110
111This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
112
113Setup instructions: https://ela.st/install-elastic-defend
114
115### Additional data sources
116
117This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
118
119- [CrowdStrike](https://ela.st/crowdstrike-integration)
120- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
121- [Sysmon Event ID 22 - DNS Query](https://ela.st/sysmon-event-22-setup)
122"""
123
124[rule.investigation_fields]
125field_names = [
126    "@timestamp",
127    "host.id",
128    "user.name",
129    "process.entity_id",
130    "process.executable",
131    "process.command_line",
132    "process.pe.original_file_name",
133    "process.code_signature.subject_name",
134    "process.parent.executable",
135    "dns.question.name",
136    "dns.Ext.status",
137    "dns.resolved_ip",
138    "destination.ip",
139    "destination.port",
140    "network.direction",
141]
142
143[[transform.investigate]]
144label = "Network events for the same process"
145description = ""
146providers = [
147  [
148    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
149    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
150    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
151  ]
152]
153relativeFrom = "now-1h"
154relativeTo = "now"
155
156[[transform.investigate]]
157label = "Alerts associated with the host"
158description = ""
159providers = [
160  [
161    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
162    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
163  ]
164]
165relativeFrom = "now-48h/h"
166relativeTo = "now"
167
168[[transform.investigate]]
169label = "DNS and network events involving the same DNS name"
170description = ""
171providers = [
172  [
173    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
174    { excluded = false, field = "dns.question.name", queryType = "phrase", value = "{{dns.question.name}}", valueType = "string" }
175  ]
176]
177relativeFrom = "now-48h/h"
178relativeTo = "now"
179
180[[transform.investigate]]
181label = "Process events for the DNS lookup process"
182description = ""
183providers = [
184  [
185    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
186    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
187    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
188  ]
189]
190relativeFrom = "now-1h"
191relativeTo = "now"
192
193[[rule.threat]]
194framework = "MITRE ATT&CK"
195[[rule.threat.technique]]
196id = "T1557"
197name = "Adversary-in-the-Middle"
198reference = "https://attack.mitre.org/techniques/T1557/"
199[[rule.threat.technique.subtechnique]]
200id = "T1557.001"
201name = "LLMNR/NBT-NS Poisoning and SMB Relay"
202reference = "https://attack.mitre.org/techniques/T1557/001/"
203
204[[rule.threat.technique]]
205id = "T1187"
206name = "Forced Authentication"
207reference = "https://attack.mitre.org/techniques/T1187/"
208
209[rule.threat.tactic]
210id = "TA0006"
211name = "Credential Access"
212reference = "https://attack.mitre.org/tactics/TA0006/"