Parag Mali - tag: amsi

Two Routes to Code Integrity: Linux IMA + AppArmor vs Windows WDAC + AMSI

noreply@paragmali.com (Parag Mali) — Sat, 16 May 2026 00:00:00 GMT

Linux and Windows have spent fifteen years answering the same question -- "is this code allowed to run?" -- and arrived at radically different architectures. Linux composes half a dozen narrow kernel modules (IMA, EVM, AppArmor, SELinux, fs-verity, IPE) plus a userspace daemon (`fapolicyd`); Windows ships one integrated suite (App Control + HVCI + AMSI + Smart App Control). Both stacks shipped their v1 with the **check in the wrong place**, and the architectural pivots that fixed it -- EVM's HMAC-sealed xattrs, HVCI's hypervisor-isolated verifier, IPE's property-based decisions -- are the breakthrough lesson of this comparison. Crypto is solved. Trust-boundary protection and policy expressiveness are not, and Rice's theorem says they never fully will be.

1. Two bypasses, same architectural shape

On a Windows 11 desktop, an attacker with a PowerShell session under their control can blind Microsoft Defender to every script that session ever evaluates by overwriting six bytes inside one function in amsi.dll. The Antimalware Scan Interface, the in-process bridge between scripting hosts and the registered antivirus product, dutifully reports "clean" on every subsequent buffer because the prologue of AmsiScanBuffer has been patched to mov eax, 0; ret (B8 00 00 00 00 C3).

The interface ships exactly as Microsoft documents it, and the function still has the signature in MSDN [@learn-microsoft-com-amsi-amsiscanbuffer]: the attacker did not need to break anything. They needed only to write into the address space they already owned.

On a Linux server, a different attacker with offline access to the disk -- recovered from a stolen laptop, a forensics image, a hostile cloud-provider snapshot -- mounts the filesystem and rewrites a system binary together with the file's security.ima extended attribute. When the box boots, the kernel's Integrity Measurement Architecture hashes the binary at exec time, compares the hash to the value stored in security.ima, sees a match, and allows execution. Without the Extended Verification Module, IMA appraisal has no defence against this offline-rewrite attack [@lwn-net-articles-394170] -- the reference hash is sitting next to the file the attacker just replaced.

Both operating systems claim fail-closed code-integrity enforcement. Both lose to a single architectural mistake about where the check runs. The mistakes are different in detail and identical in shape: the verifier is reachable by the attacker. On Windows the attacker shares the script host's address space with the scanner. On Linux the attacker shares the on-disk container with the reference hash.

This article exists to make that symmetry visible. The two stacks reached their 2026 form by very different routes -- Linux composes six narrow Linux Security Modules and one userspace daemon, Windows ships one tightly-coupled product line -- but the breakthroughs on each side answered the same question: how do you move the verifier out of reach?

The Linux answer was EVM (HMAC the extended attributes that IMA depends on) and IPE (decide on immutable file properties rather than file contents). The Windows answer was HVCI (lift the kernel-mode code-integrity check into a hypervisor-isolated secure kernel). The names are different. The lesson is one.

Why did Linux and Windows arrive at such different architectures in the first place? That story starts in an IBM research lab in 2003.

2. The question both operating systems are trying to answer

Both lineages exist to answer one question -- "is this code allowed to run?" -- but they put the check in completely different places. Before we can compare them honestly, we need a shared vocabulary for the three layers any production code-integrity stack must cover.

The first layer is code integrity itself, often abbreviated CI: a gate on the file's content or its signer. Did this .so come from a package my distribution signed? Does this .exe match an Authenticode chain rooted in a publisher my policy trusts? The answer is binary. The hook fires before the process loads the bytes.

The second layer is mandatory access control, or MAC. Now the process is running. What can it do? Can nginx open /etc/shadow? Can mshta.exe spawn cmd.exe? MAC is enforced by the kernel above discretionary access control and cannot be overridden by userspace privileges.

A kernel-enforced policy layer above traditional discretionary access control (DAC). Unlike DAC, where the file owner sets permissions, MAC policy is set by the system administrator and applied uniformly to all processes; no user, including root, can override it without changing the policy itself.

The third layer is content inspection: gating not on the file but on the buffer the interpreter is about to evaluate. The PowerShell engine has just deobfuscated a long string into a script block. Is the script block malicious? Linux has no production equivalent. Windows ships AMSI [@learn-microsoft-com-interface-portal] for exactly this.

Where each operating system puts these checks tells you almost everything about its architectural philosophy.

Linux puts every check on a Linux Security Module hook [@kernel-org-security-lsmhtml]. IMA registers at bprm_check (the kernel hook that fires when a binary is about to be executed), file_mmap with MAY_EXEC, module_check, firmware_check, and kexec_*. AppArmor and SELinux register at the syscall-level access hooks. fapolicyd rides on top of fanotify. IPE hooks op=EXECUTE. The kernel is the trust boundary, and every mechanism is a polite tenant inside it.

The kernel framework, merged into Linux 2.6.0 in December 2003, that hosts pluggable security modules at well-defined hook points in the kernel. LSMs include SELinux, AppArmor, Smack, Tomoyo, IMA, EVM, IPE, BPF LSM, and Landlock; multiple modules can coexist via "LSM stacking".

Windows takes the opposite path. The PE loader is the gate for user-mode code integrity (UMCI). The kernel-mode code-integrity check is, in the modern stack, moved out of the normal kernel into a small secure kernel running on top of Hyper-V -- Hypervisor-protected Code Integrity, HVCI [@learn-microsoft-com-code-integrity]. The script broker runs in-process with each scripting host. Cloud reputation is consulted via the Intelligent Security Graph and exposed to consumers as Smart App Control.

A monotonically extendable hash register inside a Trusted Platform Module. New measurements are folded in with `PCR_new = SHA256(PCR_old || measurement)`. Once extended, the value cannot be rolled back without resetting the TPM. IMA extends file-content hashes into PCR 10; the Windows Measured Boot chain uses PCRs 0-7 and 11-14.

The architectural philosophy comes down to a sentence each. Linux trusts the kernel surface and packs every integrity mechanism into it as a separate LSM. Windows trusts a hypervisor-isolated secure kernel and uses it to host the integrity logic the normal kernel cannot be trusted to run honestly.

flowchart LR subgraph CI[Code integrity: gate on file content or signer] direction TB L_IMA[Linux: IMA + EVM] L_IPE[Linux: IPE] L_FSV[Linux: fs-verity] L_FAP[Linux: fapolicyd] W_WDAC[Windows: App Control / WDAC] W_HVCI[Windows: HVCI / Memory Integrity] W_SAC[Windows: Smart App Control] end subgraph MAC[Mandatory access control: gate on running process behaviour] direction TB L_AA[Linux: AppArmor] L_SE[Linux: SELinux] W_NONE[Windows: no direct analogue, closest is AppContainer / ASR] end subgraph CS[Content inspection: gate on the buffer the interpreter will evaluate] direction TB W_AMSI[Windows: AMSI] L_GAP[Linux: no production equivalent] end CI --> MAC --> CS

Neither stack started this way. The 2026 stack on each side is the accumulated answer to fifteen years of failures. Here is how they grew up.

3. Two genesis stories

In 2003, four IBM researchers at the T. J. Watson Research Center -- Reiner Sailer, Xiaolan Zhang, Trent Jaeger, and Leendert van Doorn -- tried to convince the USENIX Security community that you could prove the integrity of a Linux web server to a remote verifier. Their paper, Design and Implementation of a TCG-based Integrity Measurement Architecture [@usenix-org-tech-sailerhtml], shipped at the 13th USENIX Security Symposium in 2004. It proposed hashing every executable file at load time, extending each hash into a TPM platform configuration register, and sending the resulting measurement list to a remote verifier who could compare it to a known-good manifest.

The performance evaluation [@usenix-org-sailerhtml-node19html] measured the cost on an IBM Netvista with a 2.4 GHz Pentium 4: the file_mmap LSM hook added 0.08 microseconds per call on a cache hit, and SHA-1 fingerprinting ran at roughly 80 MB/s. The headline claim was that more than 99.9% of measure calls landed on the cached path, so the overhead was essentially free.Pentium 4-era SHA-1 at 80 MB/s vs Ice Lake-era SHA-NI-accelerated SHA-256 at roughly 2 GB/s per core: a 25x throughput jump in twenty years. The original paper's qualitative finding -- cache hit dominates, overhead is negligible -- holds even more strongly on modern silicon.

