« Potential Privileged Escalation via SamAccountName Spoofing Suspicious SeIncreaseBasePriorityPrivilege Use »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.24

Remote Computer Account DnsHostName Update

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

Remote Computer Account DnsHostName Update

edit

Identifies the remote update to a computer account’s DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it’s highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges.

Rule type: eql

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: Privilege Escalation
  • Use Case: Active Directory Monitoring
  • Data Source: Active Directory
  • Use Case: Vulnerability
  • Data Source: Windows Security Event Logs
  • Resources: Investigation Guide

Version: 215

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Remote Computer Account DnsHostName Update

Possible investigation steps

  • What object, initiator, and DNS-name mismatch does the alert prove?
  • Focus: winlog.event_data.TargetUserName, winlog.event_data.TargetSid, winlog.event_data.DnsHostName, winlog.event_data.SubjectUserSid, and winlog.event_data.SubjectLogonId.
  • Implication: escalate or continue when the new DNS host name no longer matches the target computer account and points to another server namespace; lower suspicion only when target SID, subject SID, and logon session fit a recognized rename, promotion, re-binding, or authorized test.
  • Does the new DNS host name collide with a domain controller or other sensitive host?
  • Why: Certifried abuse makes a controlled computer account look like a trusted host before requesting or using a machine certificate.
  • Focus: winlog.event_data.DnsHostName, winlog.event_data.TargetUserName, winlog.event_data.TargetDomainName, and winlog.computer_name.
  • Implication: high risk when the value matches a real domain controller, CA, or privileged server different from winlog.event_data.TargetUserName; lower risk only when it belongs to the same object transition and does not collide with a privileged asset.
  • Who made the update, and does the source/session context fit that account’s role?
  • Focus: winlog.event_data.SubjectUserSid, winlog.event_data.SubjectUserName, winlog.event_data.SubjectDomainName, winlog.event_data.SubjectLogonId, and source.ip.
  • Implication: escalate when the subject is a standard user, non-tier-0 admin, unusual service account, machine account, or unexpected source for computer-account management; lower suspicion when subject, source when present, and logon session match a recognized AD management path.
  • Did the same object show SPN deletion, empty-SPN creation, or other preparation?
  • Why: successful DNS-name spoofing often requires removing FQDN service principal names or creating a computer account without them so SPN uniqueness checks do not block the DNS update.
  • Focus: Windows Security account-management and directory-change events for winlog.event_data.TargetSid, especially event.code, winlog.event_data.AttributeLDAPDisplayName, winlog.event_data.AttributeValue, and winlog.event_data.ObjectDN.
  • Implication: escalate when the sequence removes servicePrincipalName values, creates or controls the computer object, or changes related attributes just before the DNS update; lower suspicion when the same change set follows a recognized promotion or re-binding path.
  • Did certificate-service or Kerberos activity use the spoofed identity after the update?
  • Focus: post-alert Windows Security certificate enrollment and authentication events for winlog.event_data.TargetUserName or the spoofed host name, reading event.code, winlog.event_data.AuthenticationPackageName, winlog.logon.type, and source.ip.
  • Hint: missing certificate-service or Kerberos telemetry leaves post-update use unresolved, not benign.
  • Implication: escalate when the modified object requests or receives a machine certificate, uses Kerberos with the spoofed identity, authenticates from unexpected source.ip when present, or appears in privileged follow-on activity; absence of follow-on use lowers urgency only when object, initiator, and preparation evidence also align benignly.
  • If local evidence stays suspicious or unresolved, do related alerts show the same modifying user elsewhere?
  • Focus: related alerts for modifying user.id, especially AD manipulation, certificate abuse, credential-access, or privilege-escalation alerts. !{investigate{"description":"","label":"Alerts associated with the modifying user in the surrounding window","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-2h/h","relativeTo":"now"}}
  • Implication: broaden scope when the same user appears in more directory changes, certificate abuse, unusual authentication, or privilege escalation; keep response local only when related alerts are absent and local evidence supports one recognized workflow.
  • What disposition do the DNS-name mismatch, hostname collision, initiator, preparation, follow-on use, and scope support?
  • Escalate on sensitive-host collision, suspicious initiator, SPN/object preparation, certificate/Kerberos use, or related AD abuse; close only when all evidence binds one recognized test or object-transition workflow with no contradictions; preserve evidence and escalate when answers conflict or visibility is incomplete.

