# AMSI: The Pre-Execution Window Where Defender Catches a Base64 Payload It Has Never Seen Before
> How the Antimalware Scan Interface scans script content after deobfuscation but before execution, the seven runtimes it plugs into, and the nearly seven-year bypass arms race that followed.
*Published: 2026-05-12*
*Canonical: https://paragmali.com/blog/amsi-the-100-microsecond-window-where-defender-catches-a-bas*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
AMSI is a seven-function Win32 API plus a COM provider model that lets any script engine hand its post-deobfuscation buffer to a registered antimalware provider, synchronously, before the engine executes the buffer. Microsoft Defender's `MpOav.dll` is the default provider. It is the single most consequential malware-defense primitive Microsoft shipped between Authenticode and Smart App Control, and it is not, by Microsoft's own published position, a security boundary. This article walks the architecture, the seven-runtime call-site catalogue (PowerShell, WSH, Office VBA, Excel XLM, .NET 4.8, WMI, Windows 11 in-memory), the six bypass eras since 2016, and the open problems on the 2026 frontier.
## 1. A 200-Millisecond Story
A user opens a Word document attached to a phishing email. The macro decodes a base64 blob, XORs the result against a four-byte key cached in a worksheet cell, and pastes the cleartext into a string variable. The variable holds a single PowerShell command: an `Invoke-Expression` of a 12-layer obfuscated stager whose final payload is `Invoke-Mimikatz`.
Two hundred milliseconds later, [Microsoft Defender](/blog/the-defenders-dilemma-how-microsoft-won-the-antivirus-war-it/) flags the deobfuscated string `Invoke-Mimikatz` and refuses to run it. Not the base64. Not the XOR. Not the macro. The actual deobfuscated PowerShell, in the form the PowerShell tokenizer was about to execute.
No signature for this exact payload existed yesterday. The defender never read the document, never broke the encryption, and never emulated PowerShell. So how did it see the cleartext?
The answer is a seven-function Win32 API called the Antimalware Scan Interface [@amsi-portal], or AMSI, and it is the single most consequential malware-defense primitive Microsoft has shipped since [Authenticode](/blog/who-is-this-code----the-quiet-33-year-reinvention-of-app-ide/). AMSI is the only Windows primitive that scans what the script engine actually decided to run, after every layer of obfuscation has been undone, and before the engine commits to running it.
A versatile Win32 interface standard that lets applications and services pass the post-deobfuscation buffer they are about to execute to any registered antimalware product on the machine. AMSI ships in `amsi.dll` and is integrated into PowerShell, Windows Script Host, Office VBA, Excel 4.0 macros, .NET Framework 4.8, WMI, and User Account Control, among other hosts [@amsi-portal][@msec-xlm-amsi-2021][@amsi-on-mdav].
This article is for four audiences. Windows application developers who want to know how to integrate AMSI without introducing the usual four bugs. Detection engineers who want to know what AMSI emits, where, and how to hunt across it. Red-team operators who want to know which 2016-era bypasses still work in 2026 and which generate so much telemetry they are not worth the risk. AV and EDR vendors who want to register their own provider and not get out-competed by the default one.
To understand how AMSI works, we have to understand why the 25 years of antivirus that preceded it could not.
The 200-millisecond figure in the hook is approximate. Microsoft's August 2020 disclosure of Defender's pair-of-classifiers architecture [@msec-amsi-ml-2020] describes "performance-optimized" on-endpoint classifiers that hand off to the cloud only when content is classified as suspicious. The 200 ms in the scene above includes that cloud round trip.
## 2. Why Static AV Failed: 25 Years of the Obfuscation Arms Race
Consider a benign one-liner:
```powershell
Write-Host 'pwnd!'
```
A signature on that exact byte string catches the lazy attacker, and only the lazy attacker. The next attacker writes:
```powershell
Write-Host ('pwn' + 'd!')
```
The signature dies. So the defender starts emulating expression-evaluation; the attacker switches to `Invoke-Expression` of a concatenated string; the defender starts emulating `Invoke-Expression`; the attacker base64-encodes the inner script; the defender starts decoding base64 strings; the attacker XORs the base64 against a key cached in a worksheet cell; and at some point in this regress the antivirus engine is, in effect, a re-implementation of PowerShell, except slower, more buggy, and one Patch Tuesday behind. Lee Holmes called out the dead end explicitly in his June 9, 2015 disclosure: at the obfuscated leaf of this regress, "we're generally past what antivirus engines will emulate or detect, so we won't necessarily detect what this script is actually doing," and even where a defender writes a signature for an obfuscator's pattern, "a signature for it would generate an unacceptable number of false positives" [@holmes-2015-wayback].
The ladder was not theoretical. It was the operating reality of script-borne malware for 20 years.
In 1995, WM/Concept [@wiki-concept] became the first widely propagated Word macro virus and established the scriptable-host-as-malware-surface architecture: a benign-looking document carrying executable VBA inside it. On May 4, 2000, a 10 KB VBScript called ILOVEYOU [@wiki-iloveyou] ran through Windows Script Host on roughly 10 percent of all internet-connected computers and caused an estimated US\$10 to \$15 billion in damages. ILOVEYOU made the architectural diagnosis unmistakable: built-in script engines are a malware-execution surface that defenders cannot wish away.
By 2014, the surface had matured into a thriving offensive tradecraft: PowerSploit, PowerView, Invoke-Mimikatz, and the Empire C2 framework all ran fileless inside `powershell.exe` memory after deobfuscation. On-disk antivirus saw only the encoded wrapper, not the deobfuscated payload that actually ran.
Daniel Bohannon would close the file on signature-based defenses publicly at DerbyCon 6.0 on September 25, 2016 with Invoke-Obfuscation [@invoke-obfuscation], a PowerShell obfuscator that automated the regress above and turned every public-script signature into a one-bug-away walking target. Bohannon's release was a refutation, not a tool: it showed that any defender path that pattern-matched on obfuscation artifacts was a path to an unbounded backlog.
The diagnosis that Holmes named in 2015 and that Bohannon proved a year later is structural. Detection must happen *after* deobfuscation (so the obfuscation does not hide the payload), *before* execution (so the detector can still refuse), and *in the engine that did the deobfuscation* (because only that engine ever holds the deobfuscated bytes). In 2014, no Windows API did that. The next ten years are the story of building one.
## 3. The Pre-AMSI Patchwork
Before AMSI, Microsoft and the AV industry shipped four partial answers. Each one closed some of the gap. None closed all of it, because each one was wedged at the wrong place in the pipeline. Here is the timeline of what was tried, when, and what each attempt missed.
gantt
title Pre-AMSI script-malware defense timeline
dateFormat YYYY-MM
axisFormat %Y
section Threats
WM/Concept (Word macro) :done, threat1, 1995-08, 1825d
ILOVEYOU (WSH+VBScript) :done, threat2, 2000-05, 1d
Fileless PowerShell era :done, threat3, 2014-01, 730d
Invoke-Obfuscation release :crit, threat4, 2016-09-25, 1d
section Defenses
IOfficeAntiVirus (file-open) :defense1, 1997-01, 6570d
Module Logging Event 4103 :defense2, 2012-08, 1095d
Script Block Logging 4104 :defense3, 2015-07-29, 365d
AMSI in PowerShell 5.0 :crit, defense4, 2015-07-29, 1d
The first attempt was `IOfficeAntiVirus`, a COM interface Office 97 introduced in 1997 and that Office 2000 through Office 2010 carried forward. AV products implemented the interface; Office called into it at file-open time. The interface saw the document on disk, before VBA ran. It defeated the 1995-era macro virus that arrived with its payload literal in the document body. It defeated nothing once the VBA runtime started doing AutoOpen-time `Application.Run` of strings decoded from cells, because the decoded string was never on disk. The Office 365 Threat Research team's 2018 retrospective on the limitation [@msec-vba-amsi-2018] is direct: file-open AV does not see what the VBA runtime decides to run at runtime.
The second attempt was PowerShell module logging, shipped in PowerShell 3.0 in 2012 [@wiki-powershell] as Event ID 4103. It records, after the fact, that a cmdlet ran with a given parameter binding [@ps-logging-windows]. It is forensic, not preventive: by the time Event 4103 is in the Windows Event Log, the cmdlet has already returned. And it records the bound parameters, not the contents of `Invoke-Expression`'s argument string, so it sees the call but not the payload.
The third attempt, shipped on July 29, 2015 alongside Windows 10 1507 and PowerShell 5.0, was Script Block Logging [@ps-logging-windows]. Script Block Logging emits Event ID 4104 with the deobfuscated script block, captured from inside the PowerShell parser on its way to the executor. This is the right artifact at the right moment in terms of *what* it sees, but the wrong relationship in terms of *what it can do with what it sees*: Event 4104 is asynchronous and observation-only. It cannot refuse the script that produced it. It can only tell the SOC what ran, after it ran.
A PowerShell 5.0 feature that records every deobfuscated script block to the `Microsoft-Windows-PowerShell/Operational` event log channel as Event 4104. It is a post-hoc forensic record: it captures the cleartext after the parser has emitted it on its way to the executor, but the executor still runs the script [@ps-logging-windows].
The fourth attempt was the antivirus industry's own response to the gap: bring the script-engine emulators in-house. Implement a JScript emulator inside the AV engine, a VBScript emulator inside the AV engine, a PowerShell emulator inside the AV engine. Run the obfuscated source through your private emulator and inspect what comes out. This was the regress Holmes described as "fragile" in 2015. Every new feature in every shipped engine version was a maintenance bill the AV vendor had to pay. PowerShell shipped a new release every couple of years; JScript varied across IE6/IE7/IE8/Edge/WSH; VBScript varied across WSH and Office. The half-life of any one emulator was short.
Lee Holmes summarized the dead end in one sentence in his June 9, 2015 post: "antimalware software starts to do basic language emulation," but "this is a fairly fragile approach" [@holmes-2015-wayback]. The next paragraph in this article is the same paragraph in his.
## 4. The 2015 Eureka: Lee Holmes and the Birth of AMSI
On June 9, 2015, Lee Holmes published *Windows 10 to Offer Application Developers New Malware Defenses* [@holmes-2015-wayback] on the Microsoft Security Blog. It is the most important malware-defense blog post Microsoft has ever shipped. The same day, Holmes also published *PowerShell the Blue Team* [@holmes-blue-team], which named the assume-breach mindset that made AMSI's design possible.
The architectural fix Holmes named is the one the previous section's frustration sets up. Applications hand the post-deobfuscation buffer to AMSI. AMSI hands it to a registered antimalware provider. The provider returns a verdict. If the verdict is "malware," the application refuses to execute the buffer. The whole exchange happens synchronously, in the calling process, before the engine commits.
While the malicious script might go through several passes of deobfuscation, it ultimately needs to supply the scripting engine with plain, unobfuscated code.
-- Lee Holmes, Microsoft Security Blog, June 9, 2015
The same observation appears verbatim on the live Microsoft Learn `how-amsi-helps` page [@amsi-howto], which carries Holmes 2015's argument forward in Microsoft's current documentation: "Script (malicious or otherwise), might go through several passes of de-obfuscation. But you ultimately need to supply the scripting engine with plain, un-obfuscated code." The dual primary-source anchor makes the citation durable against future Wayback rot.
That one sentence is the design of AMSI in compressed form. The defender stops trying to reason about the obfuscated source. It reasons about what the engine decided to run. The engine's deobfuscation work is now the defender's free lunch.
The release vehicle was Windows 10 1507 on July 29, 2015, paired with PowerShell 5.0 [@wiki-win10-versions]. The companion piece, "PowerShell the Blue Team" [@holmes-blue-team], framed the broader assume-breach posture: "What did they do? What systems did they connect to? Was any dynamic code invoked, and what was it?" The trio of features Holmes shipped that day -- AMSI, Script Block Logging, and the over-the-shoulder transcripts -- was designed to answer those three questions together.
The companion "PowerShell heart the Blue Team" devblogs post is not optional reading if you want the full context. Holmes published the two posts on the same day for a reason: AMSI is the synchronous-blocking sibling, Script Block Logging is the forensic sibling, and Constrained Language Mode is the policy-denial sibling. The trio is co-designed [@holmes-blue-team].
The architectural insight that closed the loop is small to state and large to absorb. For 20 years the AV industry had been arguing about what to *scan*. Holmes pointed out that the answer was about *when* to scan. The naive on-disk and on-event-log approaches had failed not because their pattern matching was poor but because they were inspecting the wrong artifact at the wrong moment. The only software that ever holds the deobfuscated bytes is the engine that will execute them. The only moment that artifact exists is the moment just before the executor commits. The only place a defender can stand and see the buffer is inside that engine's process.
That is the answer Holmes named, and it is the answer Microsoft has spent the last ten years implementing across seven runtimes and defending against six bypass eras. The next section is the architecture of what Holmes named.
## 5. The AMSI Architecture: Two API Surfaces, One Provider Model
AMSI is two API surfaces (flat C and COM) and one provider model. The flat-C surface is what script-engine hosts call; the COM surface is what AV providers implement. Both surfaces converge on the same `amsi.dll`, and `amsi.dll` runs in the calling process. Here is the full hot path for one PowerShell command.
sequenceDiagram
autonumber
participant User
participant PS as powershell.exe
participant AU as AmsiUtils.ScanContent
participant AD as amsi.dll
participant MP as MpOav.dll (in-process)
participant ME as MsMpEng.exe (PPL)
User->>PS: iex ([Convert]::FromBase64String($stager))
PS->>PS: tokenize, expand, deobfuscate
PS->>AU: ScanContent(buf, name, session)
AU->>AD: AmsiScanBuffer(ctx, buf, len, name, session, out result)
AD->>MP: IAntimalwareProvider::Scan(stream)
MP->>ME: local RPC: scan(stream)
ME-->>MP: AMSI_RESULT_DETECTED (>= 32768)
MP-->>AD: HRESULT S_OK, result set
AD-->>AU: AMSI_RESULT_DETECTED
AU-->>PS: AmsiResultIsMalware(result) == TRUE
PS-->>User: ParseException: script content is malicious
### 5.1 The Win32 flat-C API
The flat-C surface is seven functions, declared in `amsi.h`, exported from `amsi.dll`, with minimum support Windows 10 / Windows Server 2016 [@amsi-scanbuffer]. A host typically calls them in this order:
1. `AmsiInitialize(LPCWSTR appName, HAMSICONTEXT *amsiContext)` once at startup. The `appName` string identifies the host: PowerShell passes `"PowerShell_"`, .NET passes `"DotNet"`, Office passes its application name [@amsi-initialize]. The string later surfaces in telemetry as `DeviceEvents.AmsiProcessName`.
2. `AmsiOpenSession(HAMSICONTEXT, HAMSISESSION *session)` per logical user command. The session handle is a correlation primitive: multiple `AmsiScanBuffer` calls inside one session let the provider re-join partial deobfuscations into one decision [@amsi-opensession].
3. `AmsiScanBuffer(ctx, buffer, length, contentName, session, &result)` per buffer. This is the hot path. `contentName` is a human-readable label the SOC analyst will see [@amsi-scanbuffer].
4. `AmsiResultIsMalware(result)` to interpret the out parameter. The macro evaluates to non-zero when the AMSI_RESULT is at or above 32768 [@amsi-resultismalware].
5. `AmsiCloseSession` to release the session handle.
6. `AmsiUninitialize` at shutdown.
The seventh function, `AmsiScanString`, is a thin wrapper that takes a wide-character string instead of a buffer-plus-length pair. Microsoft replaced PowerShell's `AmsiScanString` call site with `AmsiScanBuffer` in Windows 10 1709 as part of the response to the first CyberArk in-memory patch attack [@cyberark-redux]; we will return to that in §8.
The flat-C Win32 function any AMSI-aware host calls to submit a buffer for scanning. Signature: `HRESULT AmsiScanBuffer(HAMSICONTEXT amsiContext, PVOID buffer, ULONG length, LPCWSTR contentName, HAMSISESSION amsiSession, AMSI_RESULT *result)`. Returns S_OK on a completed scan; the verdict is delivered through the `result` out parameter. Minimum support Windows 10 desktop / Windows Server 2016 [@amsi-scanbuffer].
The `AMSI_RESULT` enumeration is the interface contract for verdicts. The values are:
| Value | Name | Semantics |
|---------------:|------------------------------|----------------------------------------------------------|
| 0 | AMSI_RESULT_CLEAN | Known clean |
| 1 | AMSI_RESULT_NOT_DETECTED | Unknown but not malicious |
| 16384 (0x4000) | AMSI_RESULT_BLOCKED_BY_ADMIN_START | Policy block (range start) |
| 20479 (0x4FFF) | AMSI_RESULT_BLOCKED_BY_ADMIN_END | Policy block (range end) |
| 32768 (0x8000) | AMSI_RESULT_DETECTED | Provider verdict: malicious; `AmsiResultIsMalware` true |
Any return value at or above 32768 is malware; values 16384 to 20479 are administrative policy blocks (e.g. AppLocker / [WDAC](/blog/wdac--hvci-code-integrity-at-every-layer-in-windows/)), and values 0 and 1 are negative results [@amsi-result-enum]. The split between 16384 and 32768 lets a host distinguish "the AV refused this" from "policy refused this," which lets the host display different error messages.
### 5.2 The COM surface
For streamable content (Office macros, .NET assemblies loaded from memory, large IM payloads), the flat-C buffer-plus-length call is the wrong abstraction. AMSI's COM surface, `IAmsiStream` plus `IAntimalwareProvider`, lets the host hand a stream callback to the provider and lets the provider pull as much content as it wants [@amsi-iantimalware]. The reference implementation is in Microsoft's Windows-classic-samples AmsiProvider [@amsi-sample] repository.
Rule of thumb: COM/stream for streamable content, flat-C for one-shot buffers. Both end up at the same provider through the same in-process load.
### 5.3 The provider model
AMSI providers are in-process COM servers. Registration writes two registry trees [@amsi-devaudience]:
flowchart TD
A[Provider DLL: vendor implements IAntimalwareProvider] --> B[regsvr32 vendor.dll]
B --> C[HKLM Software Classes CLSID {CLSID} InprocServer32 = vendor.dll]
B --> D[HKLM Software Classes CLSID {CLSID} InprocServer32 ThreadingModel = Both]
B --> E[HKLM Software Microsoft AMSI Providers {CLSID} = present]
C --> F[amsi.dll AmsiInitialize]
D --> F
E --> F
F --> G[CoCreateInstance for each registered CLSID]
G --> H[Provider loaded in-process; called on every AmsiScanBuffer]
The first tree, `HKLM\SOFTWARE\Classes\CLSID\{CLSID}`, is standard COM. It names the provider DLL and the ThreadingModel (which must be `Both`; marshaling proxies would defeat the in-process performance assumption). The second tree, `HKLM\SOFTWARE\Microsoft\AMSI\Providers\{CLSID}`, is the AMSI-specific opt-in. `amsi.dll` enumerates the Providers subkey at `AmsiInitialize` time, calls `CoCreateInstance` for each one in-process, and then calls each provider on every subsequent `AmsiScanBuffer`.
Two security mitigations have hardened that load over time. Windows 10 1709 (October 17, 2017) tightened the loader rules: provider DLLs must `LoadLibrary` their dependencies with full paths, or the DLL hijack mitigations will refuse to satisfy unqualified loads [@amsi-devaudience]. Windows 10 1903 (May 21, 2019) added an optional Authenticode signing check: when `HKLM\SOFTWARE\Microsoft\AMSI\FeatureBits` is set to `0x2`, unsigned provider DLLs are refused [@amsi-iantimalware].
> **Note:** If you ship an AMSI provider, Authenticode-sign the provider DLL. Windows 10 1903 introduced an opt-in signing check at `HKLM\SOFTWARE\Microsoft\AMSI\FeatureBits = 0x2`. Several large enterprise customers set that bit, and unsigned provider DLLs will silently refuse to load on those machines [@amsi-iantimalware].
An in-process COM server (DLL) that implements `IAntimalwareProvider` and is registered under two registry trees: the standard COM CLSID tree under `HKLM\Software\Classes\CLSID\{CLSID}` and the AMSI-specific opt-in tree under `HKLM\Software\Microsoft\AMSI\Providers\{CLSID}`. `amsi.dll` loads every registered provider into the scanning host's process at `AmsiInitialize` time [@amsi-devaudience].
The `Both` threading model is mandatory for AMSI providers. AMSI calls into the provider on whatever thread the host happens to be running, and marshaling proxies would add cross-apartment round trips that destroy the in-process performance assumption [@amsi-devaudience].
### 5.4 The default provider: MpOav.dll
Microsoft Defender's AMSI provider is `MpOav.dll`. CLSID `{2781761E-28E0-4109-99FE-B9D127C57AFE}`. Path `%ProgramData%\Microsoft\Windows Defender\Platform\\MpOav.dll` [@redcanary-amsi]. It loads in-process to the scanning application: into `powershell.exe`, into `winword.exe`, into `wscript.exe`. It does not do the heavy lifting; it bridges out to `MsMpEng.exe` via local RPC for the signature engine, cloud reputation lookup, and the on-endpoint machine-learning model.
Microsoft Defender's AMSI provider DLL, located at `%ProgramData%\Microsoft\Windows Defender\Platform\\MpOav.dll`. Loaded in-process to the scanning application; bridges to `MsMpEng.exe` via local RPC for the heavy-lifting scan [@redcanary-amsi].
`MpOav.dll` lives in the scanning host's address space (`powershell.exe`, `winword.exe`, ...), not in `MsMpEng.exe`. Defender's [Protected Process Light](/blog/who-is-this-code----the-quiet-33-year-reinvention-of-app-ide/) hardening protects `MsMpEng.exe`'s process, but it does *not* protect the AMSI provider DLL that gets loaded into PowerShell. That asymmetry is the basis of every in-process bypass in §8 [@redcanary-amsi].
### 5.5 Sessions, correlation, content names
The `HAMSISESSION` handle returned by `AmsiOpenSession` is the correlation primitive. If a single PowerShell command produces three deobfuscation steps that yield three `AmsiScanBuffer` calls, sharing one session across all three lets the provider join them: "I just saw a base64 alphabet, then a key-rotation pattern, then `Invoke-Mimikatz`. Verdict: malicious. Reason: the three together are the obfuscation chain." The session-shared verdict is more informative than any single buffer would be in isolation [@amsi-opensession].
An opaque correlation handle returned by `AmsiOpenSession`. Multiple `AmsiScanBuffer` calls that share a `HAMSISESSION` value belong to one logical user command; the provider may re-join their partial deobfuscations into a single verdict [@amsi-opensession].
The `contentName` argument to `AmsiScanBuffer` is what the SOC analyst sees in `DeviceEvents.FileName` at hunt time. Hosts that pass a meaningful `contentName` (the script-block ID, the assembly's friendly name, the URL the macro came from) give the SOC the breadcrumb they need to triage; hosts that pass a random GUID or an empty string give the SOC a column of noise [@deviceevents-table].
> **Key idea:** AMSI's value comes from running inside the same process as the script engine, because that is the only place that ever holds the deobfuscated bytes. Every weakness AMSI has also comes from running inside the same process, because anyone with code execution there can mute it.
We now know what AMSI is. The next section walks every shipping integration in Windows 10 and 11, and reveals that AMSI was not, in 2015, where most Windows scripted-content malware actually ran.
## 6. The Call-Site Catalogue: Where AMSI Plugs Into Windows
AMSI shipped in `amsi.dll` in 2015, but `amsi.dll` exporting `AmsiScanBuffer` does not scan anything by itself. It scans whatever any host process bothers to hand it. The story of AMSI between 2015 and 2021 is one host integration at a time. Here is the order they shipped.
gantt
title AMSI integration by runtime
dateFormat YYYY-MM
axisFormat %Y
PowerShell 5.0 :ps, 2015-07, 3650d
Windows Script Host :wsh, 2015-07, 3650d
Office VBA :vba, 2018-09, 2555d
.NET Framework 4.8 :dn, 2019-04, 2555d
WMI scripting :wmi, 2019-05, 2555d
Excel 4.0 macros (XLM) :xlm, 2021-03, 1825d
Win11 in-memory scripts :w11, 2021-10, 1825d
### PowerShell 5.0 (July 29, 2015)
PowerShell is the reference integration. The PowerShell host calls `System.Management.Automation.AmsiUtils.ScanContent`, which (after a one-time check on the `amsiInitFailed` flag and a lazy `AmsiInitialize`) calls `AmsiNativeMethods.AmsiScanBuffer` on the deobfuscated script block [@psa-clr-hooking]. The integration matches Holmes's design intent verbatim: the buffer handed to AMSI is the buffer the executor is about to run.
### Windows Script Host (2015)
`wscript.exe` and `cscript.exe`, the hosts that ran ILOVEYOU in 2000, integrate AMSI in the same release vehicle as PowerShell 5.0 [@amsi-portal]. Every JScript or VBScript source goes through `AmsiScanBuffer` before WSH executes it, and runtime eval-style constructions (`new ActiveXObject('WScript.Shell').Run(...)` with a dynamically built command line) get scanned at the point where the runtime resolves them.
### Office VBA (September 12, 2018)
The Office VBA integration was the first non-script-engine AMSI host, and it used a new abstraction: the trigger-buffer architecture. The VBA runtime maintains a circular buffer of Win32, COM, and VBA API calls plus their arguments. When VBA observes a high-risk trigger -- `Shell` invocation, `CreateObject("WScript.Shell")`, `Application.Run` of a decoded string -- it halts the macro and flushes the circular buffer through `AmsiScanBuffer` [@amsi-howto].
The dispatch pattern used by Office VBA and Excel 4.0 AMSI integrations. The runtime maintains a circular buffer of API calls and arguments and flushes it through `AmsiScanBuffer` when a high-risk trigger (e.g. `CreateObject("WScript.Shell")`, `Shell()`, a file-write API) fires. The provider sees the trigger plus its prior-API context, not just one isolated call [@amsi-howto].
Office 365 client applications now integrate with Antimalware Scan Interface (AMSI), enabling antivirus and other security solutions to scan macros and other scripts at runtime to check for malicious behavior.
-- Microsoft Office 365 Threat Research, September 12, 2018
The Office team published the design in the September 12, 2018 announcement [@msec-vba-amsi-2018]. The architectural payoff: a provider sees not just one trigger call but the macro's prior-API context, which is what distinguishes `Application.Run("notepad.exe")` from `Application.Run()`.
### .NET Framework 4.8 (April 2019)
The next gap was in-memory .NET. `Assembly.Load(byte[])`, the load path Cobalt Strike's `execute-assembly` command and Sliver's SharpLoader use, did not produce a file on disk and did not generate any of the file-system events on-disk AV depended on. .NET Framework 4.8 closed it: "In previous versions of .NET Framework, Windows Defender or third-party antimalware software would automatically scan all assemblies loaded from disk for malware. However, assemblies loaded from elsewhere, such as by using `Assembly.Load(byte[])`, would not be scanned ... .NET Framework 4.8 on Windows 10 triggers scans for those assemblies by Windows Defender and many other antimalware solutions that implement the Antimalware Scan Interface" [@dotnet-48].
### WMI scripting (Windows 10 1903, May 2019)
WMI is, in the abstract, an RPC protocol and a query language, but it is also a code-execution surface (`__EventConsumer` persistence; `Win32_Process.Create` lateral movement). The 1903 [@wiki-win10-versions] AMSI integration scans WMI scripting paths [@amsi-on-mdav], closing the persistence pivot that had been a favorite of post-exploitation toolkits since 2012.
### Excel 4.0 macros (March 3, 2021)
XLM macros, the language that Microsoft Excel introduced in 1992 (one year before VBA, which arrived in 1993), is the textbook example of a runtime that never died. Attackers rediscovered XLM in 2019 and 2020: Trickbot, Zloader, and Ursnif campaigns all used XLM4 macros to bypass VBA-focused defenses. Microsoft retrofitted the trigger-buffer architecture from VBA to XLM and shipped on March 3, 2021 [@msec-xlm-amsi-2021]. The Microsoft post enumerates the full AMSI host list as of 2021: "Office VBA macros; JScript; VBScript; PowerShell; WMI; Dynamically loaded .NET assemblies; MSHTA/Jscript9."
### Windows 11 in-memory script scanning (2021+)
AMSI coverage has continued to expand in current Defender releases on Windows 10 and Windows 11 beyond the script-engine hosts above; the precise call-site list is documented per-Defender-release rather than in a single canonical Microsoft Learn page. The current Defender AMSI host list reads: "PowerShell; JScript; VBScript; Windows Script Host (wscript.exe and cscript.exe); .NET Framework 4.8 or newer (scanning of all assemblies); Windows Management Instrumentation (WMI)" [@amsi-on-mdav]. Living-Off-the-Land Binary (LOLBin) paths that bypassed the classic script-engine entry points have become a continuing focus of Defender's per-release AMSI extensions.
Seven runtimes, one API. The contract is that each one phones home before it runs your code. The next section is how the seven streams converge into one analyst's pane of glass.
## 7. AMSI Meets ETW: The Correlation Story
The architectural dichotomy fits in one sentence: AMSI is synchronous and can block; [Event Tracing for Windows (ETW)](/blog/etw-how-windows-2000s-performance-hack-became-the-edr-substr/) is asynchronous and observation-only. They share the same data, the same provider, and the same calling convention, but they answer different questions. AMSI is for *decisions*. ETW is for *correlation* and *survives in-process bypass*.
flowchart LR
A[powershell.exe / winword.exe scanning host] --> B[amsi.dll AmsiScanBuffer prologue]
B --> C[ETW provider 2A576B87-09A7-520E-C21A-4942F0271D67 emit event]
B --> D[MpOav.dll IAntimalwareProvider Scan]
D --> E[MsMpEng.exe verdict]
E --> F[result returned synchronously to host]
F --> G[host refuses or allows execution]
C --> H[Defender ATP DeviceEvents AmsiScriptDetection]
C --> I[Third-party EDR via Antimalware-PPL]
C --> J[Sysmon SilkETW Sealighter on-host]
The ETW provider name is `Microsoft-Antimalware-Scan-Interface` and its GUID is `{2A576B87-09A7-520E-C21A-4942F0271D67}` [@etw-manifest]. It emits a structured event for every `AmsiScanBuffer` call. The event template has ten fields: `session`, `scanStatus`, `scanResult`, `appname`, `contentname`, `contentsize`, `originalsize`, `content`, `hash`, `contentFiltered`. The `content` field is the deobfuscated buffer that just got scanned. That is the basis of every downstream telemetry product.
The Event Tracing for Windows provider with GUID `{2A576B87-09A7-520E-C21A-4942F0271D67}` that emits a structured event for every `AmsiScanBuffer` call. The event template carries the deobfuscated content, the AMSI result, the host's `appName`, and the host's `contentName`. Consumed by Defender, by third-party EDRs once they have Antimalware-PPL onboarded, and by community tools like SilkETW and Sealighter on individual hosts [@etw-manifest].
Defender's `MsMpEng.exe` consumes the provider; third-party EDRs consume it once they have Antimalware-PPL onboarded; on individual hosts, community tools like SilkETW and Sealighter against the GUID let an analyst capture every scan on an air-gapped machine without a cloud connection.
In Microsoft Defender for Endpoint, the same event surfaces in the `DeviceEvents` table with `ActionType == "AmsiScriptDetection"`, and the `AmsiData` column carries the deobfuscated content, `AmsiPatchedTextInResult` carries any provider-side rewriting, and `AmsiProcessName` carries the host's `appName` [@deviceevents-table]. The hunting community has converged on a few canonical patterns. Here is one of them: join the AMSI detection back to its parent process command line to recover the full attack chain.
DeviceEvents
| where ActionType == "AmsiScriptDetection"
| extend Description = tostring(parse_json(AdditionalFields).Description)
| project Timestamp, DeviceName, DeviceId, InitiatingProcessCommandLine,
InitiatingProcessParentFileName, Description, ReportId
| join kind=leftouter (
DeviceProcessEvents
| project ProcessCommandLine, InitiatingProcessCommandLine,
InitiatingProcessFolderPath, DeviceId, ReportId
) on DeviceId
| where Timestamp > ago(7d)
| sort by Timestamp desc
The query is adapted from Bert-JanP's `AMSIScriptDetections.md` hunting pack [@bertjan-amsi-queries] and maps each detection to MITRE T1059.001 -- Command and Scripting Interpreter: PowerShell [@attack-t1059-001]. The shape of the join is the load-bearing part: AMSI gives you the *what* (the deobfuscated buffer), and `DeviceProcessEvents` gives you the *how* (the parent process and its command line). Together they are the full attack chain.
The ETW provider runs from inside `AmsiScanBuffer`'s prologue, not at the (possibly bypass-clobbered) return. This is why a Cornelis de Plaa / Outflank 2020 hardware-breakpoint bypass that perfectly hides the scan *result* still leaks ETW telemetry: the prologue emit happens before the breakpoint fires. The provider sees the scan happened; only the verdict is muted [@ethicalchaos].
AMSI hands out the deobfuscated buffer; ETW makes sure someone saw it happen. The attacker's job for the next seven years was to make neither happen. Here is how that went.
## 8. The Bypass Arms Race: Six Eras in Nearly Seven Years
In seven years, attackers have generated six distinct bypass eras. Each era was the *necessary consequence* of AMSI's same-process trust model. Each era's defeat by Defender required a new architectural insight, not a new signature. Here is the bird's-eye view.
| Era | First public | Attacker / source | Technique | Defender response |
|----:|--------------|-------------------|-----------|-------------------|
| 1 | May 2016 | Matt Graeber (tweet) | `AmsiUtils.amsiInitFailed = true` via reflection | String signature on field-and-class proximity |
| 2 | February 2018 | Avi Gimpel and Zeev Ben Porat (CyberArk Labs) | In-memory patch of `AmsiScanString`; May 2018 redux patches `AmsiScanBuffer` (`xor edi, edi`) | Windows 10 1709 swaps to `AmsiScanBuffer`; byte-pattern signature on common patches |
| 3 | 2018-2019 | Various practitioners | Obfuscated patches: hashed `GetProcAddress`, indirect writes, randomized bytes | Behavior signature: detect any write into `amsi.dll` code section |
| 4 | 2019 | Various practitioners | Register a malicious CLSID under `HKLM\...\AMSI\Providers` | Windows 10 1709 DLL-hijack mitigation; 1903 Authenticode signing |
| 5 | January 29, 2020 | Cornelis de Plaa (Outflank) | DR0 hardware breakpoint plus Vectored Exception Handler; no memory patch | `Microsoft-Windows-Kernel-Audit-API-Calls` ETW `NtSetContextThread` event (admin-side, no PPL gate); `Microsoft-Windows-Threat-Intelligence` on the remote-thread subset |
| 6 | December 2022 | Practical Security Analytics | Patch CLR-side `Assembly.Load(byte[])` AMSI callout in `clr.dll`; bypass at managed boundary | Signature on the CLR-side patch; `Microsoft-Windows-DotNETRuntime` ETW correlation |
### Era 1: amsiInitFailed (May 2016)
The first public AMSI bypass is one line. Matt Graeber posted it as a tweet in May 2016; Sophos's June 2021 retrospective preserves the date and the tweet body for readers who cannot reach X: "In May of 2016, PowerShell hacker Matt Graeber published a one-line AMSI evasion in a tweet" [@sophos-bypasses]. MDSec's June 2018 walk-through reproduces the technique and its decompiled target:
```powershell
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils'). `
GetField('amsiInitFailed','NonPublic,Static'). `
SetValue($null, $true)
```
Why does that work? Because the host's `AmsiUtils.ScanContent` checks a private static boolean before doing anything. If the host's own managed state says "AMSI failed to initialize," the host short-circuits every subsequent scan to "clean." MDSec's analysis quotes the field declaration verbatim: "What we are interested in is the variable `amsiInitFailed`, which is defined as: `private static bool amsiInitFailed = false`" [@mdsec-evasion].
The structural lesson is that AMSI's trust model includes the script engine's own managed state. PowerShell trusts itself. If you can flip a field in PowerShell's own memory, you have flipped PowerShell's trust in AMSI. The short-circuit logic looks like this:
{`// Decompiled sketch of System.Management.Automation.AmsiUtils.ScanContent.
// Source: Practical Security Analytics decompile of the PowerShell host.
function ScanContent(content, scriptName) {
// amsiSession is AmsiUtils.amsiSession, a static field; not a parameter.
if (amsiInitFailed) {
// The bypass: flip this flag once via reflection, every subsequent
// ScanContent returns AMSI_RESULT_NOT_DETECTED without ever calling
// amsi.dll. amsiInitFailed is a PRIVATE STATIC field of AmsiUtils;
// reflection makes it writable from any AppDomain.
return AMSI_RESULT_NOT_DETECTED;
}
if (!amsiInitialized) {
initialize(); // lazy AmsiInitialize + AmsiOpenSession
}
return AmsiNativeMethods.AmsiScanBuffer(
amsiContext, content, content.length, scriptName, amsiSession);
}`}
Defender's response was a string signature on `amsiInitFailed` plus class-name proximity. Sophos reports that "the `amsiInitFailed` bypass still accounts for about 1 percent of detections, based on a 90-day chunk of telemetry data from February to May of 2021" [@sophos-bypasses]. The bypass is detected almost everywhere it appears, yet it still appears, because some commodity actor still ships the literal string verbatim.
### Era 2: In-memory `AmsiScanString` / `AmsiScanBuffer` patch (February 2018)
Avi Gimpel and Zeev Ben Porat at CyberArk Labs published the first canonical in-memory native-code patch in February 2018 [@cyberark-patching]. The technique: `LoadLibrary("amsi.dll")`, `GetProcAddress("AmsiScanString")`, `VirtualProtect` the page to read-write-execute, overwrite the function prologue with `mov eax, E_INVALIDARG; ret`, restore the protection. Every subsequent `AmsiScanString` returns `E_INVALIDARG` without ever talking to the provider.
> **Note:** The first canonical in-memory AMSI patch attack was published by Avi Gimpel and Zeev Ben Porat at CyberArk Labs in February 2018 [@cyberark-patching]. It is sometimes misattributed to Tal Liberman at Black Hat USA 2016; no Liberman BH USA 2016 AMSI talk was independently locatable, and the canonical CyberArk article carries the Gimpel and Ben Porat byline.
Microsoft's 1709 response was to change which function PowerShell called. Instead of `AmsiScanString`, PowerShell 5.0 in 1709 calls `AmsiScanBuffer`, breaking the Gimpel and Ben Porat patch outright [@cyberark-redux]. Gimpel and Ben Porat published the redux in May 2018: target the new function with a smaller, semantically equivalent patch, `xor edi, edi`. The instruction zeros the buffer-length register, which makes `AmsiScanBuffer` think the host handed it an empty buffer and return `AMSI_RESULT_CLEAN` [@cyberark-redux].
The on-record Microsoft response to the CyberArk disclosures is the single most quoted sentence in the AMSI corpus. We hold its full force until §9, but here is the verbatim text Gimpel and Ben Porat reproduced under the heading "Microsoft Security Response Center (MSRC) Response" in their May 2018 redux:
> "The AMSI was not designed to prevent such attacks. If an attacker can execute code in a process using AMSI to scan for malware, there are numerous ways to alter the behavior of the AMSI scan." -- Microsoft Security Response Center, quoted in CyberArk Labs (May 2018 redux) [@cyberark-redux].
### Era 3: Obfuscated patches (2018-2019)
Defender's first response was a byte-pattern signature on the common patches. Practitioners replied by randomizing the patch bytes, resolving `AmsiScanBuffer` by hash rather than by name, writing the patch from indirect memory locations to defeat string-based hunts, and so on. The defender response, in turn, was to stop chasing the byte pattern and start watching for *the write itself*: any RWX write into `amsi.dll`'s code section, regardless of byte pattern, is suspicious. Trend Micro's bypass-techniques retrospective lists the era's techniques side by side: "Obfuscation and/or encryption; PowerShell downgrade; Hooks and unhooks; Memory patching; Forcing an error; Registry modifications; DLL hijacking; Reflection" [@trendmicro-bypass].
### Era 4: Provider COM-hijack (2019)
A different attack class: register a malicious CLSID under `HKLM\SOFTWARE\Microsoft\AMSI\Providers`, write your own DLL into the standard COM tree, and `amsi.dll` will dutifully load it in-process at `AmsiInitialize` time [@redcanary-amsi]. Your provider then returns `AMSI_RESULT_CLEAN` for everything, regardless of what the actual antivirus would have said. Admin is required to write the keys, but admin is required for a lot of post-exploitation work, and AMSI is in the trust path for a lot of post-exploitation script.
The defender response was Windows 10 1709's DLL-hijack mitigation (provider DLLs that did not load their dependencies with full paths refused to load) and Windows 10 1903's optional Authenticode signing requirement. With `HKLM\SOFTWARE\Microsoft\AMSI\FeatureBits = 0x2`, an unsigned provider refuses to load entirely [@amsi-iantimalware].
### Era 5: Hardware-breakpoint VEH bypass (January 29, 2020)
Cornelis de Plaa, posting as Cneelis at Outflank, published the patchless AMSI bypass on January 29, 2020. The technique elegantly sidesteps every prior defender response by never patching `amsi.dll` at all. The Outflank post itself is no longer reachable from non-browser clients (the access caveat and accessible corroborators appear in the Sidenote below); the technique mechanics, attribution, and date are preserved verbatim by EthicalChaos (April 2022) [@ethicalchaos], CrowdStrike (2024) [@crowdstrike-veh], and Trend Micro (December 2022) [@trendmicro-bypass]. Steps:
1. `AddVectoredExceptionHandler(1, exceptionHandler)` -- register a vectored exception handler.
2. Set `DR0` to the address of `AmsiScanBuffer` via `SetThreadContext`. The `DR0`-`DR3` registers are CPU hardware breakpoints; the processor raises `EXCEPTION_SINGLE_STEP` the moment instruction pointer hits the breakpoint address.
3. When the breakpoint fires, the exception handler executes. It sets `RAX = AMSI_RESULT_CLEAN`, advances `RIP` past the function body, and returns `EXCEPTION_CONTINUE_EXECUTION`.
There is zero static artifact in `amsi.dll`. The code section is untouched. Every signature that depends on a write into `amsi.dll` is dead. EthicalChaos reproduces the technique mechanics verbatim two years later: "the idea will be to register a vectored exception handler then set a breakpoint on a function within `amsi.dll` ... `AddVectoredExceptionHandler(1, exceptionHandler) ... SetThreadContext((HANDLE)-2, &threadCtx)`" [@ethicalchaos].
The original Outflank 2020-01-29 blog post (outflank.nl, "Bypassing AMSI by manipulating the AMSI scan results") is no longer reachable from non-browser clients and has no Wayback snapshot; this article therefore cites only accessible corroborators rather than the link-rotten primary. The technique mechanics in this section are reproduced verbatim by EthicalChaos (April 2022) [@ethicalchaos], CrowdStrike (2024) [@crowdstrike-veh], and Trend Micro (December 2022) [@trendmicro-bypass].
The Defender response is the one this article keeps circling back to: kernel-side ETW. The hardware-breakpoint bypass calls `SetThreadContext` to write to `DR0`. The `Microsoft-Windows-Threat-Intelligence` (EtwTi) provider's `NtSetContextThread` event covers remote-thread context writes, but in-thread context writes (which is what the patchless bypass performs) are more reliably caught by `Microsoft-Windows-Kernel-Audit-API-Calls`, the provider CrowdStrike documents as its primary detection path. CrowdStrike's writeup gives the framing: "the `DR0`-`DR3` debug registers contain the addresses of hardware (HW) breakpoints ... patchless AMSI attack called VEH-squared ... mapped in the technique Impair Defenses: Disable or Modify Tools by the MITRE ATT&CK framework (T1562.001)" [@crowdstrike-veh] -- and MITRE's T1562.001 redirect [@attack-t1562-001] now sends readers to T1685 [@attack-t1685], the unified "Impair Defenses: Disable or Modify Tools" technique. The catch: EtwTi is gated on Antimalware-PPL consumers. Defender's `MsMpEng.exe` and a small set of onboarded third-party EDRs see it. Non-PPL products do not.
Antimalware Protected Process Light. A Windows signer level (introduced in Windows 8.1, hardened in Windows 10) that lets Defender's `MsMpEng.exe` and onboarded third-party EDRs consume gated ETW providers like `Microsoft-Windows-Threat-Intelligence` (EtwTi). Without PPL, an EDR cannot see EtwTi events, which means it cannot detect patchless hardware-breakpoint AMSI bypasses through ETW.
### Era 6: CLR-DLL load-time patch (December 2022)
If patching `amsi.dll` directly is signature-rich, patch something further up the call chain. Practical Security Analytics published the technique in December 2022 [@psa-clr-hooking]: patch the .NET CLR's own AMSI callout (the managed-side wrapper inside `clr.dll` that calls `AmsiScanBuffer` on `Assembly.Load(byte[])`) rather than `amsi.dll` itself. The technique "has an advantage over other API Call Hooking techniques that target native functions such as `AMSI.dll::AmsiScanBuffer` in that this method is more difficult to prevent with EDR or Application Protection rules" -- the patched bytes live in `clr.dll`, not `amsi.dll`, and many defender rules only watch the latter.
The defender response was twofold: signature on the CLR-side patch bytes, and correlation against the `Microsoft-Windows-DotNETRuntime` ETW provider. The DotNETRuntime provider emits an `AssemblyLoadFinished` event for every `Assembly.Load` call. If the CLR-side AMSI callout has been muted, the load event fires anyway, and Defender now has a `DotNETRuntime` event with no corresponding `AmsiScanBuffer` event in the prior microseconds. That gap is the signal.
### Era 7: The behavioral era (2023+)
By 2023, the bypass families had grown beyond enumeration. Microsoft's response was structural: stop trying to enumerate bypass techniques, and start scoring the *gap*. Defender's machine-learning models, described in the August 2020 disclosure on pairs-of-classifiers [@msec-amsi-ml-2020], feed not just on the content of AMSI events but on the *cadence* of AMSI events per process. A `powershell.exe` that has been alive for 90 seconds, run 14 commands, and emitted zero `AmsiScriptDetection` ETW events when the cohort baseline expects six is suspicious regardless of the technical mechanism behind the silence. The structural insight: the win condition is no longer "detect the bypass" but "notice that scanning has stopped."
> **Note:** AMSI's *capability* (post-deobfuscation, synchronous, blocking) and its *failure mode* (same-process bypass) come from the same architectural fact. Running in the script engine's process is the only way to see the post-deobfuscation bytes; it is also the only way to be muted by anything else running in that process. Defender's 2023+ response, scoring the gap rather than the bypass, is the only structurally durable answer because it works against any technique.
The bypass arms race is a symptom, not the disease. The disease is what Microsoft has been saying out loud since 2018: AMSI is not, and was never designed to be, a security boundary.
## 9. What AMSI Is Not: The MSRC Boundary Position
When Avi Gimpel and Zeev Ben Porat disclosed their in-memory AMSI patches to the Microsoft Security Response Center across early 2018, the response they received and reproduced verbatim under the "MSRC Response" heading of their May 2018 redux is the most important single sentence in the AMSI corpus:
The AMSI was not designed to prevent such attacks. If an attacker can execute code in a process using AMSI to scan for malware, there are numerous ways to alter the behavior of the AMSI scan.
-- Microsoft Security Response Center, quoted in CyberArk Labs (May 2018 redux)
That sentence is not a Microsoft retreat under pressure. It is the published structural position. The Windows Security Servicing Criteria framework, which MSRC uses to triage every bug report against Windows, asks one question to determine whether a finding is serviced as a security vulnerability: "Does the vulnerability violate the goal or intent of a security boundary or a security feature? ... If the answer to either question is no, then by default the vulnerability will be considered for the next version or release of Windows but will not be addressed through a security update or guidance" [@msrc-criteria]. AMSI is published as neither a boundary nor a feature in that taxonomy. Bypasses of AMSI are not security bugs in MSRC's published framework. They get fixed when Microsoft can fix them. They do not get CVEs.
> **Key idea:** AMSI is not a security boundary. It is a high-coverage telemetry seam that closes one specific evasion strategy -- pre-execution obfuscation -- and concedes everything else to the layers above and below it.
So why is AMSI valuable anyway?
flowchart TD
A[AMSI same-process trust model] --> B{Attacker has code execution in the host?}
B -- No, the attacker is delivering an unprivileged script --> C[AMSI scans the deobfuscated buffer provider returns DETECTED host refuses to run]
B -- Yes, the attacker has unrestricted code execution --> D[AMSI scan is mutable in-process]
D --> E[ETW provider 2A576B87 emits from inside the prologue]
E --> F[Defender / EDR sees the scan happened; bypass leaks telemetry]
D --> G[Defender's behavioral cohort scoring]
G --> H[Gap detection: process emitted 0 AmsiData events; cohort expects ~6]
C --> I[AMSI as synchronous gate: WIN]
F --> J[AMSI bypass leaves ETW fingerprint: WIN]
H --> K[Behavioral gap detection: WIN]
There are two trust assumptions, and both hold for most real-world attacks. The first is that the attacker is *unprivileged*: they are delivering an obfuscated script payload inside a host process they did not control before delivery. The phishing-document case in §1 is exactly this. AMSI's synchronous gate beats them. The second is that Defender's *ETW telemetry* of AMSI scans, including the *gaps* in those scans, survives the bypass. Even when an in-process bypass mutes the synchronous return, the ETW provider's prologue emit still fires, and behavioral cohort scoring still notices the missing events. AMSI bypasses leak. Defender's win condition is that the leak is enough.
Why can AMSI not be moved into a [VBS Trustlet](/blog/vbs-trustlets-what-actually-runs-in-the-secure-kernel/) (the isolated, kernel-attested user-mode environment that Hyper-V's Virtual Secure Mode hosts)? Latency. A Trustlet call is a VTL switch: the CPU takes a VMEXIT into the hypervisor, saves and restores the VMCS, and returns into VTL1; the Hyper-V Top-Level Functional Specification documents the mechanism as a hypercall (Microsoft TLFS: Virtual Secure Mode [@tlfs-vsm]). AMSI is on the hot path of every script statement: PowerShell calls `AmsiScanBuffer` per command, Office VBA calls it per trigger, .NET calls it per `Assembly.Load`. Multiplying every per-statement scan by a VTL round trip is unacceptable. The same-process design is a deliberate latency-versus-isolation trade-off, made in 2015 and confirmed every year since.
Why can AMSI not be moved out-of-process to a broker? Same answer: the broker's RPC round trip puts process context switches and ALPC marshalling on the same per-statement hot path. And a broker introduces a different problem: an in-process attacker could prevent the host from speaking to the broker (close the RPC handle, replace the proxy, set a hardware breakpoint on the marshalling thunk). The attack surface is not reduced; it is moved.
Now we know what AMSI is, what it is not, and how attackers have spent seven years stress-testing the difference. What is left unsolved?
## 10. Open Problems: The 2026 Frontier
Fred Cohen proved in 1984 that general virus detection is undecidable: "In general, detection of a virus is shown to be undecidable both by a priori and runtime analysis, and without detection, cure is likely to be difficult or impossible" [@cohen-1984]. AMSI does not try to solve Cohen's problem. AMSI solves an adjacent problem -- given a deobfuscated buffer, does it match patterns a provider has seen? -- which is finite-state and tractable. The first is impossible. The second is the only thing that has ever worked.
> **Key idea:** AMSI does not try to solve the undecidable problem of "is this program malicious?". It solves a tractable adjacent problem: "does this deobfuscated buffer match patterns we have seen?". The first is theoretically impossible (Cohen 1984). The second is the only thing that has ever scaled.
The empirical upper bound on the second problem is now known. Danny Hendler, Shay Kels, and Amir Rubin's 2020 ACM AsiaCCS paper, *Detecting Malicious PowerShell Commands using Deep Neural Networks* [@hendler-msr], reports on AMSI-collected PowerShell: "Our best-performing model uses an architecture that enables the processing of textual signals from both the character and token levels and obtains a true-positive rate of nearly 90% while maintaining a low false-positive rate of less than 0.1%." The arXiv preprint carries the same headline figures [@hendler-arxiv]. About 90 percent true positive at under 0.1 percent false positive is the practical ceiling on AMSI-side classification. It is much better than every pre-AMSI defender alone, and it is still 10 percent away from perfect. Cohen's lower bound on the *general* problem means perfect is not on offer; the question is what fraction of the residual 10 percent the next ten years close.
flowchart TD
A[AMSI in 2026: open problems]
A --> B[Patchless bypass detection without PPL]
A --> C[Non-Microsoft script runtimes Python Node Ruby]
A --> D[AMSI for AI-runtime LLM-generated code]
A --> E[Cross-runtime correlation single chain]
A --> F[IAmsiStream adoption beyond scripts]
A --> G[AMSI on Linux macOS especially dotnet]
B -.user-mode-only detection requires polling.-> B1[Open: no general solution]
C -.PEP-578 audit hooks architecturally similar.-> C1[Open: no production bridge]
D -.does content-scan even apply to LLM output.-> D1[Open: design problem]
E -.no correlation_id joins macro-PowerShell-dotnet.-> E1[Open: per-host-app scope]
F -.designed for adoption but adoption thin.-> F1[Open: market problem]
G -.no shared script-engine host model.-> G1[Open: platform problem]
**Open problem 1: patchless hardware-breakpoint bypass on unprivileged user-mode EDR.** The Outflank 2020 technique still works against EDR products that lack any kernel-side ETW consumer for thread-context writes [@crowdstrike-veh]. CrowdStrike's recommended detector, `Microsoft-Windows-Kernel-Audit-API-Calls`, is available to admin-side consumers without an Antimalware-PPL gate; `Microsoft-Windows-Threat-Intelligence` is the stricter alternative for the remote-thread-context subset. The conjecture, stated bluntly: no reliable fully-unprivileged user-mode-only detection of the patchless bypass exists. Any such detection would have to either poll the debug registers (which defeats the bypass's whole point) or hook the syscalls the bypass uses (which any in-process bypass can in turn defeat). The path forward is to make kernel-ETW consumption table stakes for any serious EDR product on Windows; the path is administrative, not architectural.
**Open problem 2: non-Microsoft script runtimes.** Python, Node.js, Ruby, Lua, and the JavaScript hosts embedded in WebView2 are all script-execution surfaces that AMSI does not see. Python's PEP-578 audit hooks are architecturally similar to AMSI: a callback the runtime invokes at security-relevant events. No production AMSI bridge for Python ships from Microsoft or from any major Python distributor. The architectural reason is that AMSI's contract assumes a host that has a clear "about to execute deobfuscated content" moment; not every runtime presents that moment to the OS in a way an external provider can intercept.
**Open problem 3: AMSI for AI-runtime / LLM-generated code.** When Copilot or AutoGen agents generate code that an automated runner executes, is `AmsiScanBuffer` the right seam for inspection? The architectural question is harder than the engineering one: do content-scan signatures even apply to LLM-generated code at all? The empirical answer is unknown, and the public AMSI corpus (§8 above, plus the Hendler/Kels/Rubin character- and token-level model from §10) is built on the obfuscation artefacts of human-authored attacks; whether the same signal shape persists when the author is a language model is itself the open research question. A different seam, closer to "policy at agent-execution time," may be the right model.
**Open problem 4: cross-runtime correlation.** Today, each AMSI integration sees its slice of the attack. Office VBA sees the trigger buffer. PowerShell sees the deobfuscated command line. .NET sees the in-memory assembly. The provider can correlate calls within one `HAMSISESSION`, but no single `correlation_id` joins Office VBA's session to the PowerShell session it spawns to the .NET assembly that PowerShell loads. A SOC analyst piecing together the chain joins on parent process ID and timestamp; the join is fragile.
**Open problem 5: `IAmsiStream` adoption beyond script engines.** `IAmsiStream` was designed for non-script content -- IM messages, downloaded plugins, BLOB attachments -- but the demand from non-script applications never materialized. The interface is ready; the integrations are not. This one is a market problem, not an architectural one, and there is no obvious actor whose interest is to fix it.
**Open problem 6: AMSI on Linux and macOS.** PowerShell 7 runs on Linux. .NET runs on Linux. The same `Assembly.Load(byte[])` attack surface that drove .NET 4.8's AMSI integration exists in CoreCLR, unwatched. No equivalent of AMSI ships outside Windows. Partly that is platform: every Python and Node install on Linux is essentially its own host with its own life cycle, and there is no shared script-engine model the way `amsi.dll` provides on Windows. Partly it is economics: the large-customer demand that drove every Windows AMSI integration since 2015 has not assembled on the other side. The PowerShell team's path forward is uncertain.
If you build, hunt, attack, or defend on Windows, AMSI is not optional reading. The next section is the Monday-morning answer for each of those four roles.
## 11. Practical Guide: For Four Roles on Monday Morning
The rest of this section is the action-oriented closing. One numbered subsection per audience. Skip to the one that applies to you.
### 11.1 For an application developer
You ship a Windows application that hosts a scripting engine, an automation surface, or a plug-in loader. Here is the minimum-viable AMSI integration. The call lifecycle is exactly five functions plus one cleanup pair.
# Pseudocode against the Win32 flat-C AMSI surface in amsi.dll.
# A real implementation would use C++ or Rust with the actual amsi.h
# types. The lifecycle and error handling are the load-bearing parts.
amsi = ctypes.WinDLL("amsi.dll")
# 1. Once at startup. appName is what shows up in DeviceEvents.AmsiProcessName.
ctx = HAMSICONTEXT()
hr = amsi.AmsiInitialize("MyApp_v3.2", byref(ctx))
if hr != S_OK:
raise OSError(hr)
try:
# 2. Once per logical user command (NOT once per buffer).
session = HAMSISESSION()
hr = amsi.AmsiOpenSession(ctx, byref(session))
if hr != S_OK:
raise OSError(hr)
try:
# 3. Once per buffer. The contentName is what the SOC analyst sees.
result = AMSI_RESULT()
hr = amsi.AmsiScanBuffer(
ctx, buffer, len(buffer), "user-script.ps1", session, byref(result))
if hr != S_OK:
raise OSError(hr)
# 4. Interpret the verdict.
if amsi.AmsiResultIsMalware(result):
raise SecurityException("AMSI flagged the content as malicious")
finally:
# 5. Always close the session.
amsi.AmsiCloseSession(ctx, session)
finally:
# 6. Always uninitialize at shutdown.
amsi.AmsiUninitialize(ctx)
The four common bugs to avoid: forgetting `AmsiUninitialize` (the handle leaks until the process dies); sharing one `HAMSISESSION` across threads (the correlation breaks and the provider sees one giant interleaved logical command); ignoring `AMSI_RESULT_DETECTED` (defeats the entire point of integrating); and passing a meaningless `contentName` (every SOC analyst hunting your application will quietly curse you).
### 11.2 For an AV or EDR vendor implementing a provider
If you are an AV vendor, the Microsoft Windows-classic-samples AmsiProvider [@amsi-sample] is your starting point. The skeleton: `DllRegisterServer` writes the two registry trees (the CLSID tree under `HKLM\SOFTWARE\Classes\CLSID` and the AMSI opt-in tree under `HKLM\SOFTWARE\Microsoft\AMSI\Providers`); the IClassFactory boilerplate creates an instance; `IAntimalwareProvider::Scan` consumes the `IAmsiStream` and bridges it to your scan engine [@amsi-devaudience].
Three operational gotchas that have bitten every vendor at least once:
1. **Load dependencies with full paths.** Windows 10 1709's DLL-hijack mitigation refuses unqualified `LoadLibrary` calls from AMSI provider DLLs. Use full paths for every secondary DLL your provider loads [@amsi-devaudience].
2. **Authenticode-sign your provider.** Windows 10 1903's optional signing check at `HKLM\SOFTWARE\Microsoft\AMSI\FeatureBits = 0x2` refuses unsigned providers. Many enterprise customers set that bit by policy.
3. **ThreadingModel must be `Both`.** Marshaling proxies break the in-process performance assumption.
### 11.3 For a detection engineer
The two-pronged hunt: query the cloud telemetry (`DeviceEvents` in Defender XDR) for the wide net, and run an on-host ETW consumer (SilkETW or Sealighter against GUID `{2A576B87-09A7-520E-C21A-4942F0271D67}`) for the air-gapped and high-value hosts. The KQL pattern in §7 is the cloud-side join; the on-host consumer is documented in the `AMSIScriptDetections.md` hunting pack [@bertjan-amsi-queries].
Bonus rule: deploy a gap-detection alert. "Any `powershell.exe` process alive longer than 60 seconds with more than five `ProcessCommandLine` entries and zero `AmsiScriptDetection` events" is a high-signal pattern across every bypass family in §8, including the patchless ones. It does not detect the *bypass*; it detects the *result* of the bypass, which is silence where there should be sound.
### 11.4 For a red-team operator
The viability of each bypass family in 2026 against fully-patched Windows 11 23H2 with Defender for Endpoint and a PPL-onboarded EDR is:
- `AmsiUtils.amsiInitFailed`: dead. String signature still in place; Sophos reports about 1 percent detection share in 2021, which means roughly 1 percent of commodity actors still ship the literal bypass and get caught [@sophos-bypasses].
- In-process `AmsiScanBuffer` patch: dead. Byte-pattern signature plus behavior signature on writes to `amsi.dll`.
- Provider COM-hijack: dead. 1903 signing requirement plus 1709 DLL-hijack mitigation.
- Hardware-breakpoint VEH (Outflank 2020 family): generates `Microsoft-Windows-Kernel-Audit-API-Calls` `NtSetContextThread` events to any admin-side ETW consumer; the stricter `Microsoft-Windows-Threat-Intelligence` event fires only on remote-thread writes, so the in-thread variant is invisible to EtwTi but visible without PPL [@crowdstrike-veh].
- CLR-DLL patch (Practical Security Analytics, 2021): niche; the `Microsoft-Windows-DotNETRuntime` ETW correlation closes most variants.
> **Note:** Even when a bypass succeeds against the synchronous `AmsiScanBuffer` return, the ETW provider still emits from inside the prologue. If your goal is silence rather than evasion, you need a bypass that prevents `amsi.dll` from loading at all, and most modern hosts will not let you. The trade between "I bypassed AMSI" and "I left no telemetry" is rarely the same trade.
Even surviving 2026-viable bypasses emit telemetry that compounds: a provider COM-hijack attempt generates an unsigned-load failure in the Windows event log; a hardware-breakpoint VEH bypass generates an `NtSetContextThread` event in `Microsoft-Windows-Kernel-Audit-API-Calls` (and in `Microsoft-Windows-Threat-Intelligence` on the remote-thread subset); a CLR-DLL patch generates a clr.dll-write event in the kernel-mode memory-protection telemetry. The "I bypassed AMSI" cost is one event; the "I bypassed AMSI invisibly" cost is many. On a high-assurance target where the SOC is hunting on the gap and the EDR has PPL onboarded, the risk-adjusted return on most known bypasses is negative.
AMSI is, in the end, a covenant. The script engine promises to phone home before it runs your code. The defender promises to listen. Everyone -- attacker, defender, developer, AV vendor -- has spent ten years arguing about the terms.
## 12. FAQ
No. Per Microsoft's published Windows Security Servicing Criteria [@msrc-criteria], AMSI is not classified as a security boundary, which means AMSI-bypass bugs are not serviced as security vulnerabilities. The Microsoft Security Response Center's response to CyberArk Labs (reproduced in the May 2018 redux disclosure [@cyberark-redux]) is verbatim: "the AMSI was not designed to prevent such attacks." See §9 for the architectural reasoning.
No. `MpOav.dll` loads *into the calling process* (`powershell.exe`, `winword.exe`, `wscript.exe`), not into `MsMpEng.exe`. The PPL hardening protects `MsMpEng.exe`'s process from tampering, but it does not extend to the AMSI provider DLL that gets loaded into the script host's memory space [@redcanary-amsi].
Because AMSI's trust model assumes the host process is benign. A non-admin who has code execution inside a non-PPL host can patch the host's own memory (Era 2) or flip the host's own managed state via reflection (Era 1). Neither requires admin. Hardening AMSI against the unprivileged in-process attacker would require moving AMSI out of the host process, which would defeat its latency and post-deobfuscation-visibility design. See §9 [@mdsec-evasion].
The decrypted one. AMSI is called *after* `[Convert]::FromBase64String`, after XOR, after string concatenation, and after `Invoke-Expression` argument construction. The host hands AMSI the buffer that the executor was about to run. That is the entire point of the design [@holmes-2015-wayback].
No. AMSI catches `Assembly.Load(byte[])` since .NET Framework 4.8 (April 2019) [@dotnet-48]. It does *not* catch `DynamicMethod` [@dotnet-dynamicmethod] emission via `System.Reflection.Emit`, because there is no PE-load event to anchor a scan on; the IL is built up byte by byte inside the CLR. Detection of `Reflection.Emit` abuse falls under the broader "Reflection" bypass family Trend Micro catalogues separately from the in-memory `AmsiScanBuffer` patch family [@trendmicro-bypass].
A combination of architectural and platform reasons. Architecturally, Linux and macOS do not have a shared script-engine host model; every Python, Node.js, Ruby, and Perl install is essentially its own host. Platform-wise, the demand for an out-of-the-box scan-interface contract has not materialized, even though PowerShell 7 and .NET Core both run on Linux. See §10 for the structural argument.
AMSI is synchronous and can block; ETW is asynchronous and observation-only. Both surface the same data (the post-deobfuscation buffer) and the same provider verdict. AMSI is for *decisions* (the host refuses to run flagged content). The `Microsoft-Antimalware-Scan-Interface` ETW provider with GUID `{2A576B87-09A7-520E-C21A-4942F0271D67}` is for *correlation* and *gap detection* (the SOC can see the scan happened even when an in-process bypass mutes the synchronous return) [@etw-manifest].
**Key terms.** AMSI; `AmsiScanBuffer`; `AmsiInitialize`; `AmsiOpenSession`; `HAMSISESSION`; `AMSI_RESULT_DETECTED` (32768); AMSI provider; `MpOav.dll`; CLSID `{2781761E-28E0-4109-99FE-B9D127C57AFE}`; ETW provider `{2A576B87-09A7-520E-C21A-4942F0271D67}`; trigger-buffer architecture; Script Block Logging (Event 4104); `amsiInitFailed`; Antimalware-PPL; `Microsoft-Windows-Threat-Intelligence` (EtwTi); Constrained Language Mode.
**Review questions.**
1. Why is `IOfficeAntiVirus` (Office 97) architecturally unable to catch a VBA macro that does `Application.Run` of a string decoded from a worksheet cell, even when the decoded string is malicious? (§3)
2. State the design intent Lee Holmes named in his June 9, 2015 disclosure in one sentence. Then explain why "the engine can see the actual code that will be passed to be evaluated" makes the obfuscation arms race obsolete on the AMSI side specifically. (§4)
3. Walk through every step of `AmsiInitialize` -> `AmsiOpenSession` -> `AmsiScanBuffer` -> `AmsiResultIsMalware` -> `AmsiCloseSession` -> `AmsiUninitialize` for one PowerShell command. What happens at each step, and which field in the `DeviceEvents` table does each parameter map to? (§5, §6)
4. Why does AMSI's same-process design produce both its capability (post-deobfuscation visibility) and its failure mode (in-process bypass)? What two trust assumptions make AMSI valuable anyway? (§5, §9)
5. For each of the six bypass eras in §8, state the technique in one sentence, the defender response in one sentence, and the era's residual viability against Windows 11 23H2 plus Defender in 2026.
6. Why does the `Microsoft-Antimalware-Scan-Interface` ETW provider's prologue emit survive the patchless hardware-breakpoint bypass that mutes the synchronous `AmsiScanBuffer` return? (§7, §8 Era 5)
7. What is the role of Cohen's 1984 undecidability result in framing AMSI's open problems for 2026? Why does it justify the Hendler/Kels/Rubin ~90 percent / <0.1 percent ceiling rather than refuting it? (§10)
**Further reading.** Lee Holmes, *Windows 10 to offer application developers new malware defenses* [@holmes-2015-wayback] (June 9, 2015). Microsoft Office 365 Threat Research, *Office VBA + AMSI: Parting the veil on malicious macros* [@msec-vba-amsi-2018] (September 12, 2018). Gimpel and Ben Porat, *AMSI Bypass: Patching Technique* [@cyberark-patching] (CyberArk Labs, February 2018). Hendler, Kels, and Rubin, *Detecting Malicious PowerShell Commands using Deep Neural Networks* [@hendler-arxiv] (ACM AsiaCCS 2020). Microsoft Windows-classic-samples AmsiProvider [@amsi-sample] (reference provider implementation).
**Citation availability.** Two original primary sources cited by the historical record for §8 are not currently accessible from non-browser clients and are therefore omitted as live URLs from this article's reference set; all load-bearing technique mechanics, attributions, and dates are preserved through accessible secondary sources. (a) Cornelis de Plaa's Outflank post of January 29, 2020 on the hardware-breakpoint VEH bypass (outflank.nl, "Bypassing AMSI by manipulating the AMSI scan results") is no longer reachable from non-browser clients and has no Wayback snapshot; the technique's mechanics, January 29, 2020 publication date, and Outflank/Cneelis attribution are reproduced verbatim by EthicalChaos (April 2022) [@ethicalchaos], CrowdStrike (2024) [@crowdstrike-veh], and Trend Micro (December 2022) [@trendmicro-bypass]. (b) Matt Graeber's May 2016 `amsiInitFailed` tweet sits behind the Twitter/X login wall; the tweet body, the May 2016 date, and the `amsiInitFailed` reflection technique are reproduced verbatim by Sophos (June 2021) [@sophos-bypasses] ("In May of 2016, PowerShell hacker Matt Graeber published a one-line AMSI evasion in a tweet") and MDSec (June 2018) [@mdsec-evasion] (full decompilation of the targeted private static field). Readers can reach every load-bearing primary source for both Era 1 (`amsiInitFailed`) and Era 5 (hardware-breakpoint VEH) via the corroborating links above.