It took five years for that proposal to reach the kernel. IMA's measurement-only mode was merged in Linux 2.6.30 in June 2009. It hashed files at bprm_check, file_mmap, and module_check, extended TPM PCR 10, and otherwise let everything run.

The "is this hash allowed?" question would have to wait three more years. The Extended Verification Module landed in Linux 3.2 in January 2012; digital-signature mode for EVM followed in 3.3 in March 2012; and IMA-appraise, the enforcement extension that finally let the kernel return -EPERM when a file's hash did not match security.ima, merged in Linux 3.7 in December 2012 [@lwn-net-articles-488906]. The same LWN article frames the cadence plainly: "Much of IMA was added to the kernel in 2.6.30, but another piece, the extended verification module (EVM) was not merged until 3.2 ... Digital signature support was added to EVM in 3.3, and IMA appraisal is currently under review." Mimi Zohar's appraisal patchset [@lwn-net-articles-487700] is the canonical lore.kernel.org artifact of that final step.

AppArmor took a different, longer road. It was born inside Immunix in 1998 under the name "SubDomain", a path-based confinement layer designed to stop privilege-escalation exploits from doing anything the binary's profile did not name. Novell acquired Immunix in 2005, renamed SubDomain to AppArmor, and shipped it as the default mandatory access control layer on SLES and openSUSE. According to the Ubuntu AppArmor wiki [@wiki-ubuntu-com-apparmor], "AppArmor support was first introduced in Ubuntu 7.04, and is turned on by default in Ubuntu 7.10 and later" -- so by October 2007 AppArmor was already a default-on production MAC on the most-deployed Linux desktop distribution.

Mainlining did not happen until October 2010, when AppArmor finally landed in Linux 2.6.36 [@docs-kernel-org-lsm-apparmorhtml]. Seven years out of tree, three years default-on in Ubuntu, before the kernel community accepted it.

The contrast with SELinux [@en-wikipedia-org-security-enhancedlinux] is sharp. SELinux merged into Linux 2.6.0 in December 2003 -- barely a year after the LSM framework was created. SELinux was, in fact, the reason the LSM framework existed.

SELinux's type-enforcement model maps directly to LSM's "label the subject, label the object, look up the rule" hook signature. AppArmor's path-based reasoning does not. LSM hooks see inodes, not paths -- and an inode can be reached from many paths (bind mounts, hard links, namespace games, chroots). To merge, AppArmor had to push kernel-side helpers like `vfs_path_lookup` and `d_absolute_path` upstream so it could reconstruct the absolute path of the object at hook time. The conceptual fight took three rejected merge attempts and seven years. The lesson is one Linux kernel reviewers have repeated since: a security model is not just an algorithm, it is a commitment to a particular kind of name-resolution semantics.

The Windows lineage starts in a different building entirely. AppLocker shipped with Windows 7 and Windows Server 2008 R2 in 2009: a user-mode-only allowlist, with no hypervisor or kernel-mode backing, and rules tied to file paths, publishers, or hashes. AppLocker is still supported on modern Windows but "isn't getting new feature improvements" [@learn-microsoft-com-applocker-overview]; the modern successor is App Control for Business.

Windows 10 RTM (version 1507, July 2015) shipped the first version of Device Guard along with AMSI [@learn-microsoft-com-interface-portal] and PowerShell 5.0, which integrated with AMSI from day one. Device Guard became known as Windows Defender Application Control (WDAC) and then, in 2024, was renamed once more to App Control for Business. User-mode code integrity (UMCI) became a policy option, FilePath rules were added in Windows 10 version 1903 [@learn-microsoft-com-applocker-overview], multiple-policy authoring landed in the same release, and Smart App Control made its consumer debut in Windows 11 22H2 in September 2022 [@blogs-windows-com-2022-update].

gantt title Linux and Windows code-integrity timeline dateFormat YYYY-MM axisFormat %Y section Linux SELinux mainline 2.6.0 :2003-12, 12M AppArmor at Immunix :1998-01, 84M AppArmor default in Ubuntu :2007-10, 36M IMA mainline 2.6.30 :2009-06, 32M EVM mainline 3.2 :2012-01, 2M EVM digital sigs 3.3 :2012-03, 9M IMA-appraise 3.7 :2012-12, 24M AppArmor mainline 2.6.36 :2010-10, 14M fs-verity 5.4 :2019-11, 60M IPE 6.12 :2024-11, 12M section Windows AppLocker (Win 7) :2009-10, 70M Device Guard + AMSI + PowerShell 5 (1507) :2015-07, 25M WDAC UMCI (1709) :2017-10, 18M FilePath rules + multi-policy (1903) :2019-05, 24M HVCI broadens (Win 10 1607+) :2016-08, 60M Smart App Control (Win 11 22H2) :2022-09, 24M App Control for Business rename :2024-01, 12M

Two timelines, two design philosophies, both shipping their v1 with the same kind of mistake. The next section makes that concrete.

4. Where the naive approach breaks

Both stacks shipped their first version with the check in the wrong place. Two stories make this concrete; two more refine it.

Story A: IMA-as-shipped (2009) without EVM

When IMA reached the kernel in Linux 2.6.30, it hashed the file at bprm_check and stored the reference hash in the file's security.ima extended attribute. That is what an attacker with offline disk access needs to defeat the check, and exactly nothing else. Mount the filesystem from another box, swap the binary for a malicious one, recompute the SHA over the new binary, write the new value into security.ima. Boot the box. The kernel hashes the malicious binary at exec, reads the matching xattr the attacker just wrote, and lets the syscall through.

This is the offline-tampering attacker model EVM was designed to defeat. The contemporaneous LWN coverage put it plainly: "IMA can be subverted by 'offline' attacks, where file data or metadata is changed out from under IMA. Mimi Zohar has proposed the extended verification module (EVM) patch set as a means to protect against these offline attacks." [@lwn-net-articles-394170]

The EVM v5 patchset [@lwn-net-articles-443038], posted by Zohar in May 2011, describes the design directly: "Extended Verification Module (EVM) detects offline tampering of the security extended attributes (e.g. security.selinux, security.SMACK64, security.ima) ... initial method maintains an HMAC-sha1 across a set of security extended attributes, storing the HMAC as the extended attribute 'security.evm'."

Story B: AMSI as shipped (2015) inside the script host

AMSI's design is documented in How AMSI helps you defend against malware [@learn-microsoft-com-amsi-helps]: "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. And that's the point at which you invoke the AMSI APIs."

A scripting host -- PowerShell, WSH, MSHTA, Office VBA, the UAC installer dialog -- calls AmsiInitialize, then for every plain-text script buffer it is about to execute calls AmsiScanBuffer [@learn-microsoft-com-amsi-amsiscanbuffer] or AmsiScanString. The call is routed through amsi.dll, loaded into the host process, which dispatches to the registered IAntimalwareProvider COM server. Defender is the default provider.

The detection logic is sound. The trust boundary is not. The attacker already controls the script host. Three single-shot bypass techniques have lived in red-team toolkits since 2016:

Patch AmsiScanBuffer's prologue in memory to mov eax, 0; ret (B8 00 00 00 00 C3). Six bytes of opcode rewrite, no syscalls required, blinds the scanner permanently for this process.
Set System.Management.Automation.AmsiUtils.amsiInitFailed = true via reflection. PowerShell checks the flag on every scan path and short-circuits.
Unload amsi.dll via FreeLibrary. There is no scanner left to call.

Microsoft tracks this so closely that its own "Applications that can bypass App Control" [@learn-microsoft-com-bypass-appcontrol] deny list calls out the AMSI-bypass-capable versions of system.management.automation.dll by hash. The defender's authoritative list of files-to-block treats specific signed Microsoft DLLs as named threats.The same Microsoft bypass list also enumerates mshta.exe, wscript.exe, cscript.exe, msbuild.exe, Microsoft.Build.dll, windbg.exe, cdb.exe, kd.exe, dotnet.exe, csi.exe, rcsi.exe, addinprocess.exe, wmic.exe, bash.exe, wsl.exe, runscripthelper.exe, and dozens of others -- 40+ entries today, growing whenever a new Microsoft-signed binary turns out to host an attacker-friendly evaluator.

