Potential Kerberos SPN Spoofing via Suspicious DNS Query

[metadata]
creation_date = "2025/06/14"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/04/24"

[rule]
author = ["Elastic"]
description = """
Identifies queries for a DNS name containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern
corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is
associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse such names to coerce
victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate
services (often the victim's own identity). Depending on the coerced service and negotiated authentication, this can
support Kerberos relay or NTLM reflection/relay paths without relying on normal NTLM fallback behavior.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.network-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-windows.sysmon_operational-*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Kerberos SPN Spoofing via Suspicious DNS Query"
references = [
    "https://www.synacktiv.com/en/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025.html",
    "https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/",
    "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html",
    "https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md",
    "https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md",
]
risk_score = 73
rule_id = "99ac5005-8a9e-4625-a0af-5f7bb447204b"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
network where host.os.type == "windows" and dns.question.name : "*UWhRC*BAAAA*"
'''

note = """## Triage and analysis

### Investigating Potential Kerberos SPN Spoofing via Suspicious DNS Query

#### Possible investigation steps

- What exact marshaled-target DNS name did the host query, and did it resolve?
  - Focus: DNS event subtype and status: `event.action`, `dns.question.name`, `dns.question.type`, `dns.Ext.status`, and `dns.resolved_ip`.
  - Hint: record the full case-preserved `dns.question.name`; the UWhRC...BAAAA marker is the marshaled CREDENTIAL_TARGET_INFORMATION SPN-spoofing anchor.
  - 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.

- Which local process or Windows component generated the DNS lookup?
  - 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`.
  - 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
  - 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.

- Which host and principal anchors define containment and scope?
  - Focus: alert host and principal anchors: `host.id`, `host.name`, `user.id`, `user.name`, and `user.domain`.
  - 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.

- Did the host connect to an IP returned by the suspicious DNS lookup?
  - 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
  - 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.
  - 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.

- Does the resolved destination fit a relay path rather than recognized test infrastructure?
  - 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.
  - Hint: ASN and geo enrichment are expected mainly for public destinations; missing enrichment on private or loopback IPs is unresolved, not benign.
  - 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.

- If local evidence remains suspicious or unresolved, where else does the same activity appear?
  - Focus: related alerts for `host.id` covering credential access, forced authentication, relay, lateral movement, or staging. $investigate_1
  - Hint: then check whether the same `dns.question.name` appears on other hosts to separate one-host testing from shared relay infrastructure. $investigate_2
  - 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.

- 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.

### False positive analysis

- 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.
- 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.

### Response and remediation

- 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.
- 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.
- 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.
- 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.
- 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.
- After containment, hunt for the same encoded hostname pattern, recovered IPs, and process lineage across other hosts.
"""

setup = """## Setup

This 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.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 22 - DNS Query](https://ela.st/sysmon-event-22-setup)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "user.name",
    "process.entity_id",
    "process.executable",
    "process.command_line",
    "process.pe.original_file_name",
    "process.code_signature.subject_name",
    "process.parent.executable",
    "dns.question.name",
    "dns.Ext.status",
    "dns.resolved_ip",
    "destination.ip",
    "destination.port",
    "network.direction",
]

[[transform.investigate]]
label = "Network events for the same process"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "DNS and network events involving the same DNS name"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
    { excluded = false, field = "dns.question.name", queryType = "phrase", value = "{{dns.question.name}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Process events for the DNS lookup process"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"
[[rule.threat.technique.subtechnique]]
id = "T1557.001"
name = "LLMNR/NBT-NS Poisoning and SMB Relay"
reference = "https://attack.mitre.org/techniques/T1557/001/"

[[rule.threat.technique]]
id = "T1187"
name = "Forced Authentication"
reference = "https://attack.mitre.org/techniques/T1187/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"