Unsigned DLL loaded by DNS Service
Identifies unusual DLLs loaded by the DNS Server process, potentially indicating the abuse of the ServerLevelPluginDll functionality. This can lead to privilege escalation and remote code execution with SYSTEM privileges.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/05/29"
3integration = ["endpoint", "windows"]
4maturity = "production"
5updated_date = "2025/01/15"
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 = """
12Identifies unusual DLLs loaded by the DNS Server process, potentially indicating the abuse of the ServerLevelPluginDll
13functionality. This can lead to privilege escalation and remote code execution with SYSTEM privileges.
14"""
15from = "now-9m"
16index = ["logs-endpoint.events.library-*", "logs-windows.sysmon_operational-*", "winlogbeat-*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Unsigned DLL loaded by DNS Service"
20references = [
21 "https://cube0x0.github.io/Pocing-Beyond-DA/",
22 "https://adsecurity.org/?p=4064",
23 "https://github.com/gtworek/PSBits/tree/master/ServerLevelPluginDll"
24]
25risk_score = 47
26rule_id = "5d676480-9655-4507-adc6-4eec311efff8"
27severity = "medium"
28tags = [
29 "Domain: Endpoint",
30 "OS: Windows",
31 "Use Case: Threat Detection",
32 "Tactic: Privilege Escalation",
33 "Data Source: Elastic Defend",
34 "Data Source: Sysmon",
35 "Resources: Investigation Guide"
36]
37timestamp_override = "event.ingested"
38type = "eql"
39
40query = '''
41any where host.os.type == "windows" and event.category : ("library", "process") and
42 event.type : ("start", "change") and event.action : ("load", "Image loaded*") and
43 process.executable : "?:\\windows\\system32\\dns.exe" and
44 not ?dll.code_signature.trusted == true and
45 not file.code_signature.status == "Valid"
46'''
47note = """## Triage and analysis
48
49> **Disclaimer**:
50> 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.
51
52### Investigating Unsigned DLL loaded by DNS Service
53
54The DNS service in Windows environments is crucial for resolving domain names to IP addresses. It can be extended via DLLs, which, if unsigned, may indicate tampering. Adversaries exploit this by loading malicious DLLs to gain elevated privileges or execute code with SYSTEM rights. The detection rule identifies such threats by monitoring the DNS process for loading untrusted DLLs, flagging potential privilege escalation attempts.
55
56### Possible investigation steps
57
58- Review the alert details to identify the specific DLL file that was loaded by the DNS service and check its file path and name for any known malicious indicators.
59- Examine the file's code signature status and metadata to determine why it is not trusted or valid, and cross-reference with known trusted sources or databases.
60- Investigate the process tree of dns.exe to identify any parent or child processes that may indicate how the unsigned DLL was introduced or executed.
61- Check the system's event logs for any recent changes or anomalies around the time the DLL was loaded, focusing on events related to process creation, file modification, or user account activity.
62- Analyze network traffic logs for any unusual DNS queries or outbound connections that could suggest communication with a command and control server.
63- Assess the system for other signs of compromise, such as unauthorized user accounts, scheduled tasks, or registry changes that could indicate further exploitation or persistence mechanisms.
64- If possible, isolate the affected system to prevent further potential malicious activity and begin remediation steps based on the findings.
65
66### False positive analysis
67
68- Legitimate software updates or patches may introduce new DLLs that are unsigned. Verify the source of the update and, if trusted, create an exception for these DLLs to prevent future alerts.
69- Custom or in-house applications might use unsigned DLLs for specific functionalities. Confirm the legitimacy of these applications and add them to an allowlist to avoid unnecessary alerts.
70- Some third-party security or monitoring tools may load unsigned DLLs as part of their operation. Validate these tools with your security team and configure exceptions for known, safe DLLs.
71- Development or testing environments often use unsigned DLLs during the software development lifecycle. Ensure these environments are properly segmented and consider excluding them from this rule to reduce noise.
72- Legacy systems might rely on older, unsigned DLLs that are still in use. Conduct a risk assessment and, if deemed safe, exclude these DLLs from triggering alerts.
73
74### Response and remediation
75
76- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
77- Terminate the DNS service process (dns.exe) to stop the execution of the malicious DLL and prevent further potential damage.
78- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software.
79- Restore the DNS service to its original state by replacing the compromised DLL with a legitimate, signed version from a trusted source or backup.
80- Review and update the system's security patches and configurations to address any vulnerabilities that may have been exploited, particularly those related to privilege escalation.
81- Monitor the system and network for any signs of continued or repeated unauthorized activity, focusing on similar indicators of compromise.
82- Report the incident to the appropriate internal security team or external authorities if required, providing details of the threat and actions taken for further investigation and response."""
83
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87[[rule.threat.technique]]
88id = "T1068"
89name = "Exploitation for Privilege Escalation"
90reference = "https://attack.mitre.org/techniques/T1068/"
91
92
93[rule.threat.tactic]
94id = "TA0004"
95name = "Privilege Escalation"
96reference = "https://attack.mitre.org/tactics/TA0004/"
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 Unsigned DLL loaded by DNS Service
The DNS service in Windows environments is crucial for resolving domain names to IP addresses. It can be extended via DLLs, which, if unsigned, may indicate tampering. Adversaries exploit this by loading malicious DLLs to gain elevated privileges or execute code with SYSTEM rights. The detection rule identifies such threats by monitoring the DNS process for loading untrusted DLLs, flagging potential privilege escalation attempts.
Possible investigation steps
- Review the alert details to identify the specific DLL file that was loaded by the DNS service and check its file path and name for any known malicious indicators.
- Examine the file's code signature status and metadata to determine why it is not trusted or valid, and cross-reference with known trusted sources or databases.
- Investigate the process tree of dns.exe to identify any parent or child processes that may indicate how the unsigned DLL was introduced or executed.
- Check the system's event logs for any recent changes or anomalies around the time the DLL was loaded, focusing on events related to process creation, file modification, or user account activity.
- Analyze network traffic logs for any unusual DNS queries or outbound connections that could suggest communication with a command and control server.
- Assess the system for other signs of compromise, such as unauthorized user accounts, scheduled tasks, or registry changes that could indicate further exploitation or persistence mechanisms.
- If possible, isolate the affected system to prevent further potential malicious activity and begin remediation steps based on the findings.
False positive analysis
- Legitimate software updates or patches may introduce new DLLs that are unsigned. Verify the source of the update and, if trusted, create an exception for these DLLs to prevent future alerts.
- Custom or in-house applications might use unsigned DLLs for specific functionalities. Confirm the legitimacy of these applications and add them to an allowlist to avoid unnecessary alerts.
- Some third-party security or monitoring tools may load unsigned DLLs as part of their operation. Validate these tools with your security team and configure exceptions for known, safe DLLs.
- Development or testing environments often use unsigned DLLs during the software development lifecycle. Ensure these environments are properly segmented and consider excluding them from this rule to reduce noise.
- Legacy systems might rely on older, unsigned DLLs that are still in use. Conduct a risk assessment and, if deemed safe, exclude these DLLs from triggering alerts.
Response and remediation
- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
- Terminate the DNS service process (dns.exe) to stop the execution of the malicious DLL and prevent further potential damage.
- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software.
- Restore the DNS service to its original state by replacing the compromised DLL with a legitimate, signed version from a trusted source or backup.
- Review and update the system's security patches and configurations to address any vulnerabilities that may have been exploited, particularly those related to privilege escalation.
- Monitor the system and network for any signs of continued or repeated unauthorized activity, focusing on similar indicators of compromise.
- Report the incident to the appropriate internal security team or external authorities if required, providing details of the threat and actions taken for further investigation and response.
References
Related rules
- Creation or Modification of a new GPO Scheduled Task or Service
- Persistence via PowerShell profile
- Persistence via TelemetryController Scheduled Task Hijack
- Potential Escalation via Vulnerable MSI Repair
- Potential Exploitation of an Unquoted Service Path Vulnerability