Note: The host process making the AMSI call is the same process the attacker is running in. Any defence-in-depth plan that treats AMSI as a hard control is mis-specified. Treat AMSI as a high-quality telemetry surface feeding Defender for Endpoint and EDR pipelines; budget for the bypass.

{` // In Windows, AMSI scans each plain-text script buffer just before // the scripting engine evaluates it. The scanner lives in amsi.dll, // loaded into the script host process. The attacker who controls // that process can rewrite the function's first few bytes. // // This toy model shows the consequence: once "patched", the scanner // returns CLEAN regardless of input, and the assertion below holds // for every possible payload.

const AMSI_RESULT_CLEAN = 0; const AMSI_RESULT_MALWARE = 32768;

function amsiScanBuffer(buf, patched) { if (patched) return AMSI_RESULT_CLEAN; if (buf.includes("Invoke-Mimikatz")) return AMSI_RESULT_MALWARE; return AMSI_RESULT_CLEAN; }

console.log("Normal mode:"); console.log(" clean payload: ", amsiScanBuffer("Get-Process", false)); console.log(" malicious payload:", amsiScanBuffer("Invoke-Mimikatz", false));

console.log("\nAfter six-byte patch:"); console.log(" clean payload: ", amsiScanBuffer("Get-Process", true)); console.log(" malicious payload:", amsiScanBuffer("Invoke-Mimikatz", true));

// The takeaway: no input ever produces MALWARE once the scanner is patched. // Strengthening AMSI's signature engine cannot fix this. The scanner // must move out of the script host's address space. `}

Story C: WDAC's "trust all Microsoft-signed code" anti-pattern

A WDAC policy that trusts code signed by Microsoft also trusts every binary Microsoft has ever signed. That set includes mshta.exe, wscript.exe, cscript.exe, msbuild.exe, wmic.exe, system.management.automation.dll, and the 40-plus other binaries enumerated on Microsoft's own App Control bypass list [@learn-microsoft-com-bypass-appcontrol]. The LOLBAS community catalogue [@lolbas-project-github-io] widens the field to roughly 200 living-off-the-land binaries with explicit MITRE ATT&CK technique mappings.

The pattern is structural: WDAC grants trust at signer granularity (a chain rooted at "Microsoft Corporation"); attackers exploit at binary granularity (the specific mshta.exe that will happily evaluate an HTA blob containing a PowerShell stager). Any non-trivial WDAC policy must therefore contain explicit hash-level denies for the known-bad versions, and must keep growing those denies as Microsoft ships new signed binaries.

Story D: fapolicyd's permissive-window failure

fapolicyd [@access-redhat-com-fapolicydsecurity-hardening] is the Red Hat userspace allowlister. It sits on the fanotify permission channel and answers "may this open or exec proceed?" against a compiled rule database. It does not have IMA's offline-tampering problem because trust is inherited from the RPM database: "An application is trusted when the system package manager correctly installs it and therefore registered in the system RPM database. The fapolicyd daemon uses the RPM database as a list of trusted binaries and scripts."

What it does have is an operational footgun. Setting permissive=1 "just for troubleshooting" silently disables enforcement. Terminating the daemon causes the kernel to fail open after the fanotify response timeout. The architectural choice -- userspace daemon over kernel-mode hook -- is what makes both failure modes possible.

Key idea: The check was strong. The boundary protecting the check was weak. On IMA-as-shipped the reference hash sat next to the file the attacker rewrote. On AMSI the scanner sat inside the process the attacker controlled. On WDAC the trust grant was wider than the exploitation unit. On fapolicyd the verifier was a userspace process that could be terminated. Four different stacks, four different boundary failures, one identical lesson.

Bypass class	Stack	Concrete example	Root cause
Offline metadata swap	IMA without EVM	Rewrite binary and matching `security.ima` xattr from rescue media	Reference value stored next to the file under attacker control
In-process scanner patch	AMSI in PowerShell	`mov eax, AMSI_RESULT_CLEAN; ret` over `AmsiScanBuffer` prologue	Scanner shares address space with the script host the attacker runs in
Signer-vs-binary mismatch	WDAC Publisher rules	Allow Microsoft-signed code, attacker runs `mshta.exe`	Trust grant is coarser than the exploitable unit
Daemon liveness	fapolicyd	Terminate `fapolicyd` or set `permissive=1`	Verifier is a userspace process with no kernel-rooted backstop

Each of these failures has the same shape: the check was strong, the boundary protecting the check was weak. Both operating systems noticed, and fixed it in 2012 and 2016 in very different ways. Both fixes followed the same principle.

5. The architectural pivots

Both lineages reached the same conclusion at the same time: strengthen the boundary, not the check. Each pivot moved the trust boundary outward, beyond the place the attacker could reach.

EVM (Linux 3.2, January 2012): the xattrs become non-forgeable

The Extended Verification Module computes an HMAC over the security-relevant extended attributes -- security.ima, security.selinux, security.SMACK64, security.apparmor, security.capability -- plus inode metadata (UID, GID, mode, generation), and stores the result in security.evm. The HMAC key is loaded into the kernel keyring at boot, ideally sealed to a TPM 2.0 PCR set so the key is not retrievable except on a machine whose boot state matches the sealing measurement. The kernel keyring documentation for trusted and encrypted keys [@kernel-org-trusted-encryptedhtml] describes the substrate.

An offline attacker with disk access still cannot forge security.evm without the HMAC key. Digital-signature mode (EVM portable signatures, Linux 3.3) gives the same guarantee without any on-box key material. The check did not get cryptographically stronger: HMAC-SHA256 was not new in 2012. What changed was that the reference value the check consults moved from "an xattr next to the file" to "an xattr whose integrity is bound to a key the attacker does not have". Red Hat documents the modern setup in Enhancing security with the kernel integrity subsystem [@access-redhat-com-subsystemsecurity-hardening].

The Linux integrity module that protects the security-relevant extended attributes IMA depends on. EVM computes an HMAC (or digital signature) over the xattr set plus inode metadata and stores it in `security.evm`. Without the EVM key, an offline attacker cannot rewrite a binary and its matching `security.ima` to produce a valid pair. sequenceDiagram participant App as User app participant K as Kernel participant FS as Filesystem participant IMA as IMA participant EVM as EVM participant TPM as TPM keyring App->>K: execve("/usr/bin/foo") K->>IMA: bprm_check hook IMA->>FS: read file bytes IMA->>IMA: compute SHA-256 IMA->>FS: read security.ima xattr IMA->>EVM: verify xattr integrity EVM->>FS: read security.evm and full xattr set EVM->>TPM: HMAC key from keyring (sealed to PCRs) EVM->>EVM: recompute HMAC over xattr set + inode meta alt HMAC matches and IMA hash matches EVM-->>IMA: ok IMA-->>K: allow K-->>App: exec proceeds else mismatch EVM-->>IMA: -EPERM IMA-->>K: deny K-->>App: -EPERM end

IMA-appraise (Linux 3.7, December 2012): from observation to enforcement

The merge cadence on the kernel side is itself part of the story. Measurement-only IMA shipped in 2.6.30 in 2009. EVM merged in 3.2 in January 2012. EVM digital signatures merged in 3.3 in March 2012. IMA-appraise, which finally lets the kernel return -EPERM on a hash mismatch, merged in Linux 3.7 in December 2012 [@lwn-net-articles-488906]. Three and a half years from "we hash files" to "we refuse to run files that fail the hash". The gap was not engineering laziness; it was the time it took to design and merge the boundary-strengthening pieces that made enforcement safe to enable.

HVCI / Memory Integrity (Windows 10 1607, August 2016): the secure kernel

Windows took the equivalent step four years later, but at a different layer. Virtualization-Based Security (VBS) [@learn-microsoft-com-oem-vbs] splits Windows into Virtual Trust Level 0 -- the normal kernel everyone has been writing rootkits for since 1993 -- and Virtual Trust Level 1, a small secure kernel hosted by Hyper-V. The kernel-mode Code Integrity check that gates loading of every driver is moved into VTL1. A VTL0 attacker with full SYSTEM, even one who has loaded a malicious driver, cannot patch the VTL1 verifier; they cannot even read its memory.

