AMSI Explained - The Antimalware Scan Interface

What is AMSI?

The Antimalware Scan Interface (AMSI) is a Windows API introduced in Windows 10 (2015) that provides a standardized interface for applications to request malware scans of in-memory content at runtime. It acts as a bridge between applications that handle potentially malicious content and the antimalware products installed on the system.

Before AMSI, script-based attacks were largely invisible to antivirus engines because:

• Scripts are interpreted at runtime (never written to disk as executables)
• Obfuscated scripts are deobfuscated in memory just before execution
• Traditional AV focused on scanning files on disk

AMSI solves this by allowing the scripting engine to submit the final deobfuscated content to the AV right before execution – after all layers of encoding, concatenation, and obfuscation have been resolved.

Architecture

AMSI operates as a three-party system:

The Three Components

How a Scan Works (Step by Step)

When PowerShell executes a script, the following sequence occurs:

Key API Functions

AMSI exposes the following functions from amsi.dll:

Consumer-Side Functions

Provider-Side Interface (COM)

Providers implement the IAntimalwareProvider COM interface:

interface IAntimalwareProvider : IUnknown {
    HRESULT Scan(
        IAmsiStream *stream,      // Content to scan
        AMSI_RESULT *result       // Verdict output
    );
    void CloseSession(ULONGLONG session);
    HRESULT DisplayName(LPWSTR *displayName);
};

Provider Registration

AMSI providers register via COM in the Windows registry:

HKLM\SOFTWARE\Classes\CLSID\{<provider-GUID>}
    (Default) = "Provider Display Name"
    \InprocServer32
        (Default) = "C:\path\to\provider.dll"
        ThreadingModel = "Both"

HKLM\SOFTWARE\Microsoft\AMSI\Providers\{<provider-GUID>}
    (Default) = "Provider Display Name"

Registration requires Administrator privileges, but the provider DLL then runs in user-mode inside the calling process.

What AMSI Scans

AMSI-aware applications submit content at these points:

Why AMSI is Bypassable

AMSI has a fundamental architectural limitation that makes it vulnerable to bypass:

1. User-Mode Execution

AMSI operates entirely in user-mode (Ring 3). The amsi.dll library is loaded into the same process address space as the code being scanned. A process has full read/write access to its own memory, meaning it can:

• Overwrite AMSI function code in memory (patching)
• Modify the AMSI context structure
• Unhook or redirect function calls
• Corrupt internal state

2. No Integrity Protection

There is no kernel-mode verification that amsi.dll or the provider DLLs remain unmodified after loading. Once loaded, their code pages can be made writable and altered.

3. Pre-Scan Execution Window

The scan only happens when the consumer explicitly calls AmsiScanBuffer. If an attacker can execute code before the scan (or prevent the scan from being called), AMSI never sees the malicious content.

4. COM Registration Hijacking

Since providers are registered via COM, an attacker with user-level write access to HKCU\SOFTWARE\Classes\CLSID can redirect the provider CLSID to a benign DLL, effectively replacing the AV engine with a no-op.

Common Bypass Categories

How This Project Uses AMSI

The AMSI Raccoon Lab registers a custom AMSI provider (MostShittyAVWrapper.dll) that implements the same intentionally weak 6-check detection engine as the standalone scanner:

This allows you to practice AMSI bypass techniques in a safe environment. The 13 AMSI bypass challenges (31-43) cover real-world techniques used by red teamers and malware authors, applied against this intentionally vulnerable provider.

AMSI Bypass Challenges in This Lab

Further Reading

• Scanner Architecture - How the detection engine works internally
• BYPASS_TECHNIQUES.md - Full bypass reference for all checks
• USAGE_COMPARISON.md - AMSI Provider DLL vs Standalone EXE
• Microsoft AMSI Documentation - Official API reference