Potential WPAD Spoofing via DNS Record Creation
Identifies the creation of a DNS record that is potentially meant to enable WPAD spoofing. Attackers can disable the Global Query Block List (GQBL) and create a "wpad" record to exploit hosts running WPAD with default settings for privilege escalation and lateral movement.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/06/03"
3integration = ["system", "windows"]
4maturity = "production"
5updated_date = "2025/03/20"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the creation of a DNS record that is potentially meant to enable WPAD spoofing. Attackers can disable the
11Global Query Block List (GQBL) and create a "wpad" record to exploit hosts running WPAD with default settings for
12privilege escalation and lateral movement.
13"""
14from = "now-9m"
15index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
16language = "eql"
17license = "Elastic License v2"
18name = "Potential WPAD Spoofing via DNS Record Creation"
19note = """## Triage and analysis
20
21> **Disclaimer**:
22> 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.
23
24### Investigating Potential WPAD Spoofing via DNS Record Creation
25
26Web Proxy Auto-Discovery (WPAD) helps devices automatically detect proxy settings, crucial for network efficiency. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule identifies suspicious DNS record changes, specifically targeting WPAD entries, to flag potential spoofing attempts, aiding in early threat detection and mitigation.
27
28### Possible investigation steps
29
30- Review the event logs for the specific event code "5137" to identify the creation or modification of the "wpad" DNS record. Focus on the details provided in the winlog.event_data.ObjectDN field to confirm the presence of "DC=wpad,*".
31- Check the Active Directory change history to determine who made the changes to the DNS records and whether these changes were authorized.
32- Investigate the user account associated with the directory service change event to assess if it has been compromised or if there are any signs of unauthorized access.
33- Analyze network traffic to and from the "wpad" DNS record to identify any suspicious activity or connections to rogue proxy servers.
34- Verify the configuration of the Global Query Block List (GQBL) to ensure it has not been disabled or altered, which could allow unauthorized WPAD entries.
35- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
36
37### False positive analysis
38
39- Legitimate network changes may trigger alerts if a new WPAD DNS record is created intentionally for network configuration. Verify with network administrators if such changes were planned.
40- Automated scripts or software updates that modify DNS records can cause false positives. Review the source of the change and consider excluding known benign scripts or update processes.
41- Test environments often simulate DNS changes, including WPAD entries, for development purposes. Exclude these environments from monitoring if they are known to generate non-threatening alerts.
42- Some organizations may have legacy systems that rely on WPAD configurations. Document these systems and create exceptions for their DNS changes to avoid unnecessary alerts.
43- Regular audits of the Global Query Block List settings can help identify and exclude expected changes, reducing false positives related to WPAD record creation.
44
45### Response and remediation
46
47- Immediately isolate the affected system from the network to prevent further data interception or lateral movement by the rogue proxy.
48- Verify and restore the integrity of the DNS records by removing any unauthorized "wpad" entries and re-enabling the Global Query Block List (GQBL) if it was disabled.
49- Conduct a thorough review of Active Directory logs to identify any unauthorized changes or suspicious activities related to directory service modifications.
50- Reset credentials for any accounts that may have been compromised or accessed during the incident to prevent unauthorized access.
51- Implement network segmentation to limit the exposure of critical systems to potential WPAD spoofing attacks.
52- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or data were affected.
53- Update and enhance monitoring rules to detect similar WPAD spoofing attempts in the future, ensuring timely alerts and responses."""
54references = [
55 "https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing#through-adidns-spoofing",
56 "https://cube0x0.github.io/Pocing-Beyond-DA/",
57]
58risk_score = 47
59rule_id = "894326d2-56c0-4342-b553-4abfaf421b5b"
60setup = """## Setup
61
62The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
63Steps to implement the logging policy with Advanced Audit Configuration:
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 = "medium"
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 winlog.event_data.ObjectDN : "DC=wpad,*"
18'''
19
20
21[[rule.threat]]
22framework = "MITRE ATT&CK"
23[[rule.threat.technique]]
24id = "T1557"
25name = "Adversary-in-the-Middle"
26reference = "https://attack.mitre.org/techniques/T1557/"
27
28
29[rule.threat.tactic]
30id = "TA0006"
31name = "Credential Access"
32reference = "https://attack.mitre.org/tactics/TA0006/"
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 Potential WPAD Spoofing via DNS Record Creation
Web Proxy Auto-Discovery (WPAD) helps devices automatically detect proxy settings, crucial for network efficiency. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule identifies suspicious DNS record changes, specifically targeting WPAD entries, to flag potential spoofing attempts, aiding in early threat detection and mitigation.
Possible investigation steps
- Review the event logs for the specific event code "5137" to identify the creation or modification of the "wpad" DNS record. Focus on the details provided in the winlog.event_data.ObjectDN field to confirm the presence of "DC=wpad,*".
- Check the Active Directory change history to determine who made the changes to the DNS records and whether these changes were authorized.
- Investigate the user account associated with the directory service change event to assess if it has been compromised or if there are any signs of unauthorized access.
- Analyze network traffic to and from the "wpad" DNS record to identify any suspicious activity or connections to rogue proxy servers.
- Verify the configuration of the Global Query Block List (GQBL) to ensure it has not been disabled or altered, which could allow unauthorized WPAD entries.
- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
False positive analysis
- Legitimate network changes may trigger alerts if a new WPAD DNS record is created intentionally for network configuration. Verify with network administrators if such changes were planned.
- Automated scripts or software updates that modify DNS records can cause false positives. Review the source of the change and consider excluding known benign scripts or update processes.
- Test environments often simulate DNS changes, including WPAD entries, for development purposes. Exclude these environments from monitoring if they are known to generate non-threatening alerts.
- Some organizations may have legacy systems that rely on WPAD configurations. Document these systems and create exceptions for their DNS changes to avoid unnecessary alerts.
- Regular audits of the Global Query Block List settings can help identify and exclude expected changes, reducing false positives related to WPAD record creation.
Response and remediation
- Immediately isolate the affected system from the network to prevent further data interception or lateral movement by the rogue proxy.
- Verify and restore the integrity of the DNS records by removing any unauthorized "wpad" entries and re-enabling the Global Query Block List (GQBL) if it was disabled.
- Conduct a thorough review of Active Directory logs to identify any unauthorized changes or suspicious activities related to directory service modifications.
- Reset credentials for any accounts that may have been compromised or accessed during the incident to prevent unauthorized access.
- Implement network segmentation to limit the exposure of critical systems to potential WPAD spoofing attacks.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or data were affected.
- Update and enhance monitoring rules to detect similar WPAD spoofing attempts in the future, ensuring timely alerts and responses.
References
Related rules
- Access to a Sensitive LDAP Attribute
- Creation of a DNS-Named Record
- FirstTime Seen Account Performing DCSync
- Kerberos Pre-authentication Disabled for User
- Potential ADIDNS Poisoning via Wildcard Record Creation