Windows' Hyper-V-rooted split that puts a small secure kernel in VTL1, isolated from the normal Windows kernel (VTL0) by the hypervisor. Hypervisor-protected Code Integrity (HVCI), exposed in Windows Settings as "Memory integrity", uses VTL1 to host the kernel-mode code-integrity check, so a VTL0 attacker with SYSTEM cannot patch the verifier or downgrade its policy.

Microsoft's HVCI documentation [@learn-microsoft-com-oem-vbs] frames the W^X invariant HVCI enforces on kernel pages: "memory integrity ... protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS ... ensuring that kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable." A kernel page can be writable or executable; never both at the same time. The split is enforced by the hypervisor."HVCI", "Memory Integrity", and "kernel-mode code integrity running in VBS" are the same mechanism. Microsoft's product-name churn here is unusually thick: the Windows Settings UI calls it Memory Integrity, the documentation page is titled "Enable virtualization-based protection of code integrity", the underlying capability is HVCI, and Microsoft also markets the same hardware-and-software bundle as "Secured-Core PC".

flowchart TD subgraph VTL0[VTL0: normal Windows kernel] P[User process] DRV[Driver load request] RK[Hypothetical rootkit with SYSTEM] K0[NT kernel] P --> K0 DRV --> K0 RK --> K0 end K0 -->|hypercall: verify driver| HV[Hypervisor] RK -.X.-> SK HV --> SK subgraph VTL1[VTL1: secure kernel] SK[Secure kernel] CI[Kernel-mode CI verifier] SK --> CI end CI -->|allow / deny| HV HV -->|result| K0

IPE (Linux 6.12, November 2024): property-based decisions

The most recent Linux pivot moves further still. Integrity Policy Enforcement [@docs-kernel-org-lsm-ipehtml], upstreamed in Linux 6.12 in November 2024 from a Microsoft-contributed patch series (source on GitHub [@github-com-microsoft-ipe]), does not hash files at all. Its kernel documentation is explicit: "Integrity Policy Enforcement (IPE) is a Linux Security Module that takes a complementary approach to access control. Unlike traditional access control mechanisms that rely on labels and paths for decision-making, IPE focuses on the immutable security properties inherent to system components." A policy rule looks like:

op=EXECUTE dmverity_signature=TRUE dmverity_roothash=sha256:<hex> action=ALLOW
op=EXECUTE fsverity_signature=TRUE action=ALLOW
op=EXECUTE action=DENY

The kernel is not asked "what is the SHA-256 of this file?" at op=EXECUTE time. It is asked "did this file come from a dm-verity device whose root hash matches one of our trusted signatures?" The verifier has nothing to compute per access; it has only to read a pre-computed property. The trust boundary has moved out to whoever signed the dm-verity image at build time.

fs-verity (Linux 5.4, November 2019): O(log n) per page

The cryptographic complement is fs-verity [@kernel-org-filesystems-fsverityhtml], upstreamed in Linux 5.4 in November 2019 by Eric Biggers and Theodore Ts'o at Google. The kernel docs describe the trick: "fs-verity is similar to dm-verity but works on files rather than block devices ... userspace can execute an ioctl that causes the filesystem to build a Merkle tree for the file and persist it to a filesystem-specific location ... Userspace can use another ioctl to retrieve the root hash ... in constant time, regardless of the file size."

The Merkle tree turns whole-file hashing into O(log n) verification per page read, with constant-time digest retrieval. Concretely, an APK or container layer with thousands of pages does not need a full hash on first open; the page cache verifies the leaves and intermediate Merkle nodes only for the pages actually touched. IMA can consume fs-verity's digest directly through the digest_type=verity modifier in its policy language.

The breakthrough was not a stronger check. It was moving the check out of the attacker's address space.

Each pivot moved the trust boundary outward in a different direction. EVM moved the integrity root from "xattr next to the file" to "HMAC-keyed xattr, key sealed to TPM PCRs". HVCI moved the kernel-mode verifier from "in the kernel the attacker can patch" to "in a secure kernel the attacker cannot reach without breaking the hypervisor". IPE moved the per-access decision from "recompute a file's hash" to "look up a precomputed property". Fs-verity collapsed the per-access cost from O(n) on the file to O(log n) on a Merkle path.

The crypto was already strong. The breakthrough was the geometry of where the verifier lived.

By 2020 both stacks looked dramatically different from their 2009 and 2015 originals. Here is what each one looks like today, side by side.

6. The stack today, side by side

Eleven moving parts. Here is how they line up.

Linux	Windows	Layer
IMA appraise + EVM	App Control (WDAC) UMCI	User-mode code integrity
Kernel module signing	App Control + HVCI driver enforcement	Kernel-mode code integrity
fs-verity + dm-verity	HVCI page-level W^X + signed catalogues	Page-level integrity
AppArmor / SELinux	(no direct analogue; closest is AppContainer / ASR)	Mandatory access control
fapolicyd	App Control + AppLocker	User-space allowlist
IPE	App Control (FilePath / hash rules)	Property-based code integrity
(no direct analogue)	AMSI	Script content scan
(no direct analogue)	Smart App Control + ISG	Cloud reputation

The mapping is not 1-to-1 in either direction. Linux composes; Windows consolidates. To compare meaningfully we have to look at each layer in turn.

6.1 Code-integrity enforcers: IMA + EVM vs WDAC vs IPE

Dimension	Linux IMA + EVM	WDAC (App Control)	IPE
Enforcement layer	VFS / LSM hook (file open, mmap, exec)	PE loader (kernel CI, user-mode CI)	LSM hook on `op=EXECUTE`
Identity primitive	File-content hash or `imasig` / `modsig` / `sigv3`	Authenticode chain, hash, FilePath, or ISG	dm-verity root hash / fs-verity digest
Policy expression	Procedural rules (`func=` / `mask=` / `fsmagic=`)	Signed XML compiled to binary `.p7b`	Signed plain-text DFA
Worst-case per-access	O(n) hash on first access; O(1) cached	O(1) cached; O(n) hash on cache miss	O(1) (properties precomputed)
Fail-closed mode	Yes (appraise)	Yes (enforced)	Yes
Remote-attestation friendly	Yes (TPM PCR 10)	Indirect (Measured Boot logs)	Indirect
Bypass arms race	Whole-disk swap (countered by EVM key sealing)	LOLBins (Microsoft block list + community LOLBAS)	Limited surface (DFA-only)

The IMA policy ABI [@kernel-org-testing-imapolicy] documents the full rule grammar: action [condition ...] where action is one of measure | dont_measure | appraise | dont_appraise | audit | dont_audit | hash | dont_hash, and conditions select on func=, mask=, fsmagic=, fsuuid=, uid=, fowner=, LSM-label predicates, and the all-important appraise_type= modifier that names the signature scheme. IMA template management [@docs-kernel-org-ima-templateshtml] controls what gets recorded per measurement-list entry; the two templates used in practice today are ima-ng (d-ng|n-ng: hash-algo-prefixed digest plus name) and ima-sigv2 (d-ngv2|n-ng|sig: versioned digest plus name plus signature).

WDAC's policy rule reference [@learn-microsoft-com-to-create] defines the rule kinds operators actually write: Publisher, PcaCertificate, LeafCertificate, FileName, Version, Hash (SHA-1, SHA-256, or SHA-384), FilePath (added in 1903 and explicitly weaker because a user with write access can substitute the file), Managed Installer, and Intelligent Security Graph. The compiled output is a signed binary .p7b CIPolicy.

The same doc records the default-on audit-mode behaviour that has surprised many operators: "We recommend that you use Enabled:Audit Mode initially because it allows you to test new App Control policies before you enforce them ... By default, only kernel-mode binaries are restricted. Enabling the following rule option validates user mode executables and scripts." The Enabled:UMCI flag is what flips a WDAC policy from kernel-only to full user-mode enforcement.

