Potential ADIDNS Poisoning via Wildcard Record Creation

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 that doesn't explicitly match records contained in the zone, becoming the Man-in-the-Middle and being able to abuse DNS similarly to LLMNR/NBNS spoofing.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2024/03/26"
 3integration = ["system", "windows"]
 4maturity = "production"
 5updated_date = "2025/03/20"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and
11replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces
12some security issues, such as wildcard records, mainly because of the default permission (Any authenticated users) to
13create DNS-named records. Attackers can create wildcard records to redirect traffic that doesn't explicitly match
14records contained in the zone, becoming the Man-in-the-Middle and being able to abuse DNS similarly to LLMNR/NBNS
15spoofing.
16"""
17from = "now-9m"
18index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
19language = "eql"
20license = "Elastic License v2"
21name = "Potential ADIDNS Poisoning via Wildcard Record Creation"
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 ADIDNS Poisoning via Wildcard Record Creation
28
29Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions allow authenticated users to create DNS records, which adversaries can exploit by adding wildcard records. This enables them to redirect traffic and perform Man-in-the-Middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes indicative of wildcard record creation.
30
31### Possible investigation steps
32
33- Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification.
34- Examine the ObjectDN field in the event data to identify the specific DNS zone where the wildcard record was created, ensuring it starts with "DC=*," to confirm the wildcard nature.
35- Check the user account associated with the event to determine if it is a legitimate account or potentially compromised, focusing on any unusual or unauthorized activity.
36- Investigate recent changes in the DNS zone to identify any other suspicious modifications or patterns that could indicate further malicious activity.
37- Correlate the event with network traffic logs to detect any unusual or redirected traffic patterns that could suggest a Man-in-the-Middle attack.
38- Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users.
39
40### False positive analysis
41
42- Routine administrative changes to DNS records by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or specific ObjectDN patterns that correspond to legitimate changes.
43- Automated systems or scripts that update DNS records as part of regular maintenance may cause false positives. Identify these systems and exclude their activity from triggering alerts by filtering based on their unique identifiers or event sources.
44- Software installations or updates that modify DNS settings might be flagged. Monitor and document these activities, and consider excluding them if they are part of a recognized and secure process.
45- Changes made by trusted third-party services that integrate with ADIDNS could be misinterpreted as threats. Verify these services and whitelist their actions to prevent unnecessary alerts.
46- Temporary testing environments that mimic production settings might generate alerts. Ensure these environments are clearly documented and excluded from monitoring if they are known to perform non-threatening wildcard record creations.
47
48### Response and remediation
49
50- Immediately isolate the affected system from the network to prevent further exploitation or data exfiltration.
51- Revoke any potentially compromised credentials associated with the affected system or user accounts involved in the alert.
52- Conduct a thorough review of DNS records in the affected zone to identify and remove any unauthorized wildcard entries.
53- Implement stricter access controls on DNS record creation, limiting permissions to only necessary administrative accounts.
54- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections.
55- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems.
56- Update detection mechanisms to include additional indicators of compromise related to ADIDNS abuse, enhancing future threat detection capabilities."""
57references = [
58    "https://www.netspi.com/blog/technical/network-penetration-testing/exploiting-adidns/",
59    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/adidns-spoofing",
60]
61risk_score = 73
62rule_id = "8f242ffb-b191-4803-90ec-0f19942e17fd"
63setup = """## Setup
64
65The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
66Steps to implement the logging policy with Advanced Audit Configuration:
...
toml

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policies Configuration > Audit Policies > DS Access > Audit Directory Service Changes (Success,Failure)

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.

Set-AuditRule -AdObjectPath 'AD:\CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights CreateChild -InheritanceFlags Descendents -AttributeGUID e0fa1e8c-9b45-11d0-afdd-00c04fd930c9 -AuditFlags Success

 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 = "eql"
15
16query = '''
17any where host.os.type == "windows" and event.code == "5137" and
18    startsWith(winlog.event_data.ObjectDN, "DC=*,")
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
29
30[rule.threat.tactic]
31id = "TA0006"
32name = "Credential Access"
33reference = "https://attack.mitre.org/tactics/TA0006/"

Disclaimer: 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.

Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions allow authenticated users to create DNS records, which adversaries can exploit by adding wildcard records. This enables them to redirect traffic and perform Man-in-the-Middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes indicative of wildcard record creation.

  • Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification.
  • Examine the ObjectDN field in the event data to identify the specific DNS zone where the wildcard record was created, ensuring it starts with "DC=*," to confirm the wildcard nature.
  • Check the user account associated with the event to determine if it is a legitimate account or potentially compromised, focusing on any unusual or unauthorized activity.
  • Investigate recent changes in the DNS zone to identify any other suspicious modifications or patterns that could indicate further malicious activity.
  • Correlate the event with network traffic logs to detect any unusual or redirected traffic patterns that could suggest a Man-in-the-Middle attack.
  • Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users.
  • Routine administrative changes to DNS records by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or specific ObjectDN patterns that correspond to legitimate changes.
  • Automated systems or scripts that update DNS records as part of regular maintenance may cause false positives. Identify these systems and exclude their activity from triggering alerts by filtering based on their unique identifiers or event sources.
  • Software installations or updates that modify DNS settings might be flagged. Monitor and document these activities, and consider excluding them if they are part of a recognized and secure process.
  • Changes made by trusted third-party services that integrate with ADIDNS could be misinterpreted as threats. Verify these services and whitelist their actions to prevent unnecessary alerts.
  • Temporary testing environments that mimic production settings might generate alerts. Ensure these environments are clearly documented and excluded from monitoring if they are known to perform non-threatening wildcard record creations.
  • Immediately isolate the affected system from the network to prevent further exploitation or data exfiltration.
  • Revoke any potentially compromised credentials associated with the affected system or user accounts involved in the alert.
  • Conduct a thorough review of DNS records in the affected zone to identify and remove any unauthorized wildcard entries.
  • Implement stricter access controls on DNS record creation, limiting permissions to only necessary administrative accounts.
  • Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections.
  • Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems.
  • Update detection mechanisms to include additional indicators of compromise related to ADIDNS abuse, enhancing future threat detection capabilities.

References

Related rules

to-top