Potential Kerberos Coercion via DNS-Based SPN Spoofing
Identifies directory-service access or creation events involving a MicrosoftDNS record that contains a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This blob pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure associated with DNS-based SPN spoofing used in Kerberos coercion tradecraft. Adversaries may abuse such records to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/06/14"
3integration = ["system", "windows"]
4maturity = "production"
5updated_date = "2026/04/24"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies directory-service access or creation events involving a MicrosoftDNS record that contains a base64-encoded
11blob matching the pattern "UWhRCA...BAAAA". This blob pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION
12structure associated with DNS-based SPN spoofing used in Kerberos coercion tradecraft. Adversaries may abuse such
13records to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for
14legitimate services.
15"""
16from = "now-9m"
17index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
18language = "kuery"
19license = "Elastic License v2"
20name = "Potential Kerberos Coercion via DNS-Based SPN Spoofing"
21references = [
22 "https://www.synacktiv.com/en/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025.html",
23 "https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/",
24 "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html",
25 "https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md",
26 "https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md",
27]
28risk_score = 73
29rule_id = "f701be14-0a36-4e9a-a851-b3e20ae55f09"
30severity = "high"
31tags = [
32 "Domain: Endpoint",
33 "OS: Windows",
34 "Use Case: Threat Detection",
35 "Tactic: Credential Access",
36 "Data Source: Active Directory",
37 "Use Case: Active Directory Monitoring",
38 "Data Source: Windows Security Event Logs",
39 "Resources: Investigation Guide",
40]
41timestamp_override = "event.ingested"
42type = "query"
43
44query = '''
45host.os.type:"windows" and
46(
47 (event.code:4662 and winlog.event_data.AdditionalInfo: *UWhRC*BAAAA*MicrosoftDNS*) or
48 (event.code:5137 and winlog.event_data.ObjectDN: *UWhRC*BAAAA*MicrosoftDNS*)
49)
50'''
51
52note = """## Triage and analysis
53
54### Investigating Potential Kerberos Coercion via DNS-Based SPN Spoofing
55
56#### Possible investigation steps
57
58- Which ADIDNS record or access event matched the coercion blob?
59 - Focus: `event.code`, `winlog.event_data.AdditionalInfo`, `winlog.event_data.ObjectDN`, `winlog.event_data.DSName`, and `winlog.computer_name` to place the marshaled CREDENTIAL_TARGET_INFORMATION blob in its MicrosoftDNS partition.
60 - Implication: a namespace used by real clients makes the alert high priority; a lab-only namespace reduces urgency only when later telemetry stays bounded.
61
62- Which account and logon session touched the record?
63 - Focus: `user.id`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`.
64 - Hint: match `winlog.event_data.SubjectLogonId` on the same domain controller to authentication events where `winlog.event_data.TargetLogonId` matches, then read `source.ip` and `winlog.logon.type`. $investigate_2 Missing authentication telemetry is unresolved, not benign.
65 - Implication: an actor, source, or logon type outside the DNS or directory-administration tier raises concern; a lab-scoped account, source, and session lowers suspicion only when the change set and authentication evidence also stay bounded.
66
67- Did the same session make adjacent MicrosoftDNS changes that show setup or cleanup?
68 - Why: Kerberos coercion setups can create, alter, and remove DNS objects around the single blob-bearing event.
69 - Focus: start with surrounding directory-service events for the same `winlog.event_data.SubjectLogonId`, then narrow manually with `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.OpCorrelationID`, and `winlog.event_data.AttributeLDAPDisplayName`.
70 - Hint: use `winlog.event_data.AttributeValue` to identify added record data or cleanup values when the source logged them, and expect to filter unrelated same-session directory activity manually. $investigate_3
71 - Implication: coordinated creation, modification, or deletion supports coercion preparation; one bounded change is less concerning only when it matches the same validation scope.
72
73- Could the spoofed name coerce Kerberos from valuable systems or services?
74 - Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.AdditionalInfo`, and `winlog.event_data.DSName` for the spoofed hostname and ADIDNS zone.
75 - Implication: names resembling real servers, management systems, service SPN targets, or broad discovery labels increase relay risk; names isolated from real consumers carry lower practical risk.
76
77- Do Windows Security authentication events show the coercion progressed?
78 - Focus: after the directory-service event, review Windows Security logon or explicit-credential events with `event.code`, `winlog.event_data.TargetServerName`, `winlog.event_data.TargetInfo`, and `winlog.event_data.AuthenticationPackageName` tied to the spoofed hostname or expected target service.
79 - Hint: use `source.ip`, `winlog.event_data.TargetUserName`, and `winlog.computer_name` to identify victim systems and relay targets. Missing authentication telemetry is unresolved, not benign.
80 - Implication: escalate as progressed coercion when Kerberos or service access follows the record creation, especially from machine accounts or management systems; treat it as attempted-only when authentication evidence remains absent and the local record evidence is otherwise bounded.
81
82- Is the suspicious pattern isolated to this actor and domain controller?
83 - Focus: related relay, directory-service, credential-access, or privilege-escalation alerts for `user.id`. $investigate_0
84 - Hint: compare alerts on the logging domain controller's `host.id` for the same behavior families. $investigate_1
85 - Implication: expand case scope when the same actor or controller has related suspicious alerts; keep scope local when no related alerts contradict the locally validated test scope.
86
87- What disposition is supported?
88 - Focus: record scope, actor/session, MicrosoftDNS change set, authentication progression, and related-alert scope.
89 - Implication: escalate when a meaningful blob-bearing record, abnormal actor/session, adjacent MicrosoftDNS changes, or follow-on Kerberos/service activity supports coercion; close only when telemetry binds those categories to a lab or security-test workflow, with external validation required for any legitimacy claim telemetry cannot prove; preserve and escalate when evidence is mixed or incomplete.
90
91### False positive analysis
92
93- Authorized security testing or lab validation can create CredMarshalTargetInfo-style ADIDNS records. Confirm by verifying that `winlog.event_data.ObjectDN` is in the test namespace named by the validation record, `user.id` or `winlog.event_data.SubjectUserSid` matches the named operator, the MicrosoftDNS change set stays bounded, and Windows Security authentication events stay inside the stated victim and target scope. If validation records are unavailable and telemetry cannot prove that exact workflow, keep the alert unresolved instead of closing on recurrence alone.
94- Build exceptions from the minimum confirmed pattern: stable `user.id` or `winlog.event_data.SubjectUserSid`, the specific zone path in `winlog.event_data.ObjectDN`, and the logging `host.id`. Avoid exceptions on event codes 4662 or 5137, all MicrosoftDNS changes, or the blob pattern alone.
95
96### Response and remediation
97
98- If confirmed benign, reverse any temporary containment and document the recognized operator, ADIDNS zone or record pattern, and lab-only authentication scope that confirmed the security-test workflow. Create an exception only after the same actor, zone pattern, and domain-controller scope recur.
99- If suspicious but unconfirmed, preserve a case export of the raw Windows Security event, `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.AdditionalInfo`, the actor/session evidence, the logging domain controller, and any follow-on authentication events before containment. Export the record and surrounding zone state, then use reversible containment such as tightening the affected zone's write access or temporarily removing the actor's ability to modify MicrosoftDNS objects while scope is clarified.
100- If confirmed malicious, preserve the coercion record, surrounding MicrosoftDNS changes, and Windows Security authentication evidence tied to the spoofed name; contain the implicated account before destructive cleanup. Review the affected zone, replicating domain controllers, victim systems, and relay targets before removing the spoofing record and adjacent unauthorized DNS objects created by the same session.
101- If Kerberos, LDAP, SMB, ADCS, or other service access followed the record, reset exposed account or machine secrets as appropriate and review for RBCD, certificate enrollment, Shadow Credentials, LAPS retrieval, password changes, group changes, service creation, or interactive SMB follow-on behavior.
102- Harden by removing unnecessary ADIDNS write permissions, restricting authenticated-user access to MicrosoftDNS objects, and enforcing relay-resistant controls such as SMB signing, LDAP signing/channel binding, and EPA where applicable.
103- Retain directory-service and authentication telemetry that supported the decision, and document the confirmed workflow or malicious artifact set for future analysts.
104"""
105
106setup = """## Setup
107
108The following Windows audit policies must be enabled to generate the events used by this rule:
109- [Audit Directory Service Access](https://ela.st/audit-directory-service-access)
110- [Audit Directory Service Changes](https://ela.st/audit-directory-service-changes)
111"""
112
113[rule.investigation_fields]
114field_names = [
115 "@timestamp",
116 "event.code",
117 "host.id",
118 "winlog.computer_name",
119 "winlog.event_data.SubjectUserName",
120 "winlog.event_data.SubjectUserSid",
121 "winlog.event_data.SubjectDomainName",
122 "winlog.event_data.SubjectLogonId",
123 "winlog.event_data.ObjectDN",
124 "winlog.event_data.ObjectGUID",
125 "winlog.event_data.AdditionalInfo",
126 "winlog.event_data.DSName",
127 "winlog.event_data.OpCorrelationID",
128 "winlog.event_data.AttributeLDAPDisplayName",
129 "winlog.event_data.AttributeValue",
130]
131
132[[transform.investigate]]
133label = "Alerts associated with the creator"
134description = ""
135providers = [
136 [
137 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
138 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
139 ]
140]
141relativeFrom = "now-48h/h"
142relativeTo = "now"
143
144[[transform.investigate]]
145label = "Alerts associated with the domain controller"
146description = ""
147providers = [
148 [
149 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
150 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
151 ]
152]
153relativeFrom = "now-48h/h"
154relativeTo = "now"
155
156[[transform.investigate]]
157label = "Authentication events for the subject logon session"
158description = ""
159providers = [
160 [
161 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
162 { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
163 { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
164 ],
165 [
166 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
167 { excluded = false, field = "event.code", queryType = "phrase", value = "4648", valueType = "string" },
168 { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
169 ]
170]
171relativeFrom = "now-24h"
172relativeTo = "now"
173
174[[transform.investigate]]
175label = "MicrosoftDNS directory-service events for the same session"
176description = ""
177providers = [
178 [
179 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
180 { excluded = false, field = "event.code", queryType = "phrase", value = "4662", valueType = "string" },
181 { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
182 ],
183 [
184 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
185 { excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" },
186 { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
187 ],
188 [
189 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
190 { excluded = false, field = "event.code", queryType = "phrase", value = "5137", valueType = "string" },
191 { excluded = false, field = "winlog.event_data.SubjectLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
192 ]
193]
194relativeFrom = "now-24h"
195relativeTo = "now"
196
197[[rule.threat]]
198framework = "MITRE ATT&CK"
199[[rule.threat.technique]]
200id = "T1557"
201name = "Adversary-in-the-Middle"
202reference = "https://attack.mitre.org/techniques/T1557/"
203[[rule.threat.technique.subtechnique]]
204id = "T1557.001"
205name = "LLMNR/NBT-NS Poisoning and SMB Relay"
206reference = "https://attack.mitre.org/techniques/T1557/001/"
207
208[[rule.threat.technique]]
209id = "T1187"
210name = "Forced Authentication"
211reference = "https://attack.mitre.org/techniques/T1187/"
212
213[rule.threat.tactic]
214id = "TA0006"
215name = "Credential Access"
216reference = "https://attack.mitre.org/tactics/TA0006/"
Triage and analysis
Investigating Potential Kerberos Coercion via DNS-Based SPN Spoofing
Possible investigation steps
-
Which ADIDNS record or access event matched the coercion blob?
- Focus:
event.code,winlog.event_data.AdditionalInfo,winlog.event_data.ObjectDN,winlog.event_data.DSName, andwinlog.computer_nameto place the marshaled CREDENTIAL_TARGET_INFORMATION blob in its MicrosoftDNS partition. - Implication: a namespace used by real clients makes the alert high priority; a lab-only namespace reduces urgency only when later telemetry stays bounded.
- Focus:
-
Which account and logon session touched the record?
- Focus:
user.id,winlog.event_data.SubjectUserSid,winlog.event_data.SubjectUserName,winlog.event_data.SubjectDomainName, andwinlog.event_data.SubjectLogonId. - Hint: match
winlog.event_data.SubjectLogonIdon the same domain controller to authentication events wherewinlog.event_data.TargetLogonIdmatches, then readsource.ipandwinlog.logon.type. $investigate_2 Missing authentication telemetry is unresolved, not benign. - Implication: an actor, source, or logon type outside the DNS or directory-administration tier raises concern; a lab-scoped account, source, and session lowers suspicion only when the change set and authentication evidence also stay bounded.
- Focus:
-
Did the same session make adjacent MicrosoftDNS changes that show setup or cleanup?
- Why: Kerberos coercion setups can create, alter, and remove DNS objects around the single blob-bearing event.
- Focus: start with surrounding directory-service events for the same
winlog.event_data.SubjectLogonId, then narrow manually withwinlog.event_data.ObjectDN,winlog.event_data.ObjectGUID,winlog.event_data.OpCorrelationID, andwinlog.event_data.AttributeLDAPDisplayName. - Hint: use
winlog.event_data.AttributeValueto identify added record data or cleanup values when the source logged them, and expect to filter unrelated same-session directory activity manually. $investigate_3 - Implication: coordinated creation, modification, or deletion supports coercion preparation; one bounded change is less concerning only when it matches the same validation scope.
-
Could the spoofed name coerce Kerberos from valuable systems or services?
- Focus:
winlog.event_data.ObjectDN,winlog.event_data.AdditionalInfo, andwinlog.event_data.DSNamefor the spoofed hostname and ADIDNS zone. - Implication: names resembling real servers, management systems, service SPN targets, or broad discovery labels increase relay risk; names isolated from real consumers carry lower practical risk.
- Focus:
-
Do Windows Security authentication events show the coercion progressed?
- Focus: after the directory-service event, review Windows Security logon or explicit-credential events with
event.code,winlog.event_data.TargetServerName,winlog.event_data.TargetInfo, andwinlog.event_data.AuthenticationPackageNametied to the spoofed hostname or expected target service. - Hint: use
source.ip,winlog.event_data.TargetUserName, andwinlog.computer_nameto identify victim systems and relay targets. Missing authentication telemetry is unresolved, not benign. - Implication: escalate as progressed coercion when Kerberos or service access follows the record creation, especially from machine accounts or management systems; treat it as attempted-only when authentication evidence remains absent and the local record evidence is otherwise bounded.
- Focus: after the directory-service event, review Windows Security logon or explicit-credential events with
-
Is the suspicious pattern isolated to this actor and domain controller?
- Focus: related relay, directory-service, credential-access, or privilege-escalation alerts for
user.id. $investigate_0 - Hint: compare alerts on the logging domain controller's
host.idfor the same behavior families. $investigate_1 - Implication: expand case scope when the same actor or controller has related suspicious alerts; keep scope local when no related alerts contradict the locally validated test scope.
- Focus: related relay, directory-service, credential-access, or privilege-escalation alerts for
-
What disposition is supported?
- Focus: record scope, actor/session, MicrosoftDNS change set, authentication progression, and related-alert scope.
- Implication: escalate when a meaningful blob-bearing record, abnormal actor/session, adjacent MicrosoftDNS changes, or follow-on Kerberos/service activity supports coercion; close only when telemetry binds those categories to a lab or security-test workflow, with external validation required for any legitimacy claim telemetry cannot prove; preserve and escalate when evidence is mixed or incomplete.
False positive analysis
- Authorized security testing or lab validation can create CredMarshalTargetInfo-style ADIDNS records. Confirm by verifying that
winlog.event_data.ObjectDNis in the test namespace named by the validation record,user.idorwinlog.event_data.SubjectUserSidmatches the named operator, the MicrosoftDNS change set stays bounded, and Windows Security authentication events stay inside the stated victim and target scope. If validation records are unavailable and telemetry cannot prove that exact workflow, keep the alert unresolved instead of closing on recurrence alone. - Build exceptions from the minimum confirmed pattern: stable
user.idorwinlog.event_data.SubjectUserSid, the specific zone path inwinlog.event_data.ObjectDN, and the logginghost.id. Avoid exceptions on event codes 4662 or 5137, all MicrosoftDNS changes, or the blob pattern alone.
Response and remediation
- If confirmed benign, reverse any temporary containment and document the recognized operator, ADIDNS zone or record pattern, and lab-only authentication scope that confirmed the security-test workflow. Create an exception only after the same actor, zone pattern, and domain-controller scope recur.
- If suspicious but unconfirmed, preserve a case export of the raw Windows Security event,
winlog.event_data.ObjectDN,winlog.event_data.ObjectGUID,winlog.event_data.AdditionalInfo, the actor/session evidence, the logging domain controller, and any follow-on authentication events before containment. Export the record and surrounding zone state, then use reversible containment such as tightening the affected zone's write access or temporarily removing the actor's ability to modify MicrosoftDNS objects while scope is clarified. - If confirmed malicious, preserve the coercion record, surrounding MicrosoftDNS changes, and Windows Security authentication evidence tied to the spoofed name; contain the implicated account before destructive cleanup. Review the affected zone, replicating domain controllers, victim systems, and relay targets before removing the spoofing record and adjacent unauthorized DNS objects created by the same session.
- If Kerberos, LDAP, SMB, ADCS, or other service access followed the record, reset exposed account or machine secrets as appropriate and review for RBCD, certificate enrollment, Shadow Credentials, LAPS retrieval, password changes, group changes, service creation, or interactive SMB follow-on behavior.
- Harden by removing unnecessary ADIDNS write permissions, restricting authenticated-user access to MicrosoftDNS objects, and enforcing relay-resistant controls such as SMB signing, LDAP signing/channel binding, and EPA where applicable.
- Retain directory-service and authentication telemetry that supported the decision, and document the confirmed workflow or malicious artifact set for future analysts.
References
Related rules
- Potential Machine Account Relay Attack via SMB
- Service Creation via Local Kerberos Authentication
- Suspicious Kerberos Authentication Ticket Request
- Active Directory Forced Authentication from Linux Host - SMB Named Pipes
- AdminSDHolder SDProp Exclusion Added