flowchart LR PE[PE load request] --> AC[Parse Authenticode signature] AC --> RM[Match rule set] RM --> P[Publisher / cert rule?] P -->|hit| AL[Allow] P -->|miss| H[Hash rule?] H -->|hit| AL H -->|miss| FP[FilePath rule?] FP -->|hit| AL FP -->|miss| MI[Managed Installer?] MI -->|hit| AL MI -->|miss| ISG[Intelligent Security Graph?] ISG -->|hit| AL ISG -->|miss| DEF[Default action] AL --> BL{"In bypass-list deny?"} BL -->|yes| BLK[Block] BL -->|no| LOAD[Loader continues] DEF --> BLK

6.2 Mandatory access control: AppArmor vs SELinux

Dimension	AppArmor	SELinux
Model	Path-based allowlist per binary	Type-enforcement on subject x object x class
Storage of policy state	In-memory DFA loaded from user space	`security.selinux` xattr + compiled `policy.31`
Granularity	Profile per executable	Per-type, per-class, per-operation
Survives file rename	No (path is the identity)	Yes (xattr travels with inode)
Default-on distros	Ubuntu, openSUSE, SLES	RHEL, Fedora, Oracle Linux, Android, ChromeOS
Authoring tools	`aa-genprof`, `aa-logprof`, `aa-enforce`	`audit2allow`, `semodule`, refpolicy, `udica`

AppArmor's kernel documentation [@docs-kernel-org-lsm-apparmorhtml] describes the model directly: "AppArmor is MAC style security extension for the Linux kernel. It implements a task centered policy, with task 'profiles' being created and loaded from user space." A profile reads like a rule file rather than a label algebra:

