AMSI & Bypass: Review of Known AMSI Bypass Techniques and Introducing a New One

## Overview

The presentation, delivered by Maor Korkos—a security researcher team leader at Deep Instinct and former vulnerability researcher—examines the Antimalware Scan Interface (AMSI). Korkos outlines the internal architecture of AMSI, reviews how consumers and providers interact, and sets up an analysis of known bypass techniques, vendor defensive countermeasures, and the introduction of a new bypass methodology.

AMSI acts as an interface standard allowing scriptable and content-executing applications to integrate with antimalware products before executing potentially untrusted code. Scripting engines and applications call Windows APIs to request scans of buffers and content prior to execution.

---

## AMSI Architecture and Operating Model

AMSI functions through a consumer-provider architecture brokered by the Windows operating system:

- **Mediation Layer (`amsi.dll`):** The mediator between consumers and providers is implemented as `amsi.dll`, which must be loaded into the address space of any AMSI-protected process. - **Consumers:** Applications that invoke AMSI to scan content. In-built Windows consumers include PowerShell (integrated from version 3 onward), JavaScript, VBScript/VBA, WMI, and UAC elevations. Newer consumers include Excel 4.0 macros, Volume Shadow Copies operations, and .NET in-memory assembly loads. Third-party developers can also consume AMSI by loading `amsi.dll` into their memory space and calling its exported APIs. - **Providers:** Antimalware vendors that register to receive scan requests dispatched through AMSI. Examples highlighted include Microsoft Defender, Deep Instinct, and SentinelOne.

---

## Process Memory Layout and Key APIs

When an application integrates with AMSI, its memory layout and runtime operations follow a specific execution flow:

1. **`AmsiInitialize`:** Called to initialize AMSI services. It accepts two parameters: - The application name requesting the service. - A reference to the context structure (`AMSI_CONTEXT`). 2. **Context Structure (`AMSI_CONTEXT`):** Once initialized, this structure stores four fields: - `signature`: Contains the literal string `"AMSI"` to identify the structure in memory. - `appName`: The application name passed as a parameter. - `antimalware`: A pointer/reference to an instance of an internal class named `CAmsiAntimalware`. - `sessionCount`: A random number assigned during initialization. 3. **`AmsiOpenSession`:** Opens a new AMSI session for subsequent scanning operations. 4. **`AmsiScanBuffer`:** Requests a scan on content buffers. It receives the context, the buffer content to evaluate, and a reference to receive the scan result (`AMSI_RESULT`). - The values returned in `AMSI_RESULT` include `AMSI_RESULT_CLEAN` and `AMSI_RESULT_DETECTED` (indicating a malicious indicator was identified). - Internally, `AmsiScanBuffer` invokes the `Scan` method defined on the `CAmsiAntimalware` class instance, which iterates through all registered providers on the machine and executes their respective exported `Scan` functions.

---

## Attack Surface and Bypass Foundations

Korkos outlines the basic attack surface from an adversary's perspective: - In the simplest antimalware provider implementations, detection relies on static signatures or lists of known malicious strings and substrings. - When providers inspect the scanned buffer for known signatures, attackers traditionally attempt string manipulation, obfuscation, or encoding techniques to evade simple substring matching. - Understanding these internal mechanics—specifically the loading of `amsi.dll`, the `AMSI_CONTEXT` layout, and the `CAmsiAntimalware` provider invocation chain—serves as the foundation for examining advanced memory patching, provider evasion, and novel bypass techniques.