« Kerberos Traffic from Unusual Process Potential Kerberos SPN Spoofing via Suspicious DNS Query »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential Kerberos Coercion via DNS-Based SPN Spoofing

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential Kerberos Coercion via DNS-Based SPN Spoofing

edit

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.

Rule type: query

Rule indices:

  • logs-system.security*
  • logs-windows.forwarded*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Data Source: Active Directory
  • Use Case: Active Directory Monitoring
  • Data Source: Windows Security Event Logs
  • Resources: Investigation Guide

Version: 4

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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, and winlog.computer_name to 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.
  • Which account and logon session touched the record?
  • Focus: user.id, winlog.event_data.SubjectUserSid, winlog.event_data.SubjectUserName, winlog.event_data.SubjectDomainName, and winlog.event_data.SubjectLogonId.
  • 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{"description":"","label":"Authentication events for the subject logon session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} 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.
  • 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 with winlog.event_data.ObjectDN, winlog.event_data.ObjectGUID, winlog.event_data.OpCorrelationID, and winlog.event_data.AttributeLDAPDisplayName.
  • 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{"description":"","label":"MicrosoftDNS directory-service events for the same session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5137","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}}
  • 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, and winlog.event_data.DSName for 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.
  • 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, and winlog.event_data.AuthenticationPackageName tied to the spoofed hostname or expected target service.
  • 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.
  • 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.
  • 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{"description":"","label":"Alerts associated with the creator","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: compare alerts on the logging domain controller’s host.id for the same behavior families. !{investigate{"description":"","label":"Alerts associated with the domain controller","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"}}
  • 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.
  • 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.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.
  • 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.

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.

Setup

edit

Setup

The following Windows audit policies must be enabled to generate the events used by this rule: - Audit Directory Service Access - Audit Directory Service Changes

Rule query

edit
host.os.type:"windows" and
(
  (event.code:4662 and winlog.event_data.AdditionalInfo: *UWhRC*BAAAA*MicrosoftDNS*) or
  (event.code:5137 and winlog.event_data.ObjectDN: *UWhRC*BAAAA*MicrosoftDNS*)
)

Framework: MITRE ATT&CKTM

« Kerberos Traffic from Unusual Process Potential Kerberos SPN Spoofing via Suspicious DNS Query »