Potential Kerberos Coercion via DNS-Based SPN Spoofing

 1[metadata]
 2creation_date = "2025/06/14"
 3integration = ["system", "windows"]
 4maturity = "production"
 5updated_date = "2025/06/14"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Identifies the creation of a DNS record containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This
11pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks.
12It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse this to coerce
13victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate
14services (often the victim's own identity). This enables reflective Kerberos relay attacks, potentially resulting in
15privileged access such as NT AUTHORITY\\SYSTEM, without relying on NTLM fallback.
16"""
17from = "now-9m"
18index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
19language = "kuery"
20license = "Elastic License v2"
21name = "Potential Kerberos Coercion via DNS-Based SPN Spoofing"
22note = """## Triage and analysis
23
24> **Disclaimer**:
25> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
26
27### Investigating Potential Kerberos Coercion via DNS-Based SPN Spoofing
28
29### Possible investigation steps
30
31- Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification.
32- Inspect the ObjectDN field to identify the full distinguished name of the created DNS record. Look for entries containing Base64-encoded segments matching UWhRCA...BAAAA, which are indicative of an embedded CREDENTIAL_TARGET_INFORMATION payload used in SPN spoofing.
33- Validate the associated user or computer account responsible for the DNS record creation. Investigate whether the account has legitimate administrative access to modify DNS zones or whether it may have been compromised.
34- Correlate with DNS query logs and network telemetry to determine if the suspicious DNS hostname was later queried or resolved by other hosts on the network. A match suggests the attacker moved forward with the coercion attempt.
35- Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users.
36
37### False positive analysis
38
39- This activity is unlikely to happen legitimately.
40
41### Response and remediation
42
43- Review and remove the malicious DNS record containing the embedded CREDENTIAL_TARGET_INFORMATION Base64 payload (UWhRCA...BAAAA). Ensure that no additional coercion records exist in the same DNS zone.
44- Identify the source of the DNS modification by correlating the event with user context and host activity. Investigate whether the account used was compromised or misused.
45- Audit Kerberos ticket activity following the DNS record creation. Look for suspicious service ticket requests (Event ID 4769) or authentication attempts that could indicate a relay or privilege escalation attempt.
46- Temporarily isolate involved systems if signs of compromise or lateral movement are detected, especially if the record was successfully resolved and used for coercion.
47- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections.
48- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems.
49"""
50references = [
51    "https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025",
52    "https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/",
53    "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html",
54    "https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md",
55    "https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md",
56]
57risk_score = 73
58rule_id = "f701be14-0a36-4e9a-a851-b3e20ae55f09"
59setup = """## Setup
60
61The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
62Steps to implement the logging policy with Advanced Audit Configuration:

1
2The above policy does not cover the target object by default (we still need it to be configured to generate events), so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.

 1"""
 2severity = "high"
 3tags = [
 4    "Domain: Endpoint",
 5    "OS: Windows",
 6    "Use Case: Threat Detection",
 7    "Tactic: Credential Access",
 8    "Data Source: Active Directory",
 9    "Use Case: Active Directory Monitoring",
10    "Data Source: Windows Security Event Logs",
11    "Resources: Investigation Guide",
12]
13timestamp_override = "event.ingested"
14type = "query"
15
16query = '''
17(event.code:4662 and winlog.event_data.AdditionalInfo: *UWhRC*BAAAA*MicrosoftDNS*) or 
18(event.code:5137 and winlog.event_data.ObjectDN: *UWhRC*BAAAA*MicrosoftDNS*)
19'''
20
21
22[[rule.threat]]
23framework = "MITRE ATT&CK"
24[[rule.threat.technique]]
25id = "T1557"
26name = "Adversary-in-the-Middle"
27reference = "https://attack.mitre.org/techniques/T1557/"
28[[rule.threat.technique.subtechnique]]
29id = "T1557.001"
30name = "LLMNR/NBT-NS Poisoning and SMB Relay"
31reference = "https://attack.mitre.org/techniques/T1557/001/"
32
33
34[[rule.threat.technique]]
35id = "T1187"
36name = "Forced Authentication"
37reference = "https://attack.mitre.org/techniques/T1187/"
38
39
40[rule.threat.tactic]
41id = "TA0006"
42name = "Credential Access"
43reference = "https://attack.mitre.org/tactics/TA0006/"