Creation of a DNS-Named Record

 1[metadata]
 2creation_date = "2024/03/26"
 3integration = ["system", "windows"]
 4maturity = "production"
 5updated_date = "2025/01/22"
 6min_stack_version = "8.14.0"
 7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 8
 9[rule]
10author = ["Elastic"]
11description = """
12Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and
13replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces
14some security issues because of the default permission (Any authenticated users) to create DNS-named records. Attackers
15can perform Dynamic Spoofing attacks, where they monitor LLMNR/NBT-NS requests and create DNS-named records to target
16systems that are requested from multiple systems. They can also create specific records to target specific services,
17such as wpad, for spoofing attacks.
18"""
19from = "now-9m"
20index = ["winlogbeat-*", "logs-system.*", "logs-windows.*"]
21language = "eql"
22license = "Elastic License v2"
23name = "Creation of a DNS-Named Record"
24references = [
25    "https://www.netspi.com/blog/technical/network-penetration-testing/adidns-revisited/",
26    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/wpad-spoofing",
27]
28risk_score = 21
29rule_id = "1e1b2e7e-b8f5-45e5-addc-66cc1224ffbc"
30setup = """## Setup
31
32The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
33Steps to implement the logging policy with Advanced Audit Configuration:

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.

 1"""
 2severity = "low"
 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: System",
11    "Resources: Investigation Guide",
12]
13timestamp_override = "event.ingested"
14type = "eql"
15
16query = '''
17any where host.os.type == "windows" and event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and
18    not winlog.event_data.SubjectUserName : "*$"
19'''
20note = """## Triage and analysis
21
22> **Disclaimer**:
23> 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.
24
25### Investigating Creation of a DNS-Named Record
26
27Active 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.
28
29### Possible investigation steps
30
31- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp.
32- 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.
33- 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.
34- 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.
35- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts.
36- 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.
37
38### False positive analysis
39
40- 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.
41- 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.
42- 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.
43- 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.
44- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats.
45
46### Response and remediation
47
48- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks.
49- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD.
50- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access.
51- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts.
52- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks.
53- 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.
54- 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."""
55
56
57[[rule.threat]]
58framework = "MITRE ATT&CK"
59[[rule.threat.technique]]
60id = "T1557"
61name = "Adversary-in-the-Middle"
62reference = "https://attack.mitre.org/techniques/T1557/"
63
64
65[rule.threat.tactic]
66id = "TA0006"
67name = "Credential Access"
68reference = "https://attack.mitre.org/tactics/TA0006/"