AMSI Bypass Techniques: PowerShell and Beyond

The Antimalware Scan Interface is one of Microsoft's most important defensive technologies against script-based attacks. As a penetration tester, I regularly encounter AMSI during engagements, and understanding how it works and how attackers attempt to bypass it is essential knowledge for any defender. This post covers MITRE ATT&CK technique T1562.001 (Impair Defenses: Disable or Modify Tools) and helps blue teams strengthen their AMSI-related detection capabilities.

How AMSI Works Under the Hood

AMSI acts as a bridge between script engines and antimalware products. When a PowerShell script executes, the script engine sends the deobfuscated content to AMSI before execution. AMSI then forwards this content to the registered antimalware provider, typically Windows Defender, for scanning. This architecture is powerful because it sees the final, deobfuscated form of scripts, defeating many layers of encoding and obfuscation.

What AMSI Scans

AMSI is integrated into multiple Windows components, providing broad coverage against script-based threats. Defenders should be aware of all the integration points to understand their coverage.

• PowerShell scripts - Every script block is submitted to AMSI before execution, including dynamically generated code and commands typed interactively. This is the most well-known integration point and catches the majority of PowerShell-based attacks.
• VBScript and JScript - The Windows Script Host integrates with AMSI, ensuring that legacy scripting languages used in many attack chains are also scanned before execution.
• Office VBA macros - Starting with Office 365, macro code is submitted to AMSI for scanning. This significantly improves detection of malicious macros that have been a primary initial access vector for years.
• .NET assembly loads - The .NET Common Language Runtime submits assemblies to AMSI when they are loaded, which helps detect attacks that load malicious .NET assemblies reflectively into memory, a technique commonly used by tools like Cobalt Strike.

Bypass Categories Attackers Use

Understanding how attackers attempt to bypass AMSI allows defenders to build detections specifically targeting these techniques. Each category has distinct indicators that security teams should monitor for.

• Memory patching - Attackers modify the AmsiScanBuffer function in amsi.dll within the process memory to always return a clean result. This is the most common bypass approach. The act of patching this function involves specific API calls that can be detected, including calls to VirtualProtect to change memory permissions on the AMSI DLL.
• Obfuscation - Rather than disabling AMSI, some attackers heavily obfuscate their payloads to avoid triggering AMSI signatures. While AMSI sees deobfuscated content in most cases, creative encoding can sometimes evade detection. Defenders should ensure their AMSI provider has robust behavioral rules beyond simple signatures.
• Reflection-based disabling - Using .NET reflection, attackers can access internal AMSI fields and set the amsiInitFailed flag to true, causing subsequent scans to be skipped. This technique manipulates internal .NET runtime state and can be detected by monitoring for specific reflection patterns.
• COM hijacking - AMSI uses COM objects for communication between components. By redirecting the AMSI COM server registration in the registry, attackers can route AMSI calls to a benign handler. Registry modifications to AMSI-related COM entries should be closely monitored.

Testing Your AMSI Coverage

1. Understand what triggers AMSI - Use the EICAR test string or known AMSI test samples to verify that AMSI is functional in your environment. Ensure all integration points are active and reporting correctly.
2. Test obfuscation effectiveness - During penetration tests, document which obfuscation techniques bypass your AMSI provider. This helps identify signature gaps that your vendor should address.
3. Verify bypass detection - Attempt known AMSI bypass techniques in a controlled environment and verify that your EDR detects the bypass attempt itself, not just the payload it was trying to run.
4. Document detection gaps - Create a comprehensive report mapping each bypass technique to your detection capabilities, noting where additional monitoring or custom rules are needed.

Detection and Defense

Detecting AMSI bypass attempts is critical because a successful bypass may render an entire layer of your defense invisible. Here are the key detection strategies I recommend to my clients.

• Monitor for AMSI-related API calls - Watch for calls to VirtualProtect targeting amsi.dll memory regions. Sysmon Event ID 10 (ProcessAccess) and EDR telemetry can reveal when a process modifies memory protections on loaded AMSI modules.
• Enable PowerShell Script Block Logging - Event ID 4104 captures the full content of executed script blocks. Even if AMSI is bypassed, script block logging provides a separate telemetry stream that captures malicious commands. This should be enabled organization-wide via Group Policy.
• Monitor Windows Event ID 4103 - Module logging captures PowerShell pipeline execution details and provides another layer of visibility independent of AMSI.
• Watch for .NET reflection patterns - Detect PowerShell commands that use System.Reflection to access AMSI-related types and fields. Specific patterns like accessing the amsiContext or amsiSession fields are strong indicators of bypass attempts.
• Registry monitoring - Alert on modifications to AMSI COM registration keys under HKLM\SOFTWARE\Classes\CLSID. Any changes to these keys outside of legitimate software updates should be investigated immediately.
• Deploy AMSI health checks - Implement periodic automated checks that verify AMSI is functioning correctly on all endpoints. A sudden failure of AMSI on a host may indicate a bypass has occurred.

Strengthening Your AMSI Posture

Beyond detection, there are proactive steps organizations can take to make AMSI bypass more difficult for attackers. Keep Windows and Defender definitions updated, as Microsoft continuously patches known bypass techniques. Consider deploying third-party AMSI providers that offer additional detection capabilities beyond Defender. Implement Constrained Language Mode for PowerShell where possible, which restricts the .NET types available and makes many bypass techniques impossible. Finally, remember that AMSI is one layer in a defense-in-depth strategy. Even with perfect AMSI coverage, organizations need endpoint detection, network monitoring, and robust logging to maintain comprehensive visibility into their environment.