Suspicious Execution from a Mounted Device
Identifies when a script interpreter or signed binary is launched via a non-standard working directory. An attacker may use this technique to evade defenses.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/05/28"
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 when a script interpreter or signed binary is launched via a non-standard working directory. An attacker may
13use this technique to evade defenses.
14"""
15from = "now-9m"
16index = ["winlogbeat-*", "logs-endpoint.events.process-*", "logs-windows.sysmon_operational-*"]
17language = "eql"
18license = "Elastic License v2"
19name = "Suspicious Execution from a Mounted Device"
20references = [
21 "https://www.microsoft.com/security/blog/2021/05/27/new-sophisticated-email-based-attack-from-nobelium/",
22 "https://www.volexity.com/blog/2021/05/27/suspected-apt29-operation-launches-election-fraud-themed-phishing-campaigns/",
23]
24risk_score = 47
25rule_id = "8a1d4831-3ce6-4859-9891-28931fa6101d"
26setup = """## Setup
27
28If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
29events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
30Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
31`event.ingested` to @timestamp.
32For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
33"""
34severity = "medium"
35tags = [
36 "Domain: Endpoint",
37 "OS: Windows",
38 "Use Case: Threat Detection",
39 "Tactic: Defense Evasion",
40 "Tactic: Execution",
41 "Data Source: Elastic Defend",
42 "Data Source: Sysmon",
43 "Resources: Investigation Guide",
44]
45timestamp_override = "event.ingested"
46type = "eql"
47
48query = '''
49process where host.os.type == "windows" and event.type == "start" and process.executable : "C:\\*" and
50 (process.working_directory : "?:\\" and not process.working_directory: "C:\\") and
51 process.parent.name : "explorer.exe" and
52 process.name : ("rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe",
53 "cscript.exe", "wscript.exe")
54'''
55note = """## Triage and analysis
56
57> **Disclaimer**:
58> 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.
59
60### Investigating Suspicious Execution from a Mounted Device
61
62In Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when triggered by common parent processes like explorer.exe, thus flagging potential defense evasion attempts.
63
64### Possible investigation steps
65
66- Review the process details to confirm the executable path and working directory, ensuring they match the criteria of being launched from a non-standard directory (e.g., not from "C:\\\\").
67- Investigate the parent process, explorer.exe, to determine if there are any unusual activities or user actions that might have triggered the suspicious execution.
68- Check the user account associated with the process to verify if the activity aligns with their typical behavior or if the account might be compromised.
69- Analyze the command line arguments used by the suspicious process to identify any potentially malicious scripts or commands being executed.
70- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
71- Examine the mounted device from which the process was executed to determine its origin, legitimacy, and any associated files that might be malicious.
72
73### False positive analysis
74
75- Legitimate software installations or updates may trigger the rule if they are executed from a mounted device. Users can create exceptions for known software update processes that are verified as safe.
76- Portable applications running from USB drives or external storage can be flagged. To mitigate this, users should whitelist specific applications that are frequently used and deemed non-threatening.
77- IT administrative scripts executed from network shares or mounted drives for maintenance tasks might be detected. Users can exclude these scripts by specifying trusted network paths or script names.
78- Development environments where scripts are tested from non-standard directories can cause alerts. Developers should ensure their working directories are recognized as safe or use designated development machines with adjusted monitoring rules.
79- Backup or recovery operations that utilize mounted devices for script execution may be misidentified. Users should identify and exclude these operations by defining exceptions for known backup tools and processes.
80
81### Response and remediation
82
83- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
84- Terminate any suspicious processes identified by the detection rule, such as those initiated by script interpreters or signed binaries from non-standard directories.
85- Conduct a forensic analysis of the mounted device and the affected system to identify any malicious payloads or scripts and remove them.
86- Review and restore any altered system configurations or registry settings to their original state to ensure system integrity.
87- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker.
88- Monitor for any recurrence of similar activities by enhancing logging and alerting mechanisms, focusing on process execution from non-standard directories.
89- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
90
91
92[[rule.threat]]
93framework = "MITRE ATT&CK"
94[[rule.threat.technique]]
95id = "T1218"
96name = "System Binary Proxy Execution"
97reference = "https://attack.mitre.org/techniques/T1218/"
98[[rule.threat.technique.subtechnique]]
99id = "T1218.005"
100name = "Mshta"
101reference = "https://attack.mitre.org/techniques/T1218/005/"
102
103[[rule.threat.technique.subtechnique]]
104id = "T1218.010"
105name = "Regsvr32"
106reference = "https://attack.mitre.org/techniques/T1218/010/"
107
108[[rule.threat.technique.subtechnique]]
109id = "T1218.011"
110name = "Rundll32"
111reference = "https://attack.mitre.org/techniques/T1218/011/"
112
113
114
115[rule.threat.tactic]
116id = "TA0005"
117name = "Defense Evasion"
118reference = "https://attack.mitre.org/tactics/TA0005/"
119[[rule.threat]]
120framework = "MITRE ATT&CK"
121[[rule.threat.technique]]
122id = "T1059"
123name = "Command and Scripting Interpreter"
124reference = "https://attack.mitre.org/techniques/T1059/"
125[[rule.threat.technique.subtechnique]]
126id = "T1059.001"
127name = "PowerShell"
128reference = "https://attack.mitre.org/techniques/T1059/001/"
129
130[[rule.threat.technique.subtechnique]]
131id = "T1059.003"
132name = "Windows Command Shell"
133reference = "https://attack.mitre.org/techniques/T1059/003/"
134
135
136
137[rule.threat.tactic]
138id = "TA0002"
139name = "Execution"
140reference = "https://attack.mitre.org/tactics/TA0002/"
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 Suspicious Execution from a Mounted Device
In Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when triggered by common parent processes like explorer.exe, thus flagging potential defense evasion attempts.
Possible investigation steps
- Review the process details to confirm the executable path and working directory, ensuring they match the criteria of being launched from a non-standard directory (e.g., not from "C:\").
- Investigate the parent process, explorer.exe, to determine if there are any unusual activities or user actions that might have triggered the suspicious execution.
- Check the user account associated with the process to verify if the activity aligns with their typical behavior or if the account might be compromised.
- Analyze the command line arguments used by the suspicious process to identify any potentially malicious scripts or commands being executed.
- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise.
- Examine the mounted device from which the process was executed to determine its origin, legitimacy, and any associated files that might be malicious.
False positive analysis
- Legitimate software installations or updates may trigger the rule if they are executed from a mounted device. Users can create exceptions for known software update processes that are verified as safe.
- Portable applications running from USB drives or external storage can be flagged. To mitigate this, users should whitelist specific applications that are frequently used and deemed non-threatening.
- IT administrative scripts executed from network shares or mounted drives for maintenance tasks might be detected. Users can exclude these scripts by specifying trusted network paths or script names.
- Development environments where scripts are tested from non-standard directories can cause alerts. Developers should ensure their working directories are recognized as safe or use designated development machines with adjusted monitoring rules.
- Backup or recovery operations that utilize mounted devices for script execution may be misidentified. Users should identify and exclude these operations by defining exceptions for known backup tools and processes.
Response and remediation
- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified by the detection rule, such as those initiated by script interpreters or signed binaries from non-standard directories.
- Conduct a forensic analysis of the mounted device and the affected system to identify any malicious payloads or scripts and remove them.
- Review and restore any altered system configurations or registry settings to their original state to ensure system integrity.
- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker.
- Monitor for any recurrence of similar activities by enhancing logging and alerting mechanisms, focusing on process execution from non-standard directories.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
References
Related rules
- Command Shell Activity Started via RunDLL32
- Control Panel Process with Unusual Arguments
- ImageLoad via Windows Update Auto Update Client
- Microsoft Build Engine Started by a System Process
- Persistence via Hidden Run Key Detected