False positive analysis

  • Benign matches are uncommon because changing a computer account DNS host name to another host namespace is an AD identity anti-pattern. Authorized CVE-2022-26923 testing or patch validation explains the alert only when subject SID/logon, target SID/name, spoofed host name, event-origin controller, SPN/object-change sequence, and follow-on certificate or authentication events all match the same test scope. Without a test plan, close only when telemetry proves a bounded lab pattern; drift in initiator, hostname, or follow-on use keeps the alert suspicious.
  • Rare promotion, rename, migration, or re-binding explains the alert only when the same computer object intentionally assumes the new DNS identity, no privileged-host collision exists, and subject, target SID, new host name, controller, and bounded follow-on authentication path all align. Do not close if telemetry leaves object identity, collision, or follow-on use unresolved.
  • Build exceptions from the minimum confirmed workflow: stable winlog.event_data.SubjectUserSid, winlog.event_data.TargetSid, winlog.event_data.TargetUserName, winlog.event_data.DnsHostName, winlog.computer_name, and bounded follow-on source.ip or event.code. Avoid exceptions on event.action, winlog.event_data.DnsHostName, or winlog.event_data.TargetSid alone.

Response and remediation

  • If confirmed benign, document the exact workflow evidence first: subject SID/logon, target SID/name, DNS host name, event-origin controller, SPN/object-change context, and bounded follow-on authentication or certificate pattern. Then reverse temporary containment. Create an exception only after the same pattern is stable enough to avoid suppressing lookalike spoofing.
  • If suspicious but unconfirmed, export the alert and surrounding Windows Security records first, preserving the target object, spoofed host name, subject identity/logon, event-origin controller, SPN/object changes, certificate/authentication events, source IPs, and related alerts. Then use reversible containment, such as restoring the prior DNS host name or temporarily disabling the modified computer account with AD owner coordination. Escalate to account or host containment only when certificate issuance, Kerberos use, or related privilege abuse shows active use.
  • If confirmed malicious, preserve the same AD object-change and follow-on authentication/certificate evidence before restoration. Disable or restore the modified computer object, reset the machine-account secret or trust path, revoke or map affected certificates when issued, and contain the modifying account and suspected source host. Use broader domain recovery only when certificate or Kerberos abuse extends beyond the single object.
  • Before final object restoration, search the same subject SID and target SID across Windows Security logs for additional DNS host name, SPN, certificate, or privilege-abuse events so scope is complete before evidence changes.
  • Post-incident hardening: apply CVE-2022-26923 domain controller and AD CS fixes, reduce ms-DS-MachineAccountQuota where feasible, restrict computer-account creation and validated writes, retain computer-account and 5136 directory-service auditing, and record the confirmed subject/target/hostname/follow-on-authentication pattern for future triage.

Setup

edit

Setup

Audit Computer Account Management must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-computer-account-management

Rule query

edit
iam where host.os.type == "windows" and event.action == "changed-computer-account" and
    user.id : ("S-1-5-21-*", "S-1-12-1-*") and

    /* if DnsHostName value equal a DC DNS hostname then it's highly suspicious */
    winlog.event_data.DnsHostName : "??*" and

    /* exclude FPs where DnsHostName starts with the ComputerName that was changed */
    not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1))

Framework: MITRE ATT&CKTM

« Potential Privileged Escalation via SamAccountName Spoofing Suspicious SeIncreaseBasePriorityPrivilege Use »