Potential DLL Side-Loading via Trusted Microsoft Programs
Identifies an instance of a Windows trusted program that is known to be vulnerable to DLL Search Order Hijacking starting after being renamed or from a non-standard path. This is uncommon behavior and may indicate an attempt to evade defenses via side loading a malicious DLL within the memory space of one of those processes.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/09/03"
3integration = ["endpoint", "windows", "m365_defender"]
4maturity = "production"
5updated_date = "2025/03/20"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies an instance of a Windows trusted program that is known to be vulnerable to DLL Search Order Hijacking
11starting after being renamed or from a non-standard path. This is uncommon behavior and may indicate an attempt to evade
12defenses via side loading a malicious DLL within the memory space of one of those processes.
13"""
14from = "now-9m"
15index = [
16 "winlogbeat-*",
17 "logs-endpoint.events.process-*",
18 "logs-windows.sysmon_operational-*",
19 "endgame-*",
20 "logs-m365_defender.event-*",
21]
22language = "eql"
23license = "Elastic License v2"
24name = "Potential DLL Side-Loading via Trusted Microsoft Programs"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> 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.
29
30### Investigating Potential DLL Side-Loading via Trusted Microsoft Programs
31
32DLL side-loading exploits the DLL search order to load malicious code into trusted Microsoft programs, which are often whitelisted by security tools. Adversaries rename or relocate these programs to execute unauthorized DLLs, evading detection. The detection rule identifies unusual execution paths or renamed instances of these programs, signaling potential misuse and enabling timely threat response.
33
34### Possible investigation steps
35
36- Review the process details to confirm the original file name and the path from which the process was executed. Check if the process.pe.original_file_name matches any of the specified trusted programs like "WinWord.exe", "EXPLORER.EXE", "w3wp.exe", or "DISM.EXE".
37- Investigate the process execution path to determine if it deviates from the standard paths listed in the query, such as "?:\\Windows\\explorer.exe" or "?:\\Program Files\\Microsoft Office\\root\\Office*\\WINWORD.EXE".
38- Examine the process creation history and parent process to identify any unusual or suspicious parent-child relationships that might indicate malicious activity.
39- Check for any recent file modifications or creations in the directory from which the process was executed, which could suggest the presence of a malicious DLL.
40- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, or Microsoft Defender for Endpoint to gather additional context and identify potential patterns of malicious behavior.
41- Assess the risk and impact of the event by considering the risk score and severity level provided, and determine if immediate containment or further investigation is necessary.
42
43### False positive analysis
44
45- Legitimate software updates or installations may temporarily execute trusted Microsoft programs from non-standard paths. Users can create exceptions for known update processes to prevent false alerts.
46- Custom enterprise applications might use renamed instances of trusted Microsoft programs for legitimate purposes. Identify and whitelist these specific applications to avoid unnecessary alerts.
47- Virtual environments or sandboxed applications may execute trusted programs from unusual paths as part of their normal operation. Review and exclude these environments if they are known and trusted.
48- Security or IT administrative tools might mimic trusted Microsoft programs for monitoring or management tasks. Verify these tools and add them to an exception list if they are part of standard operations.
49- Development or testing environments often involve renamed or relocated executables for debugging purposes. Ensure these environments are recognized and excluded from the detection rule to reduce false positives.
50
51### Response and remediation
52
53- Isolate the affected system from the network to prevent further spread of the potential threat and unauthorized access.
54- Terminate the suspicious process identified by the detection rule to stop any ongoing malicious activity.
55- Conduct a forensic analysis of the affected system to identify any malicious DLLs or additional compromised files, and remove them.
56- Restore the affected system from a known good backup to ensure all malicious changes are reverted.
57- Update and patch all software on the affected system, focusing on the trusted Microsoft programs identified in the alert, to mitigate vulnerabilities exploited by DLL side-loading.
58- Monitor the network for any signs of lateral movement or additional compromised systems, using the indicators of compromise identified during the investigation.
59- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or data have been affected."""
60risk_score = 73
61rule_id = "1160dcdb-0a0a-4a79-91d8-9b84616edebd"
62setup = """## Setup
63
64If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
65events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
66Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
67`event.ingested` to @timestamp.
68For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
69"""
70severity = "high"
71tags = [
72 "Domain: Endpoint",
73 "OS: Windows",
74 "Use Case: Threat Detection",
75 "Tactic: Defense Evasion",
76 "Tactic: Execution",
77 "Data Source: Elastic Endgame",
78 "Data Source: Elastic Defend",
79 "Data Source: Sysmon",
80 "Data Source: Microsoft Defender for Endpoint",
81 "Resources: Investigation Guide",
82]
83timestamp_override = "event.ingested"
84type = "eql"
85
86query = '''
87process where host.os.type == "windows" and event.type == "start" and
88 process.pe.original_file_name in ("WinWord.exe", "EXPLORER.EXE", "w3wp.exe", "DISM.EXE") and
89 not process.executable : ("?:\\Windows\\explorer.exe",
90 "?:\\Windows\\SyWOW64\\explorer.exe",
91 "?:\\Program Files\\Microsoft Office\\root\\Office*\\WINWORD.EXE",
92 "?:\\Program Files?(x86)\\Microsoft Office\\root\\Office*\\WINWORD.EXE",
93 "?:\\Windows\\System32\\Dism.exe",
94 "?:\\Windows\\SysWOW64\\Dism.exe",
95 "?:\\Program Files (x86)\\Windows Kits\\10\\Assessment and Deployment Kit\\Deployment Tools\\amd64\\DISM\\dism.exe",
96 "?:\\Windows\\System32\\inetsrv\\w3wp.exe",
97 "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe")
98'''
99
100
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103[[rule.threat.technique]]
104id = "T1036"
105name = "Masquerading"
106reference = "https://attack.mitre.org/techniques/T1036/"
107
108[[rule.threat.technique]]
109id = "T1574"
110name = "Hijack Execution Flow"
111reference = "https://attack.mitre.org/techniques/T1574/"
112[[rule.threat.technique.subtechnique]]
113id = "T1574.002"
114name = "DLL Side-Loading"
115reference = "https://attack.mitre.org/techniques/T1574/002/"
116
117
118
119[rule.threat.tactic]
120id = "TA0005"
121name = "Defense Evasion"
122reference = "https://attack.mitre.org/tactics/TA0005/"
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 DLL Side-Loading via Trusted Microsoft Programs
DLL side-loading exploits the DLL search order to load malicious code into trusted Microsoft programs, which are often whitelisted by security tools. Adversaries rename or relocate these programs to execute unauthorized DLLs, evading detection. The detection rule identifies unusual execution paths or renamed instances of these programs, signaling potential misuse and enabling timely threat response.
Possible investigation steps
- Review the process details to confirm the original file name and the path from which the process was executed. Check if the process.pe.original_file_name matches any of the specified trusted programs like "WinWord.exe", "EXPLORER.EXE", "w3wp.exe", or "DISM.EXE".
- Investigate the process execution path to determine if it deviates from the standard paths listed in the query, such as "?:\Windows\explorer.exe" or "?:\Program Files\Microsoft Office\root\Office*\WINWORD.EXE".
- Examine the process creation history and parent process to identify any unusual or suspicious parent-child relationships that might indicate malicious activity.
- Check for any recent file modifications or creations in the directory from which the process was executed, which could suggest the presence of a malicious DLL.
- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, or Microsoft Defender for Endpoint to gather additional context and identify potential patterns of malicious behavior.
- Assess the risk and impact of the event by considering the risk score and severity level provided, and determine if immediate containment or further investigation is necessary.
False positive analysis
- Legitimate software updates or installations may temporarily execute trusted Microsoft programs from non-standard paths. Users can create exceptions for known update processes to prevent false alerts.
- Custom enterprise applications might use renamed instances of trusted Microsoft programs for legitimate purposes. Identify and whitelist these specific applications to avoid unnecessary alerts.
- Virtual environments or sandboxed applications may execute trusted programs from unusual paths as part of their normal operation. Review and exclude these environments if they are known and trusted.
- Security or IT administrative tools might mimic trusted Microsoft programs for monitoring or management tasks. Verify these tools and add them to an exception list if they are part of standard operations.
- Development or testing environments often involve renamed or relocated executables for debugging purposes. Ensure these environments are recognized and excluded from the detection rule to reduce false positives.
Response and remediation
- Isolate the affected system from the network to prevent further spread of the potential threat and unauthorized access.
- Terminate the suspicious process identified by the detection rule to stop any ongoing malicious activity.
- Conduct a forensic analysis of the affected system to identify any malicious DLLs or additional compromised files, and remove them.
- Restore the affected system from a known good backup to ensure all malicious changes are reverted.
- Update and patch all software on the affected system, focusing on the trusted Microsoft programs identified in the alert, to mitigate vulnerabilities exploited by DLL side-loading.
- Monitor the network for any signs of lateral movement or additional compromised systems, using the indicators of compromise identified during the investigation.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or data have been affected.
Related rules
- Clearing Windows Console History
- Command Shell Activity Started via RunDLL32
- Conhost Spawned By Suspicious Parent Process
- Control Panel Process with Unusual Arguments
- Disabling Windows Defender Security Settings via PowerShell