Suspicious Antimalware Scan Interface DLL
Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusual location. This may indicate an attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/01/17"
3integration = ["windows", "endpoint", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
4maturity = "production"
5updated_date = "2026/04/27"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusual location. This may indicate an
11attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one.
12"""
13from = "now-9m"
14index = [
15 "winlogbeat-*",
16 "logs-endpoint.events.file-*",
17 "logs-windows.sysmon_operational-*",
18 "endgame-*",
19 "logs-sentinel_one_cloud_funnel.*",
20 "logs-m365_defender.event-*",
21 "logs-crowdstrike.fdr*",
22]
23language = "eql"
24license = "Elastic License v2"
25name = "Suspicious Antimalware Scan Interface DLL"
26references = ["https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell"]
27risk_score = 73
28rule_id = "fa488440-04cc-41d7-9279-539387bf2a17"
29severity = "high"
30tags = [
31 "Domain: Endpoint",
32 "OS: Windows",
33 "Use Case: Threat Detection",
34 "Tactic: Defense Evasion",
35 "Data Source: Elastic Endgame",
36 "Resources: Investigation Guide",
37 "Data Source: Elastic Defend",
38 "Data Source: Sysmon",
39 "Data Source: SentinelOne",
40 "Data Source: Microsoft Defender XDR",
41 "Data Source: Crowdstrike",
42]
43timestamp_override = "event.ingested"
44type = "eql"
45
46query = '''
47file where host.os.type == "windows" and event.type != "deletion" and file.path != null and
48 file.name : ("amsi.dll", "amsi") and
49 event.action != "A process changed a file creation time" and
50 not file.path : (
51 "?:\\$SysReset\\CloudImage\\Package_for_RollupFix*\\amsi.dll",
52 "?:\\Windows\\system32\\amsi.dll",
53 "?:\\Windows\\Syswow64\\amsi.dll",
54 "?:\\$WINDOWS.~BT\\*\\amsi.dll",
55 "?:\\Windows\\CbsTemp\\*\\amsi.dll",
56 "?:\\Windows\\SystemTemp\\*\\amsi.dll",
57 "?:\\Windows\\SoftwareDistribution\\Download\\*",
58 "?:\\Windows\\WinSxS\\*\\amsi.dll",
59 "?:\\Windows\\servicing\\*\\amsi.dll",
60 "\\\\?\\Volume{*}\\Windows\\WinSxS\\*\\amsi.dll",
61 "\\\\?\\Volume{*}\\Windows\\system32\\amsi.dll",
62 "\\\\?\\Volume{*}\\Windows\\syswow64\\amsi.dll",
63
64 /* Crowdstrike specific exclusion as it uses NT Object paths */
65 "\\Device\\HarddiskVolume*\\Windows\\system32\\amsi.dll",
66 "\\Device\\HarddiskVolume*\\Windows\\syswow64\\amsi.dll",
67 "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\*\\amsi.dll",
68 "\\Device\\HarddiskVolume*\\$SysReset\\CloudImage\\Package_for_RollupFix*\\amsi.dll",
69 "\\Device\\HarddiskVolume*\\$WINDOWS.~BT\\*\\amsi.dll",
70 "\\Device\\HarddiskVolume*\\Windows\\SoftwareDistribution\\Download\\*\\amsi.dll",
71 "\\Device\\HarddiskVolume*\\Windows\\CbsTemp\\*\\amsi.dll",
72 "\\Device\\HarddiskVolume*\\Windows\\SystemTemp\\*\\amsi.dll",
73 "\\Device\\HarddiskVolume*\\Windows\\servicing\\*\\amsi.dll"
74 )
75'''
76
77note = """## Triage and analysis
78
79### Investigating Suspicious Antimalware Scan Interface DLL
80#### Possible investigation steps
81
82- Does the alert show a rogue AMSI DLL in a path a consumer process could reach?
83 - Why: AMSI DLL hijack works when amsi.dll is placed where a copied or launched AMSI-aware process searches first; copied PowerShell beside the DLL is a distinctive public-tooling pattern.
84 - Focus: `file.path`, `event.action`, and `file.size`, checking writable application, archive extraction, temp, user profile, or working directories outside Windows system and servicing paths.
85 - Implication: escalate when the DLL lands beside or inside a reachable search-order path for PowerShell, pwsh, wscript, cscript, mshta, Office, or another AMSI-aware consumer; lower concern only when the path is a lab or package-test directory unreachable by a copied consumer and content evidence fits that test.
86
87- Did the writer and parent context fit that DLL placement?
88 - Focus: `process.executable`, `process.command_line`, `process.hash.sha256`, `process.parent.command_line`, `user.id`, and `host.id`.
89 - Implication: escalate when the writer is user-writable, script- or shell-launched, newly seen by hash, or started through ad hoc remote administration; lower concern only when writer identity, parent command line, account, and host match one recognized validation workflow. Writer identity alone never clears the placement.
90
91- Did the same writer stage the full DLL-hijack pattern?
92 - Focus: file events on the same `host.id` and `process.entity_id`, especially `file.path`, `event.action`, and `file.size`. $investigate_0
93 - Implication: escalate when the writer also drops copied powershell.exe, pwsh.exe, a script host, loader script, or renamed DLL beside the new amsi.dll; lower concern only when all artifacts stay inside one controlled validation directory and no consumer starts from it.
94
95- Did a process load or reuse the created DLL path?
96 - Focus: with library-load telemetry, pivot from `host.id` plus `file.path` to events where `dll.path` equals the created path, then read loader `process.executable`, `process.command_line`, and `@timestamp`; missing library-load telemetry leaves execution unresolved, not benign. $investigate_1
97 - Hint: with only file telemetry, treat later writes or touches of the same `file.path` as reuse clues, not module-load proof.
98 - Implication: escalate when PowerShell, pwsh, wscript, cscript, mshta, Office, or another AMSI-aware process loads or reuses the path after creation; unresolved load evidence keeps the case at staging unless other local evidence corroborates abuse.
99
100- Did process execution show use of the hijack directory or another AMSI-bypass path?
101 - Focus: process starts on the same `host.id` and `user.id`, especially `process.executable`, `process.command_line`, and `process.parent.command_line`. $investigate_2
102 - Implication: escalate when copied PowerShell or a script host starts from the DLL directory, a consumer process uses that directory as its working directory, or command lines show PowerShell v2 launch; lower concern only when execution stays limited to the same controlled validation workflow.
103
104- If local evidence is suspicious or unresolved, is the scope still limited to this host?
105 - Focus: related alerts for `host.id`; use `user.id` only when the writer maps to one stable identity, then compare `file.path`, `process.hash.sha256`, and `process.command_line` patterns. $investigate_4
106 - Hint: use the user-scoped alert view only after the writer identity is stable enough to test account-level spread. $investigate_3
107 - Implication: broaden response when the same host or user shows additional AMSI, suspicious library-load, script-control, persistence, or payload-staging alerts; keep scope local when this is a single bounded placement with no corroborating chain.
108
109- Escalate when suspicious placement has any meaningful corroborator: copied consumer staging, load or reuse, suspicious lineage, execution from the DLL directory, or related evasion alerts. Close only when placement, writer, staging/load result, execution context, and outside validation all bind to authorized testing; preserve artifacts and escalate when evidence is mixed, missing, or contradictory.
110
111### False positive analysis
112
113- Authorized malware-research, red-team, defensive-validation, or package testing that intentionally exercises AMSI search-order behavior is the credible benign path. Confirm `file.path` stays in a lab-only or test-package location; `process.executable`, `process.command_line`, `process.hash.sha256`, `user.id`, and `host.id` map to that workflow; no copied script host launches outside the test; and available load evidence comes from the expected harness. If schedules or inventories are unavailable, require current telemetry to prove the same lab or test harness; use recurrence only for exception design, not closure. If path, writer, load target, or execution context diverges, do not close as benign.
114- Before creating an exception, validate the same `process.executable`, `process.hash.sha256`, parent workflow, `file.path`, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that workflow pattern. Avoid exceptions on amsi.dll alone, a directory fragment alone, or the host alone.
115
116### Response and remediation
117
118- If confirmed benign, reverse temporary containment and record which evidence proved the workflow: `file.path`, writer identity, `process.parent.command_line`, account and host scope, staging pattern, and any available load or harness evidence. Create an exception only after that workflow recurs across prior alerts from this rule.
119- If suspicious but unconfirmed, preserve the created `file.path`, writer `process.entity_id`, `process.command_line`, parent lineage, sibling staged files, load or reuse evidence when available, and related-alert context before containment. Apply reversible containment tied to the findings, and avoid deleting the DLL until load or reuse is understood.
120- If confirmed malicious, isolate the endpoint or contain the responsible account according to the confirmed writer, copied consumer, and execution evidence. Before termination or cleanup, record the writer process details, DLL path, copied consumer executable, load evidence when available, and sibling scripts or payloads; weigh host criticality before isolation.
121- Remove the rogue DLL, copied PowerShell or script-host binaries, loader scripts, and sibling payloads found during the investigation, then restore the affected application or working directory from known-good content and verify the legitimate system AMSI locations remain intact.
122- If a target process loaded the rogue DLL, capture module and process evidence before restart or termination, then reverse any companion AMSI weakening found through process command lines or staged scripts.
123- After containment, scope the same writer identity, DLL path pattern, copied consumer pattern, parent workflow, and companion AMSI-bypass behavior across other hosts, and retain the supporting file, process, and library-load evidence when available.
124"""
125
126setup = """## Setup
127
128This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
129
130Setup instructions: https://ela.st/install-elastic-defend
131
132### Additional data sources
133
134This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
135
136- [CrowdStrike](https://ela.st/crowdstrike-integration)
137- [Microsoft Defender XDR](https://ela.st/m365-defender)
138- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
139- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
140"""
141
142[rule.investigation_fields]
143field_names = [
144 "@timestamp",
145 "event.action",
146 "host.name",
147 "host.id",
148 "user.name",
149 "user.id",
150 "user.domain",
151 "process.entity_id",
152 "process.pid",
153 "process.executable",
154 "process.command_line",
155 "file.path",
156 "file.name",
157 "file.extension",
158 "file.size",
159]
160
161[transform]
162
163[[transform.investigate]]
164label = "File events for the writer process"
165description = ""
166providers = [
167 [
168 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
169 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
170 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
171 ]
172]
173relativeFrom = "now-24h/h"
174relativeTo = "now"
175
176[[transform.investigate]]
177label = "Events for the created DLL path"
178description = ""
179providers = [
180 [
181 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
182 { excluded = false, field = "file.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }
183 ],
184 [
185 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
186 { excluded = false, field = "dll.path", queryType = "phrase", value = "{{file.path}}", valueType = "string" }
187 ]
188]
189relativeFrom = "now-24h/h"
190relativeTo = "now"
191
192[[transform.investigate]]
193label = "Process events for the same host and user"
194description = ""
195providers = [
196 [
197 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
198 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" },
199 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
200 ]
201]
202relativeFrom = "now-1h"
203relativeTo = "now"
204
205[[transform.investigate]]
206label = "Alerts associated with the user"
207description = ""
208providers = [
209 [
210 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
211 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
212 ]
213]
214relativeFrom = "now-48h/h"
215relativeTo = "now"
216
217[[transform.investigate]]
218label = "Alerts associated with the host"
219description = ""
220providers = [
221 [
222 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
223 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
224 ]
225]
226relativeFrom = "now-48h/h"
227relativeTo = "now"
228
229[[rule.threat]]
230framework = "MITRE ATT&CK"
231[[rule.threat.technique]]
232id = "T1562"
233name = "Impair Defenses"
234reference = "https://attack.mitre.org/techniques/T1562/"
235[[rule.threat.technique.subtechnique]]
236id = "T1562.001"
237name = "Disable or Modify Tools"
238reference = "https://attack.mitre.org/techniques/T1562/001/"
239
240[[rule.threat.technique]]
241id = "T1574"
242name = "Hijack Execution Flow"
243reference = "https://attack.mitre.org/techniques/T1574/"
244[[rule.threat.technique.subtechnique]]
245id = "T1574.001"
246name = "DLL"
247reference = "https://attack.mitre.org/techniques/T1574/001/"
248
249[rule.threat.tactic]
250id = "TA0005"
251name = "Defense Evasion"
252reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating Suspicious Antimalware Scan Interface DLL
Possible investigation steps
-
Does the alert show a rogue AMSI DLL in a path a consumer process could reach?
- Why: AMSI DLL hijack works when amsi.dll is placed where a copied or launched AMSI-aware process searches first; copied PowerShell beside the DLL is a distinctive public-tooling pattern.
- Focus:
file.path,event.action, andfile.size, checking writable application, archive extraction, temp, user profile, or working directories outside Windows system and servicing paths. - Implication: escalate when the DLL lands beside or inside a reachable search-order path for PowerShell, pwsh, wscript, cscript, mshta, Office, or another AMSI-aware consumer; lower concern only when the path is a lab or package-test directory unreachable by a copied consumer and content evidence fits that test.
-
Did the writer and parent context fit that DLL placement?
- Focus:
process.executable,process.command_line,process.hash.sha256,process.parent.command_line,user.id, andhost.id. - Implication: escalate when the writer is user-writable, script- or shell-launched, newly seen by hash, or started through ad hoc remote administration; lower concern only when writer identity, parent command line, account, and host match one recognized validation workflow. Writer identity alone never clears the placement.
- Focus:
-
Did the same writer stage the full DLL-hijack pattern?
- Focus: file events on the same
host.idandprocess.entity_id, especiallyfile.path,event.action, andfile.size. $investigate_0 - Implication: escalate when the writer also drops copied powershell.exe, pwsh.exe, a script host, loader script, or renamed DLL beside the new amsi.dll; lower concern only when all artifacts stay inside one controlled validation directory and no consumer starts from it.
- Focus: file events on the same
-
Did a process load or reuse the created DLL path?
- Focus: with library-load telemetry, pivot from
host.idplusfile.pathto events wheredll.pathequals the created path, then read loaderprocess.executable,process.command_line, and@timestamp; missing library-load telemetry leaves execution unresolved, not benign. $investigate_1 - Hint: with only file telemetry, treat later writes or touches of the same
file.pathas reuse clues, not module-load proof. - Implication: escalate when PowerShell, pwsh, wscript, cscript, mshta, Office, or another AMSI-aware process loads or reuses the path after creation; unresolved load evidence keeps the case at staging unless other local evidence corroborates abuse.
- Focus: with library-load telemetry, pivot from
-
Did process execution show use of the hijack directory or another AMSI-bypass path?
- Focus: process starts on the same
host.idanduser.id, especiallyprocess.executable,process.command_line, andprocess.parent.command_line. $investigate_2 - Implication: escalate when copied PowerShell or a script host starts from the DLL directory, a consumer process uses that directory as its working directory, or command lines show PowerShell v2 launch; lower concern only when execution stays limited to the same controlled validation workflow.
- Focus: process starts on the same
-
If local evidence is suspicious or unresolved, is the scope still limited to this host?
- Focus: related alerts for
host.id; useuser.idonly when the writer maps to one stable identity, then comparefile.path,process.hash.sha256, andprocess.command_linepatterns. $investigate_4 - Hint: use the user-scoped alert view only after the writer identity is stable enough to test account-level spread. $investigate_3
- Implication: broaden response when the same host or user shows additional AMSI, suspicious library-load, script-control, persistence, or payload-staging alerts; keep scope local when this is a single bounded placement with no corroborating chain.
- Focus: related alerts for
-
Escalate when suspicious placement has any meaningful corroborator: copied consumer staging, load or reuse, suspicious lineage, execution from the DLL directory, or related evasion alerts. Close only when placement, writer, staging/load result, execution context, and outside validation all bind to authorized testing; preserve artifacts and escalate when evidence is mixed, missing, or contradictory.
False positive analysis
- Authorized malware-research, red-team, defensive-validation, or package testing that intentionally exercises AMSI search-order behavior is the credible benign path. Confirm
file.pathstays in a lab-only or test-package location;process.executable,process.command_line,process.hash.sha256,user.id, andhost.idmap to that workflow; no copied script host launches outside the test; and available load evidence comes from the expected harness. If schedules or inventories are unavailable, require current telemetry to prove the same lab or test harness; use recurrence only for exception design, not closure. If path, writer, load target, or execution context diverges, do not close as benign. - Before creating an exception, validate the same
process.executable,process.hash.sha256, parent workflow,file.path,user.id, andhost.idrecur across prior alerts from this rule. Build the exception from that workflow pattern. Avoid exceptions on amsi.dll alone, a directory fragment alone, or the host alone.
Response and remediation
- If confirmed benign, reverse temporary containment and record which evidence proved the workflow:
file.path, writer identity,process.parent.command_line, account and host scope, staging pattern, and any available load or harness evidence. Create an exception only after that workflow recurs across prior alerts from this rule. - If suspicious but unconfirmed, preserve the created
file.path, writerprocess.entity_id,process.command_line, parent lineage, sibling staged files, load or reuse evidence when available, and related-alert context before containment. Apply reversible containment tied to the findings, and avoid deleting the DLL until load or reuse is understood. - If confirmed malicious, isolate the endpoint or contain the responsible account according to the confirmed writer, copied consumer, and execution evidence. Before termination or cleanup, record the writer process details, DLL path, copied consumer executable, load evidence when available, and sibling scripts or payloads; weigh host criticality before isolation.
- Remove the rogue DLL, copied PowerShell or script-host binaries, loader scripts, and sibling payloads found during the investigation, then restore the affected application or working directory from known-good content and verify the legitimate system AMSI locations remain intact.
- If a target process loaded the rogue DLL, capture module and process evidence before restart or termination, then reverse any companion AMSI weakening found through process command lines or staged scripts.
- After containment, scope the same writer identity, DLL path pattern, copied consumer pattern, parent workflow, and companion AMSI-bypass behavior across other hosts, and retain the supporting file, process, and library-load evidence when available.
References
Related rules
- Modification of AmsiEnable Registry Key
- Command Obfuscation via Unicode Modifier Letters
- Potential Remote Install via MsiExec
- Suspicious Microsoft Diagnostics Wizard Execution
- Attempt to Install or Run Kali Linux via WSL