/usr/sbin/nginx {
  capability net_bind_service,
  /etc/nginx/** r,
  /var/log/nginx/* w,
  /var/www/** r,
  network inet stream,
}

The kernel compiles each profile to a DFA at load time, so policy lookup is O(L) in path length. SELinux's compiled policy uses a hash-table query against compiled type-enforcement rules with an in-memory access-vector cache for O(1) hot decisions. Both are practical; they differ on which model fits the way an administrator thinks. AppArmor wins on auditability and quick authoring; SELinux wins on expressiveness and on what the Wikipedia summary [@en-wikipedia-org-security-enhancedlinux] calls Mandatory Access Control for multi-level security. Smack [@schaufler-ca-com] is a third in-tree LSM, simpler than SELinux, used heavily by Tizen.

Red Hat's `fapolicyd` is the answer for operators who want App Control-style allowlisting without rebuilding the kernel. Trust is inherited from the RPM database; the daemon sits on the kernel's `fanotify` permission channel and answers ALLOW or DENY on every `open` and `exec`. Per the RHEL hardening guide [@access-redhat-com-fapolicydsecurity-hardening], rule files in `/etc/fapolicyd/rules.d/` are concatenated in lexicographic order into `compiled.rules`. The Red Hat-shipped numbered prefixes are 10 (language interpreters), 20 (dracut), 21 (updaters), 30 (patterns), 40/41/42 (ELF), 70 (trusted languages), 72 (shell), 90 (deny-execute), 95 (allow-open). First-match-wins evaluation means operators adding custom rules must give their file a number lower than 90 to ensure their `allow` is reached before the catch-all deny.

6.3 Hypervisor-anchored CI: HVCI

HVCI's runtime cost is dominated by the hypercall round-trip from VTL0 to VTL1 on driver load and on each executable-page allocation. Steady-state overhead is small on hardware with the right capabilities.

Microsoft's HVCI documentation [@learn-microsoft-com-code-integrity] names the dependency: "Memory integrity works better with Intel Kabylake and higher processors with Mode-Based Execution Control, and AMD Zen 2 and higher processors with Guest Mode Execute Trap capabilities. Older processors rely on an emulation of these features, called Restricted User Mode, and will have a bigger impact on performance." Practitioner-visible rule of thumb: less than 5 percent overhead on MBEC/GMET-capable silicon, 10 to 20 percent on kernel-bound workloads when the CPU has to emulate.

HVCI hardware prerequisites per the OEM VBS guidance [@learn-microsoft-com-oem-vbs]: 64-bit CPU with virtualization extensions (VT-x or AMD-V), second-level address translation (EPT or RVI), an IOMMU (VT-d or AMD-Vi), TPM 2.0, UEFI MAT, Secure MOR v2, and ideally MBEC (Intel) or GMET (AMD).

6.4 Script-level inspection: AMSI vs Linux's gap

Dimension	AMSI	Linux IMA on scripts
What it sees	Deobfuscated script buffer at execution time	Whole-file content at `open` or `mmap`
Coverage	PowerShell, WSH, VBA, JScript, MSHTA, UAC installers, .NET, Edge	Any file whose `func=FILE_CHECK` rule matches
Provider model	COM `IAntimalwareProvider` per process	None; kernel verifies signature directly
Defends against runtime obfuscation	Yes (sees final buffer)	No (sees file as written)
Trust boundary	Wrong (in-process; patchable by attacker)	Right (kernel-side; attacker cannot patch)

The asymmetry is the point. AMSI sees what the interpreter is about to evaluate; IMA sees only what is on disk. AMSI catches in-memory PowerShell payloads, Office macros that decode themselves at runtime, and Invoke-Expression evaluations that never touched the filesystem. IMA's hash is final at file write time and tells you exactly nothing about what bash -c "$(curl evil)" will execute.

The reduced PowerShell language mode App Control forces on systems with UMCI enabled. It blocks reflection (the `[System.Reflection]` namespace), dynamic-type creation, and arbitrary .NET API calls. It is the runtime-side complement to App Control: even if a script gets in, its evaluation surface is dramatically reduced. This is also what makes the `amsiInitFailed` flag-flip bypass non-trivial under modern App Control: the reflection needed to set the flag is blocked.

6.5 Cloud reputation: Smart App Control

Smart App Control [@learn-microsoft-com-business-appcontrol] ships as a pre-baked WDAC policy bundled with Windows 11 22H2 and later. The App Control overview describes it as the consumer-facing entry point introduced in Windows 11 version 22H2 to bring application control to home users. On every fresh install SAC starts in evaluation mode for 48 hours. Microsoft's cloud reputation service silently observes the user's app inventory; on enterprise-managed devices SAC auto-disables at the end of the window unless the user explicitly opts in. Once disabled by user, policy, or the auto-disable rule, it can only be re-enabled by performing a clean install of Windows. A Settings > Reset This PC is not sufficient.

Three quirks operators must understand. First, evaluation lasts 48 hours and is silent. Second, enterprise-managed (Intune, AAD-joined, GPO-managed) devices auto-disable at evaluation end. Third, disable is one-way: there is no "restart evaluation" path. The intended deployment model is that enterprises use full App Control with a managed-installer policy, not SAC. Consumers with a small app footprint and no IT team get a cloud-driven allowlist for free; everyone else is expected to author a policy.

Note: Once Smart App Control is off on a device, it can only be re-enabled by performing a clean install of Windows. A Settings > Reset This PC does not re-enable SAC. Treat enabling SAC as a deployment decision, not a casual toggle.

6.6 fs-verity as the per-file Merkle layer

For the data-at-rest performance story, fs-verity's ioctl(FS_IOC_ENABLE_VERITY) builds the Merkle tree, persists it next to the file, and switches the file to read-only. FS_IOC_MEASURE_VERITY returns the digest in constant time. IMA's policy language gained appraise_type=sigv3 and the digest_type=verity modifier so a rule like

appraise func=BPRM_CHECK fsmagic=0xef53 appraise_type=sigv3 digest_type=verity

asks the filesystem for the file's fs-verity digest (O(1)) and verifies the kernel-stored signature over that digest, rather than re-hashing the file even on first access. Supported on ext4, f2fs, and btrfs.

Eleven mechanisms, two architectures, one shared shape: an allowlist of trusted producers plus a hook that can refuse to honour anything outside it. The allowlist of producers is the deepest common assumption, and it is also where the next class of attacks lives.

7. Bypass arms races

Every code-integrity system on the market is in a continuous fight with the bypass it shipped with. The fights tell you what each architecture got wrong.

The AMSI bypass family

The three single-shot techniques from Section 4 -- prologue patch, amsiInitFailed flag flip, library unload -- have all been answered by partial mitigations. Microsoft has hardened AMSI provider loading [@learn-microsoft-com-interface-portal] to require Authenticode-signed provider DLLs from Windows 10 1903 onward. Defender ships ETW-based detection that flags in-memory patches to amsi.dll. Constrained Language Mode (forced by App Control) blocks the reflection needed to flip AmsiUtils.amsiInitFailed. None of these closes the structural problem. AMSI is by design a function call inside the script host. As long as the host process is the trust boundary, the attacker who reaches the host process wins.

The trust boundary is wrong: the host process making the AMSI call is the same process the attacker is running in. The simplest in-memory patch overwrites `AmsiScanBuffer`'s prologue with a six-byte sequence that loads `AMSI_RESULT_CLEAN` (0) into EAX and returns:

xor eax, eax    ; 31 C0
ret             ; C3

or, depending on the calling convention the patcher targets:

mov eax, 0x80070057   ; B8 57 00 07 80   (HRESULT E_INVALIDARG)
ret                   ; C3

Both variants are detected by modern Defender via the ETW patch detection, but neither requires kernel privileges or a syscall to apply.

The WDAC LOLBin arms race

Microsoft's App Control bypass list [@learn-microsoft-com-bypass-appcontrol] is a maintained document that any non-trivial WDAC policy must merge into its deny rules. The 40-plus entries include mshta.exe, wscript.exe, cscript.exe, msbuild.exe, Microsoft.Build.dll, windbg.exe, cdb.exe, kd.exe, dotnet.exe, csi.exe, rcsi.exe, addinprocess.exe, addinutil.exe, aspnet_compiler.exe, bash.exe, wsl.exe, runscripthelper.exe, system.management.automation.dll, and webclnt.dll / davsvc.dll. The community LOLBAS index [@lolbas-project-github-io] widens the field to roughly 200 entries with MITRE ATT&CK technique IDs.

Tooling (the WDAC Wizard, AaronLocker, Microsoft's ConfigCI PowerShell module, CiTool.exe) automates merging the deny set into a base policy and onto Intune. The asymmetry is the bottom line: trust granted at signer granularity, exploitation at binary granularity. The deny list is not a fix; it is a treadmill.

A trusted binary, often shipped by the OS vendor and signed by the vendor's code-signing certificate, that an attacker re-purposes to bypass an allowlist or to perform actions that would be blocked if attempted with non-vendor tooling. Examples on Windows: `mshta.exe` to evaluate HTA scripts, `regsvr32.exe` to execute a remote scriptlet, `installutil.exe` to run code via a designed-for-development assembly loader.

fapolicyd permissive-window

This is not a cryptographic bypass; it is the architectural choice (userspace daemon over fanotify) showing its operational seam. A privileged operator who sets permissive=1 to debug a noisy rule and forgets to revert has silently disabled enforcement. If the daemon dies under load or after a bad rule deploy, the kernel waits for the fanotify response timeout and then fails open. There is no failsafe equivalent of HVCI's "the verifier is in another address space" guarantee.

IMA / EVM offline-key attacks

EVM is only as strong as its key custody. If the HMAC key is loaded from a file on disk (the worst-case configuration), an attacker with root on a running system can read it, then perform the offline-rewrite attack of Section 4 with a valid security.evm HMAC. TPM-sealed keys close this path on hardware that supports sealing; some installations skip the seal step "until we add a TPM" and never do. Asymmetric (EVM portable signatures) mode avoids on-box key custody but requires a per-package signing pipeline most distributions have not built.

The cross-stack symmetry

Both lineages obey two architectural rules, and both have at least one place where they break each rule:

Bypass class	Linux instance	Windows instance	Root cause	Partial mitigation
Verifier shares address space with attacker	(script interpreters; no in-kernel interpreter scanner)	AMSI prologue patch, `amsiInitFailed` flag flip	Software-only protection of an in-process secret is impossible	ETW patch detection, signed providers, Constrained Language Mode
Trust grant coarser than exploit unit	RPM trust pre-fapolicyd integrity-mode addition	WDAC Publisher rules + LOLBins	Trust algebra cannot express "Microsoft except mshta" with one rule	Hash-level denies, growing block list
Reference value reachable by attacker	IMA without EVM	(HVCI moved the kernel verifier out of reach)	Reference value next to the file under attacker control	EVM HMAC sealed to TPM PCR
Verifier is killable	fapolicyd daemon failure	(HVCI verifier is hypervisor-isolated)	Verifier liveness is part of the trust assumption	TPM-sealed boot policy + kernel-mode fallback

The first row is the most uncomfortable for both stacks. Linux does not have an AMSI-equivalent in production, so there is no in-kernel hook that sees the buffer an interpreter is about to evaluate; the boundary is not "wrong", it simply does not exist. Windows has the hook and has paid for the consequences of putting it in the wrong place for ten years. Neither result is good.

The lesson from both rows of pivots is consistent: when an architecture is forced to put the verifier somewhere reachable, treat its output as telemetry rather than control, and budget for the bypass.

These are not implementation bugs. They are structural features of the architectures, and to understand why, we have to look at what computer science says is and is not possible.

8. What the theory says

Three impossibility results bound everything in this article. Two are decades old; the third is a property of how modern interpreted languages execute.

Rice's theorem

Rice's 1953 theorem says that any non-trivial semantic property of an arbitrary program is undecidable from the program text alone. Applied to malware: there is no algorithm that takes a binary as input and returns "malicious" or "benign" in finite time for every input.

Every code-integrity stack on the market therefore reduces to the same shape: an allowlist of producers (signers, hashes, dm-verity roots) the operator chooses to trust, plus a hook that refuses to honour anything outside the allowlist. Defender, ClamAV, the AMSI scanner -- all the things we call "malware detectors" -- are heuristic add-ons running on top of an allowlist substrate, and they are explicitly fallible. They have to be.

No software-only protection of an in-process secret

The second result is operational, not formal, but it is no less binding. If process P holds a secret S, and process P also evaluates code C the attacker chose, then no purely software-side technique inside P can keep C from reading or rewriting S.

AMSI's design violates this: the scanner is a function call inside the script host, and the attacker is running code in the script host. HVCI's entire architecture exists to relocate the kernel-mode code-integrity verifier out of the host's address space, into a secure kernel the attacker cannot reach with normal kernel privileges. EVM's design likewise moves the integrity-defining key into a kernel keyring sealed to TPM PCRs so an offline attacker with disk access cannot reach it.

No verification of dynamically generated executable code

The third result is the gap on both operating systems. JIT-compiled code (V8, JVM, CLR), libffi closures, and anonymous mmap followed by mprotect(PROT_EXEC) all produce executable bytes that did not exist on disk and were never hashed.

The IPE documentation [@docs-kernel-org-lsm-ipehtml] lists this as an explicit limitation: a property-based check on the file the JIT compiled does not authenticate the bytes the JIT emitted. WDAC's User-Mode Code Integrity has the same gap for managed runtimes that emit IL at runtime. There is no production answer on either side; there are only mitigations: disable JITs where possible, run them in restricted runtimes (Constrained Language Mode), block the trampolines.The JIT gap is one reason both stacks ship "Constrained Language Mode"-style restricted-runtime options. PowerShell's Constrained Language Mode blocks reflection and dynamic-type creation; the JVM's --module-path and module-system encapsulation play a similar role for hosted Java code; the CLR's AppContainer and the .NET Core trim modes lean the same way. None of these "verify" the JIT output; they restrict what the runtime is willing to emit.

Cryptographic bounds

The cryptographic side, by contrast, is closed.

Any preimage-resistant hash needs $\Omega(n)$ work on the data being hashed. You cannot verify a file you do not read.
A Merkle tree with leaf size $k$ over a file of size $n$ reduces this to $O(\log(n/k))$ per partial read. The classic Merkle 1979 construction underlies dm-verity, fs-verity, and the Android APK Signature Scheme v4. fs-verity matches this lower bound.
Whole-file SHA-256 on modern x86 with SHA-NI runs at roughly $2 \text{ GB/s}$ per core; SHA-512 at $\sim 1.4 \text{ GB/s}$. A 100 MB binary verifies in roughly $50 \text{ ms}$ worst-case and $0 \text{ ms}$ cached. RSA-2048 and Ed25519 signature verification both finish in well under a millisecond on modern hardware (tens to a few hundred microseconds depending on CPU and library); verify cost is not the bottleneck.

So on the crypto side the gap between upper and lower bounds is closed. On the policy-expressiveness side there is no "best" policy because the right policy depends on threat model. There is no Pareto frontier; there are only trade-offs.

Bound	What it says	Mechanism that matches it	Remaining gap
Rice's theorem	"Is this binary malicious?" is undecidable	Every CI stack is an allowlist + signer model	Allowlist composition is itself a policy problem
In-process secret	No purely-software defence inside the attacker's address space	HVCI moves verifier to VTL1; EVM key in keyring sealed to TPM	AMSI design violates this; the gap is structural
Hash verification	$\Omega(n)$ per full read; $O(\log n)$ per partial read	fs-verity per page; IMA cached on `i_iversion`	Cold-cache cost remains O(n) for non-fs-verity files
JIT and dynamic code	No way to verify code that did not exist on disk	None	Restricted-runtime modes (CLM, AppContainer) are the best partial answer
Asymmetric verify	About 60-300 us per RSA-2048 or Ed25519 verify on modern x86	Authenticode catalogues amortise; IMA caches in inode	Cold cache is the only sensitive case

Key idea: Crypto is closed. Policy expressiveness and trust-boundary protection are theoretically unsolvable in general. Every stack is an allowlist plus a trusted-signer model, never a malware detector. The wall is theoretical, not engineering.

If the theory says we cannot win, what is research targeting in 2026?

9. Open frontiers

Three problems define the 2026 research front. All are being worked on upstream. None will dissolve the theoretical bounds of Section 8.

Linux integrity at distribution scale: the Integrity Digest Cache

IMA appraisal has a scale problem. On a general-purpose Linux distribution where every file is RPM-signed, asking IMA to verify a per-file imasig signature on every open is expensive.

Roberto Sassu (Huawei Cloud) proposed a fix as the digest_cache LSM in version 3 of the patchset, posted in February 2024 [@lore-kernel-org-1-robertosassuhuaweicloudcom] and covered on LWN [@lwn-net-articles-961591]. The v3 cover letter is concrete: "Preliminary tests have shown a speedup of IMA appraisal of about 65% for sequential read, and 45% for parallel read." The design extracts pre-computed reference digests from vendor-signed digest lists (RPM headers, kernel TLV digest-list format, third-party formats via loadable parsers) and exposes a digest_cache_lookup() primitive that integrity providers (IMA, IPE, BPF LSM) call instead of verifying per-file signatures.

By v6 in November 2024 [@lore-kernel-org-1-robertosassuhuaweicloudcom-2] the work had been retitled "Introduce the Integrity Digest Cache" and pivoted from a standalone LSM into an integrity-subsystem helper, in response to maintainer feedback. The v6 cover letter quantifies the baseline the design attacks: IMA measurement "introduces a noticeable overhead (up to 10x slower in a microbenchmark) on frequently used system calls, like the open()." Discussion continues on the linux-integrity list [@lore-kernel-org-linux-integrity]; memory safety of the TLV parser was verified with the Frama-C [@frama-c-com] static analyser. As of late 2024 the work is not yet upstream.

Preliminary tests have shown a speedup of IMA appraisal of about 65% for sequential read, and 45% for parallel read. -- Roberto Sassu, digest_cache LSM v3 cover letter, February 2024

The important framing correction: the Integrity Digest Cache is not a Linux AMSI equivalent. AMSI is an interpreter-side scanner of the deobfuscated, about-to-execute script buffer. The Integrity Digest Cache is a file-content digest delivery mechanism that closes the same gap IMA already closes, but more efficiently and at distribution scale. The Linux script-content gap remains genuinely open.

Out-of-process AMSI broker

The conjectural fix on the Windows side is an out-of-process AMSI broker: every AmsiScanBuffer call IPCs to a service running outside the script host's address space. The in-process bypass family disappears because the attacker is no longer in the same process as the scanner. The cost is a context switch and serialisation overhead per script eval.

Microsoft has layered partial mitigations -- signed AMSI provider DLLs from 1903, ETW patch detection in Defender, Constrained Language Mode under App Control -- but no full out-of-process redesign exists. Whether it ever will is a function of how willing Microsoft is to pay the latency cost on hot PowerShell loops.

Cross-OS attestation

A verifier validating evidence from a mixed Linux + Windows fleet today must speak two languages at once. IMA's measurement-log format (ima_template_fmt) and Windows Measured Boot's WBCL [@trustedcomputinggroup-org-log-format] both target TPM PCRs but encode events differently.

Confidential-computing efforts (Intel TDX, AMD SEV-SNP) are pushing toward a common report/quote primitive at the platform layer, and the TCG Canonical Event Log Format aims at a portable per-entry representation. Workload-level integrity proofs remain stack-specific. The two operating systems do not yet speak a common attestation language.

Problem	Current best partial result	Upstream status
IMA appraisal scale on RPM-signed distros	Integrity Digest Cache, 45-65% appraisal speedup	Patchset v6 (Nov 2024); not upstream
AMSI in-process trust boundary	Signed provider DLLs, ETW patch detection, CLM	Partial; structural fix would be OOP broker
Linux script-content scanning	Nothing in production	Open
Cross-OS attestation interop	TCG CEL, TDX/SEV-SNP quotes	Platform-layer; workload-level still split
WDAC LOLBin treadmill	Microsoft block list + LOLBAS + WDAC Wizard	Operational; structural fix unknown

Each of these will probably ship in the 2026-2028 window. None of them dissolves the theoretical bounds of Section 8. The job for a defender in 2026 is therefore operational, not technological.

10. Practitioner decision guide

Eight common deployment scenarios. Eight concrete answers.

If you need...	On Linux, use...	On Windows, use...
TPM-backed remote attestation	IMA + EVM (TPM PCR 10)	Measured Boot + TPM PCR 11 + HVCI
Block unsigned drivers	`module.sig_enforce=1` plus kernel module signing	HVCI (Memory Integrity)
Cryptographic allowlist of installed software	fapolicyd (RPM/DEB trust)	App Control with Publisher rules
Per-app sandbox	AppArmor or SELinux	AppContainer or App Control (no direct equivalent)
Catch in-memory PowerShell payloads	(no direct equivalent)	AMSI
Consumer-grade reputation gating	(no direct equivalent)	Smart App Control
Immutable appliance image	dm-verity + IPE	App Control with hash rules + HVCI
Large APK-style assets verified lazily	fs-verity	(no direct equivalent)

The why behind each row.

TPM-backed attestation. On Linux, IMA's measurement mode extends file hashes into PCR 10 and ships the measurement log to a remote verifier (Keylime, Veraison). On Windows it means consuming the Measured Boot event log a Windows kernel emits while VBS+HVCI is enabled. Both stacks target the same root of trust (the TPM) but speak different event formats.

Blocking unsigned drivers. Linux uses a built-in kernel module signing flag. Windows needs HVCI, because the kernel-mode CI check runs in VTL1 and any policy weakening attempted from VTL0 with SYSTEM cannot reach it.

Application allowlisting on general-purpose distributions. This is fapolicyd's wheelhouse: it inherits trust from the RPM/DEB database, which is the only place a general-purpose distro has a clean "trusted" list. On Windows, App Control with publisher rules plus a managed-installer policy is the equivalent.

Per-app sandboxing. Clean Linux story (AppArmor or SELinux per binary). On Windows it is the gap App Control was never quite designed to fill; AppContainer or Microsoft Defender Attack Surface Reduction rules are the substitutes.

In-memory PowerShell payloads. AMSI's use case. Linux has nothing equivalent in production.

Consumer reputation gating. Smart App Control's use case. Linux distros have nothing equivalent because the distribution-package model already plays that role.

Immutable appliance images. Dm-verity plus IPE on Linux. App Control hash rules plus HVCI on Windows.

Large lazy-loaded assets. Fs-verity territory; Windows has no public equivalent.

Common implementation pitfalls

Distilled from the same shape: every stack has a default that surprises operators.

IMA without EVM and without a TPM-sealed key is decorative. Hashing files into an xattr the attacker can rewrite buys you nothing against offline access. EVM is mandatory; the EVM key must be sealed.
AppArmor profiles authored in complain mode never get promoted to enforce. Schedule a config-management pass that runs aa-enforce on the profiles you actually want to confine.
SELinux setenforce 0 for debugging that becomes permanent. The /.autorelabel flag is required after restoring contexts; track that you flipped it.
fapolicyd permissive-mode lapses. Set up alerting on permissive=1 in the runtime configuration; treat the daemon's exit status as a security event.
WDAC's Enabled:Audit Mode policy-rule option is on by default. Policies silently do not enforce until you remove it. Add a deployment check that asserts audit mode is off before declaring rollout complete.
HVCI without a driver-compatibility check. Microsoft's DG_Readiness_Tool and the HVCI compatibility report belong in every pilot. Vendors that allocate RWX kernel pages will fail HVCI loading and leave the host unbootable.
Treating AMSI as a control. It is telemetry. Budget for the bypass on day one.
Smart App Control disable is one-way. A single mis-click ends the consumer reputation gate until the device is reset. Make sure the user understands this before they tap the toggle.

Note: On Linux: enable IMA in measure mode before appraise; deploy AppArmor / SELinux profiles in complain / permissive before enforce; run fapolicyd with permissive=1 for the first deploy. On Windows: leave WDAC's Enabled:Audit Mode set during the first rollout and use the event log to identify the policy gaps before flipping to enforced. Audit mode is the only safe way to discover that the policy is wrong before it locks you out of production.

Note: A bare IMA appraisal policy without an HMAC-keyed EVM (and without the key sealed to a TPM 2.0 PCR set) does not stop an offline attacker. If you do not have TPM-sealed key custody and signed-xattr xattrs, IMA appraisal is mostly a check-box. fapolicyd with integrity=ima may be a saner starting point on machines without TPM.

Usually no, unless your distribution signs every system file (most do not for `imasig` in production) and you have a TPM-sealed EVM key. For general-purpose servers, fapolicyd with RPM-database trust is usually the right answer; it inherits trust from packages you already trust and does not require kernel-side signature infrastructure. Reserve IMA appraise for appliance / fixed-function builds, embedded distros, or fleets with a signed-package pipeline. Path-based reasoning maps to how administrators think about confinement: "this binary may read /etc/nginx, may write /var/log/nginx, may bind a network socket." SELinux's type-enforcement model is more expressive (it lets a single rule cover an entire class of objects across paths and bind mounts), but it requires the administrator to think in compiled-policy terms. Both are correct; pick the one whose mental model matches your team. The right answer on Ubuntu and SUSE is almost always AppArmor; the right answer on RHEL and Android is almost always SELinux. No. Microsoft's block list [@learn-microsoft-com-bypass-appcontrol] grows whenever a new signed binary turns out to host an attacker-friendly evaluator. Treat WDAC as defence-in-depth, layered with HVCI and AMSI-as-telemetry, not as a single-point allowlist. The WDAC Wizard and AaronLocker projects automate keeping the deny set current; even with them, expect the deny set to evolve every quarter. Yes. Enable it, but configure it as a telemetry source feeding Defender for Endpoint and any EDR pipeline you operate. The bypass family of Section 7 is real, but the un-bypassed case still catches the long tail of script-based attacks that do not bother defeating AMSI, and the bypass attempt itself is highly detectable (in-memory patch ETW events). Treat AMSI alerts as detective controls, not preventive controls. On CPUs with Intel MBEC (Kaby Lake or newer) or AMD GMET (Zen 2 or newer) [@learn-microsoft-com-oem-vbs], the steady-state overhead is generally under 5 percent. On older CPUs that rely on the Restricted User Mode emulation path, kernel-bound workloads can see 10 to 20 percent regressions. Run your specific kernel-bound benchmarks on the actual hardware before enabling on a fleet with a mixed CPU generation; "free" is a Kaby Lake-and-newer claim. Usually no. SAC auto-disables on enterprise-managed devices (Intune-enrolled, Azure AD-joined, or under Group Policy management) at the end of the 48-hour evaluation window unless the user explicitly opts in. The intended deployment model is that enterprises use full App Control with a managed-installer policy, not SAC. If SAC has already auto-disabled and you actually want it on, the only path to re-enable is a clean install of Windows. A Settings > Reset This PC does not bring it back.

The two architectures answer the same question with different trade-offs. A practitioner in 2026 needs both maps, because the bypass that breaks the Linux side rarely looks like the bypass that breaks the Windows side, and the mitigation that fixes one is rarely the mitigation that fixes the other.

What stays constant is the lesson the two lineages converged on over fifteen years: the trust boundary is the architecture. Move the verifier out of reach. Allowlist the producers. Treat the things that cannot be moved as telemetry, not as control. None of that closes Rice's wall, but all of it pushes the actual exploitable surface back another mile, on both operating systems.

AMSI: The Pre-Execution Window Where Defender Catches a Base64 Payload It Has Never Seen Before

noreply@paragmali.com (Parag Mali) — Tue, 12 May 2026 00:00:00 GMT

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

Write-Host 'pwnd!'

A signature on that exact byte string catches the lazy attacker, and only the lazy attacker. The next attacker writes:

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:

AmsiInitialize(LPCWSTR appName, HAMSICONTEXT *amsiContext) once at startup. The appName string identifies the host: PowerShell passes "PowerShell_<GUID>", .NET passes "DotNet", Office passes its application name [@amsi-initialize]. The string later surfaces in telemetry as DeviceEvents.AmsiProcessName.
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].
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].
AmsiResultIsMalware(result) to interpret the out parameter. The macro evaluates to non-zero when the AMSI_RESULT is at or above 32768 [@amsi-resultismalware].
AmsiCloseSession to release the session handle.
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), 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\<version>\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 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(<base64-decoded-PowerShell>).

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

For detection engineers: the `appName` string you pass to `AmsiInitialize` becomes `DeviceEvents.AmsiProcessName` in the Defender XDR advanced-hunting schema, and the `contentName` you pass to `AmsiScanBuffer` becomes the human-readable label the SOC analyst triages [@deviceevents-table].

If you are integrating a new host, set contentName to the script-block ID, the assembly's friendly name, or the URL the macro came from. Never set it to a random GUID, never set it to an empty string. Future-you, hunting at 2 a.m., will thank present-you.

If you are hunting, the AmsiProcessName column tells you which host did the scan, which lets you quickly distinguish a PowerShell payload that landed via winword.exe (Office VBA -> Shell -> powershell.exe) from one that landed via outlook.exe (link click -> Edge -> PowerShell). The two have completely different lateral-movement implications.

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) 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:

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

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:

AddVectoredExceptionHandler(1, exceptionHandler) -- register a vectored exception handler.
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.
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 (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.

The pragmatic alternative to "AMSI as a security boundary" is *defense in depth across three trust models*, which is what Microsoft has actually shipped:

The synchronous gate. AMSI in-process. Beats the unprivileged-payload case. Cannot be a boundary because of the latency math above.
The ETW correlation seam. The Microsoft-Antimalware-Scan-Interface provider emits the buffer to whoever can read it. Beats the in-process bypass case, because the ETW emit happens before the bypass-clobbered return [@ethicalchaos].
The policy-denial layer. Constrained Language Mode under WDAC User Mode Code Integrity, and the "Block Macros from Internet" default. These do not scan content; they refuse to run it [@ps-clm] [@internet-macros-blocked].

The three together cover the cases AMSI alone cannot. Each one is weak alone. None of them is a security boundary in MSRC's strict sense; together, they cover the operational space.

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:

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].
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.
ThreadingModel must be Both. Marshaling proxies break the in-process performance assumption.

Defender inherits a legacy contract from the IOfficeAntiVirus era: when a full third-party AV registers itself as the active antimalware provider, Defender unregisters itself as the active AV and remains as a passive scanner. AMSI is the modern instance of that contract. Your registered provider becomes the active AV slot; Defender steps aside. The flip is not silent: Defender logs the transition, and admin tools display the new active AV in Windows Security Center. If you are the registered provider and Defender is *not* yielding, recheck your registration (both registry trees, signing, and that your provider's `IAntimalwareProvider::DisplayName` returns a non-empty string).

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.

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