« Suspicious Shell Execution via Velociraptor Potential WPAD Spoofing via DNS Record Creation »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential ADIDNS Poisoning via Wildcard Record Creation

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

Potential ADIDNS Poisoning via Wildcard Record Creation

edit

Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD’s access control and replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces some security issues, such as wildcard records, mainly because of the default permission (Any authenticated users) to create DNS-named records. Attackers can create wildcard records to redirect traffic for names that do not explicitly match records in the zone, positioning themselves as an adversary-in-the-middle and enabling credential interception or relay through ADIDNS manipulation similar in outcome to LLMNR/NBNS spoofing.

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

Version: 108

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential ADIDNS Poisoning via Wildcard Record Creation

Possible investigation steps

  • What wildcard object did the alert create, and which ADIDNS scope can it affect?
  • Why: a leading DC=* object can answer otherwise unresolved names across that ADIDNS zone, so the zone and partition define the first impact boundary.
  • Focus: winlog.event_data.ObjectDN, winlog.event_data.ObjectGUID, winlog.event_data.DSName, and winlog.computer_name.
  • Hint: parse winlog.event_data.ObjectDN from left to right. In DC=*,DC=example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=example,DC=com, DC=* is the wildcard node, DC=example.com is the DNS zone, and DC=DomainDnsZones,... identifies the AD DNS partition.
  • Implication: escalate faster when the object is a wildcard dnsNode in a production domain or forest DNS partition; lower concern only when the same object, zone, and domain controller align with a defensive sinkhole or contained test candidate, then continue to session and change evidence before closure.
  • Which account created the wildcard?
  • Focus: user.name, user.id, and winlog.event_data.SubjectLogonId.
  • Implication: escalate when the creator is not a recognized zone-management, defensive sinkhole, or test identity for this object and zone; keep investigating when the account fits a known role because identity alone does not clear wildcard creation.
  • Where did the creating session originate?
  • Focus: 4624 events on the same host.id where winlog.event_data.TargetLogonId matches winlog.event_data.SubjectLogonId; review source.ip, winlog.logon.type, and winlog.event_data.AuthenticationPackageName.
  • !{investigate{"description":"","label":"Session origin (4624) for the wildcard-creating logon","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Implication: escalate when the source, logon type, or authentication method is unexpected for DC-side ADIDNS changes; missing 4624 origin data is unresolved, not benign.
  • What DNS attributes or neighboring objects changed in the same operation?
  • Focus: same-session 5136/5137 records keyed by winlog.event_data.OpCorrelationID or winlog.event_data.SubjectLogonId, then grouped by winlog.event_data.ObjectGUID; inspect winlog.event_data.AttributeLDAPDisplayName and winlog.event_data.AttributeValue.
  • Hint: query the same domain controller and alert window for matching directory-service changes. Treat winlog.event_data.AttributeValue for dnsRecord as a lead because Security logs may encode or truncate record data. If the target is unclear, retrieve the current ADIDNS object or DNS record and compare it to ObjectDN, ObjectGUID, and the event timeline because current state may differ from event-time state. Missing DNS record data is unresolved, not benign. Windows Security alone does not prove tool identity or client redirection.
  • !{investigate{"description":"","label":"Directory service changes from the wildcard-creating session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5137","valueType":"string"}]],"relativeFrom":"now-1h/h","relativeTo":"now"}}
  • Implication: escalate when 5136 data shows a dnsRecord target or adjacent ADIDNS changes not tied to the same verified sinkhole or test object; if winlog.event_data.AttributeValue is opaque or absent, the target remains unresolved.
  • Did clients use the wildcard or authenticate to the recovered target?
  • Focus: DNS/client telemetry for names in the affected zone and downstream network or authentication events to the recovered target; compare dns.question.name, dns.resolved_ip, source.ip, and destination.ip.
  • Implication: escalate impact when clients query unresolved names that resolve to the wildcard target, then connect or authenticate to that target; missing DNS, network, or authentication telemetry is unresolved, not benign.
  • If object, session, or change-set evidence stays suspicious, do related alerts suggest broader AD abuse?
  • Focus: related alerts for user.id and host.id involving repeated directory-service changes, ADIDNS abuse, or credential access.
  • !{investigate{"description":"","label":"Alerts associated with the user","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"}}
  • !{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: broaden scope when the same actor or domain controller shows related AD, relay, or credential-access activity; keep scope local only when related alerts are absent and object, session, and change-set evidence fit a recognized sinkhole or test.
  • Escalate when production wildcard scope, unrecognized creator/session, suspicious dnsRecord target, client-impact evidence, adjacent ADIDNS changes, or related AD-abuse alerts point to unrecognized wildcard creation; close only when all evidence fits the exact defensive sinkhole or contained test object; if mixed or incomplete, preserve and escalate.

False positive analysis

  • Wildcard records in AD-integrated DNS zones are an anti-pattern because they can replace NXDOMAIN behavior and redirect unresolved names. The plausible benign paths are narrow: an administrator-controlled defensive sinkhole or a contained red-team or penetration test. Confirm by verifying that winlog.event_data.ObjectDN, winlog.event_data.ObjectGUID, winlog.event_data.DSName, user.id, winlog.event_data.SubjectLogonId, and recovered 5136 attribute evidence all align with that exact object and scope.
  • If independent confirmation of the sinkhole or test is unavailable, do not close as benign even when the Windows Security evidence is internally consistent.
  • Before creating an exception, require the same wildcard object, authorized zone, creator identity, and defensive or test window to recur as one stable workflow. Avoid exceptions on user.name, user.id, or the domain partition alone because those would suppress lookalike wildcard creation.

Response and remediation

  • If confirmed as an authorized defensive sinkhole or test, reverse any temporary containment, verify the wildcard is removed or retained according to that scope, and document winlog.event_data.ObjectDN, winlog.event_data.ObjectGUID, winlog.event_data.DSName, creating user.id, winlog.event_data.SubjectLogonId, winlog.computer_name, and the confirming scope.
  • If suspicious but unconfirmed, export the AD object state, replication context, and related 5136/5137 Windows Security events before modifying the record or account. Then apply reversible containment tied to the evidence, such as restricting the creating account’s ADIDNS write path or temporarily limiting that account while scope is clarified.
  • If confirmed malicious, preserve the exported AD object, 5136 attribute evidence, session-origin evidence, and related alerts before deletion. Remove the wildcard and any unauthorized ADIDNS objects from the same session, then verify removal replicated to all domain controllers.
  • Disable or restrict the creating account after evidence preservation to prevent re-poisoning. Use winlog.event_data.SubjectLogonId and recovered source.ip to hand off the source system for endpoint investigation of ADIDNS tooling, credential capture, or follow-on authentication.
  • If separate response evidence proves client redirection through the wildcard, treat credentials active on affected systems as exposed. Reset those accounts, prioritizing privileged and service accounts, and investigate for relayed authentication or follow-on access.
  • Review ADIDNS permissions for the affected zone; reduce wildcard-creation opportunities, especially broadly delegated or authenticated-user create-child rights. Search all AD-integrated zones for additional wildcard or suspicious ADIDNS objects and document the final evidence set for future narrow exceptions.

Setup

edit

Setup

Audit Directory Service Changes must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-directory-service-changes

Rule query

edit
any where host.os.type == "windows" and event.code == "5137" and
    startsWith(winlog.event_data.ObjectDN, "DC=*,")

Framework: MITRE ATT&CKTM

« Suspicious Shell Execution via Velociraptor Potential WPAD Spoofing via DNS Record Creation »