AMSI Bypass: Advanced Techniques Used to Evade Windows Built-in Security
An advanced technical analysis of how modern malware and Red Teams bypass the Antimalware Scan Interface (AMSI) to execute malicious scripts completely undetected by Windows Defender.
In the constant arms race between Microsoft and cyber adversaries, the introduction of the Antimalware Scan Interface (AMSI) in Windows 10 represented a monumental leap forward for defensive security. For years, attackers relied heavily on "fileless" malware—malicious scripts written in PowerShell, VBScript, or JavaScript that executed entirely in the computer's memory. Because these scripts were heavily obfuscated and never wrote a physical executable file to the hard drive, traditional signature-based antivirus engines were largely blind to them. AMSI was designed specifically to illuminate this blind spot. It acts as a universal, vendor-agnostic bridge between scripting engines (like PowerShell) and the installed antivirus software (like Windows Defender), forcing the script content to be deeply analyzed after it has been de-obfuscated, but before it is actually executed.
Initially, AMSI decimated the effectiveness of standard, off-the-shelf hacking frameworks and drastically increased the difficulty of executing fileless attacks. However, advanced adversaries and elite Red Teams did not simply abandon PowerShell; they immediately began researching highly sophisticated methods to surgically dismantle, blind, or entirely bypass AMSI. Today, executing an AMSI Bypass is considered a mandatory, foundational skill for any modern malware developer or Red Team operator. This advanced technical article dissects the core architecture of AMSI, explores the complex methodologies attackers use to evade it—ranging from simple obfuscation to deep memory manipulation—and outlines how defenders can detect and mitigate these stealthy evasion tactics.
Understanding the AMSI Architecture
To understand how AMSI is bypassed, one must first comprehend how it functions at an architectural level within the Windows operating system. AMSI is not a standalone antivirus engine; it is an interface—a standard set of APIs.
When a user or a process attempts to execute a script (for example, by launching PowerShell), the PowerShell engine (powershell.exe) loads a specific Dynamic Link Library: amsi.dll. As the script is interpreted, the PowerShell engine passes the raw, de-obfuscated script content to the AmsiScanBuffer or AmsiScanString functions residing within amsi.dll.
amsi.dll then forwards this content via Remote Procedure Call (RPC) to the registered antimalware provider installed on the system (by default, Windows Defender). Defender analyzes the pure script content using advanced signatures and heuristics. It returns a result code back to amsi.dll, which then informs PowerShell. If Defender deems the script safe (AMSI_RESULT_CLEAN), PowerShell executes the code. If Defender flags it as malicious (AMSI_RESULT_DETECTED), PowerShell immediately halts execution and displays a glaring red error message to the user, effectively killing the attack before it can run.
The Arsenal of AMSI Bypass Techniques
Because AMSI sits directly in the execution pipeline, attackers have developed numerous techniques to disrupt this flow. The objective is rarely to uninstall the antivirus, but rather to blind the specific amsi.dll instance loaded within the current PowerShell process.
Obfuscation and String Manipulation
The simplest, though increasingly less effective, method of bypassing AMSI relies on advanced obfuscation. AMSI utilizes complex signature detection to identify known malicious strings, such as Invoke-Mimikatz or the specific byte patterns of a Cobalt Strike payload.
Attackers attempt to evade these signatures by mathematically encoding, encrypting, or heavily obfuscating the script. They utilize techniques like Base64 encoding, XOR encryption, or dynamically building strings at runtime (e.g., concatenating 'I' + 'nvoke-Mimi' + 'katz'). While basic obfuscation is often caught by AMSI’s heuristics, highly customized, bespoke obfuscation algorithms—particularly those that utilize Abstract Syntax Tree (AST) manipulation to fundamentally alter the script's structure without changing its function—can occasionally slip past the scanner, confusing the engine long enough for the payload to execute.
The PowerShell Downgrade Attack
AMSI was introduced in PowerShell version 3.0. Windows 10 and 11 come with PowerShell 5.1 installed by default, which is fully integrated with AMSI. However, for backward compatibility, many Windows systems still have the legacy PowerShell version 2.0 engine installed.
In a PowerShell Downgrade attack, the adversary simply bypasses AMSI by explicitly forcing the malicious script to execute using the old v2.0 engine. They execute a command like powershell.exe -version 2 -Command [Malicious Code]. Because the v2.0 engine was built before AMSI existed, it has absolutely no knowledge of amsi.dll and no mechanism to communicate with Windows Defender. The malicious script executes completely in the blind, bypassing the entire AMSI architecture with a single, trivial command line flag.
Reflection and the "Matt Graeber" Bypass
One of the most famous and foundational AMSI bypass techniques was discovered by security researcher Matt Graeber. This technique utilizes a powerful feature of .NET and PowerShell called Reflection. Reflection allows a script to inspect, interact with, and modify the internal, private properties and methods of the .NET framework running in its own memory space at runtime.
Graeber discovered that deep within the internal structure of the System.Management.Automation assembly (the core of PowerShell), there is a private field called amsiInitFailed. This boolean variable tracks whether AMSI successfully initialized when PowerShell started. If this variable is set to $true, PowerShell assumes AMSI is broken or unavailable and simply stops trying to scan any scripts, allowing everything to execute.
The attacker utilizes Reflection to reach deep into the restricted memory space, locate the amsiInitFailed field, and forcibly flip its value from false to true. From that millisecond onward, the current PowerShell session is completely blind. The attacker can then load massive, well-known hacking frameworks like Empire or Mimikatz directly into memory, and AMSI will not scan a single line of the code.
Memory Patching (Hooking)
As Microsoft actively patches vulnerabilities like the amsiInitFailed bypass, attackers have moved to lower-level, highly sophisticated techniques: Memory Patching (also known as function hooking).
When PowerShell loads amsi.dll, the operating system maps the code of that DLL directly into the memory space of the PowerShell process. In a memory patching attack, the malicious script utilizes specific Windows APIs (like VirtualProtect and WriteProcessMemory) to locate the exact memory address where the critical AmsiScanBuffer function resides inside amsi.dll.
Once located, the attacker overwrites the first few bytes of the AmsiScanBuffer function with a specific set of assembly instructions (often returning the code for AMSI_RESULT_CLEAN or simply an error code). When PowerShell subsequently attempts to scan a malicious script, it calls the AmsiScanBuffer function. However, instead of executing the actual scanning logic, the function immediately executes the attacker's injected assembly instructions, instantly returning a message to PowerShell saying, "This script is perfectly safe." The scan is bypassed before it even begins, blinding AMSI at the deepest architectural level.
Detection and Mitigation Strategies
Defending against sophisticated AMSI bypasses is a complex challenge, as these techniques often leverage legitimate administrative features of the operating system. Organizations must move beyond relying solely on endpoint antivirus and implement deep systemic hardening and behavioral monitoring.
Disable PowerShell Version 2.0
The most immediate and critical mitigation is to completely eradicate the PowerShell Downgrade attack. PowerShell v2.0 is a deprecated, massive security liability that provides no modern logging or security controls. Organizations must utilize Group Policy or specialized scripts to systematically uninstall the Windows Feature for PowerShell 2.0 across the entire enterprise environment. Once removed, attackers are forced to operate within modern PowerShell environments where AMSI and Script Block Logging are active.
Enforce Constrained Language Mode (CLM)
The ultimate architectural defense against advanced bypass techniques (like Reflection and Memory Patching) is the enforcement of Constrained Language Mode (CLM) via Windows Defender Application Control (WDAC) or AppLocker.
When PowerShell operates in Full Language Mode (the default), it has unrestricted access to the powerful, low-level .NET APIs necessary to execute Reflection or call VirtualProtect to manipulate memory. When CLM is enforced, PowerShell is severely restricted. It can still run standard administrative scripts, but it is explicitly blocked from utilizing advanced .NET types, COM objects, and the critical Windows APIs required to interact with system memory. By enforcing CLM, organizations effectively strip the attacker of the tools necessary to execute memory-based AMSI bypasses.
Leverage Advanced EDR and Script Block Logging
Because attackers actively attempt to blind AMSI, defenders must ensure they have alternative visibility into script execution. Organizations must forcefully enable PowerShell Script Block Logging (Event ID 4104) via Group Policy. This feature logs the entire, de-obfuscated content of every script executed on the system directly to the Windows Event Log, providing invaluable forensic data even if AMSI is successfully bypassed.
Furthermore, traditional antivirus is insufficient against memory patching. Organizations must deploy advanced Endpoint Detection and Response (EDR) solutions. EDR agents do not solely rely on AMSI; they continuously monitor the behavioral execution of processes. A robust EDR will detect the highly anomalous behavior of a PowerShell script attempting to call VirtualProtect to modify the memory region of amsi.dll, instantly terminating the process and triggering a high-priority alert before the payload can execute.
The introduction of AMSI forced a fundamental evolution in malware development, pushing attackers away from simple script execution and toward deep, highly technical memory manipulation. An AMSI Bypass is not a sign that Windows security is fundamentally broken; rather, it is a testament to the intense, continuous cat-and-mouse game between elite threat actors and operating system developers.
Securing modern Windows environments requires the understanding that AMSI, while a powerful tool, is not an impenetrable shield. Organizations must adopt a defense-in-depth posture. By aggressively disabling legacy components like PowerShell v2.0, enforcing the restrictive boundaries of Constrained Language Mode, and deploying advanced EDR solutions capable of detecting behavioral memory anomalies, security teams can effectively neutralize the sophisticated bypass techniques utilized by modern adversaries, forcing them out of the shadows of memory and back into the light of detection.
Ready to test your knowledge? Take the AMSI Bypass MCQ Quiz on HackCert today!
Related articles
COM Hijacking: System Hacking Using Windows Internal Processes
14 min
ETW Bypassing: How Cybercriminals Disable Windows Event Logs to Stay Hidden
12 min
Syscalls Execution: Direct Kernel Communication Tactics for Bypassing Security Software
11 min
5G Security: Unveiling Cyber Attack Risks in Modern Networks and Mitigation Strategies
10 min