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/"
...
toml

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.

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.

  • 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.
  • 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.
  • 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

to-top