Creation of a DNS-Named Record
ELASTIC detection rule by Elastic · Elastic License v2
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 because of the default permission (Any authenticated users) to create DNS-named records. Attackers
can perform Dynamic Spoofing attacks, where they monitor LLMNR/NBT-NS requests and create DNS-named records to target
systems that are requested from multiple systems. They can also create specific records to target specific services,
such as wpad, for spoofing attacks.
[metadata]
creation_date = "2024/03/26"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"
[rule]
author = ["Elastic"]
description = """
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 because of the default permission (Any authenticated users) to create DNS-named records. Attackers
can perform Dynamic Spoofing attacks, where they monitor LLMNR/NBT-NS requests and create DNS-named records to target
systems that are requested from multiple systems. They can also create specific records to target specific services,
such as wpad, for spoofing attacks.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Creation of a DNS-Named Record"
note = """## Triage and analysis
> **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.
### Investigating Creation of a DNS-Named Record
Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create DNS records for spoofing attacks, targeting services like WPAD. The detection rule identifies such abuse by monitoring specific Windows events related to DNS record creation, filtering out legitimate system accounts to highlight potential threats.
### Possible investigation steps
- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp.
- Examine the winlog.event_data.SubjectUserName field to determine the user account that initiated the DNS record creation, ensuring it is not a system account.
- Investigate the context around the winlog.event_data.ObjectClass field to confirm the object class is "dnsNode" and assess if the DNS record creation aligns with expected administrative activities.
- Check for any recent LLMNR/NBT-NS requests or network traffic that might indicate an attempt to exploit the newly created DNS record for spoofing purposes.
- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts.
- Assess the risk and impact of the DNS record creation by determining if it targets critical services like WPAD or other sensitive systems within the network.
### False positive analysis
- Legitimate administrative actions may trigger the rule when DNS records are created or modified by IT staff. To manage this, create exceptions for known administrative accounts that regularly perform these tasks.
- Automated system processes or scripts that update DNS records can also cause false positives. Identify these processes and exclude their associated accounts from the rule to prevent unnecessary alerts.
- Service accounts used by legitimate applications to dynamically update DNS records might be flagged. Review these accounts and add them to an exception list if they are verified as non-threatening.
- Temporary network changes or testing environments where DNS records are frequently modified can lead to false positives. Consider excluding these environments or specific IP ranges from the rule to reduce noise.
- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks.
- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD.
- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access.
- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.
- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or services were affected.
- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent similar incidents in the future."""
references = [
"https://www.netspi.com/blog/technical/network-penetration-testing/adidns-revisited/",
"https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/wpad-spoofing",
]
risk_score = 21
rule_id = "1e1b2e7e-b8f5-45e5-addc-66cc1224ffbc"
setup = """## 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
"""
severity = "low"
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",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
any where host.os.type == "windows" and event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and
not winlog.event_data.SubjectUserName : "*$"
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"
[[rule.threat.technique.subtechnique]]
id = "T1557.001"
name = "LLMNR/NBT-NS Poisoning and SMB Relay"
reference = "https://attack.mitre.org/techniques/T1557/001/"
[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"