AMSI Bypass Attacks: How Attackers Disable the Antimalware Scan Interface and How to Detect It
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AMSI is one of the most impactful security additions to Windows in the past decade. It made obfuscated PowerShell-based malware -- which was previously invisible to AV -- detectable at the point of execution. The attacker community responded by developing techniques to disable AMSI before executing malicious PowerShell. Understanding the bypass methods is necessary for writing effective detection rules -- the bypass attempt itself is a high-signal indicator that malicious activity is about to occur.
How AMSI Bypass Works (The Memory Patch Technique)
The most common AMSI bypass modifies the AmsiScanBuffer function in the amsi.dll loaded into the PowerShell process. The patch overwrites the first few bytes of AmsiScanBuffer with a return instruction that always returns AMSI_RESULT_CLEAN (0x80070057 / 0x1) regardless of the input. The patch is applied via .NET reflection to call Virtual Protect (change memory permissions), WriteProcessMemory (patch the bytes), then Virtual Protect again to restore permissions. Classic bypass (the original amsiInitFailed approach): Set the private amsiInitFailed field in the System.Management.Automation.AmsiUtils class to $true, which causes AMSI to skip all subsequent scans in that session. Both techniques are well-known and are detected by Windows Defender as specific signatures. Attackers respond by obfuscating the bypass code itself: encoding the bypass strings, splitting them with string concatenation, using variable substitution, or using compiled C# assemblies to apply the patch without PowerShell string literals. This is the escalating arms race -- the detector needs to catch the bypass attempt, not rely on AV to catch the subsequent payload.
What AMSI Bypass Strings Look Like in Logs
PowerShell Script Block Logging (Event ID 4104) captures all script content before AMSI processes it. This means the AMSI bypass code itself is captured by Script Block Logging even when AMSI is bypassed. Look for these patterns in Event ID 4104 messages: amsiInitFailed (the amsiInitFailed field set to true), AmsiScanBuffer (function being referenced for patching), amsi.dll (the DLL being loaded and patched), WriteProcessMemory or VirtualProtect (Windows API calls used for the memory patch), [Ref].Assembly.GetType or [Runtime.InteropServices.Marshal] (reflection methods used to access the AMSI internals). Even heavily obfuscated bypasses often contain string fragments detectable with regex: the reconstructed payload visible in the 4104 log before AMSI can stop it. This is why Script Block Logging is so valuable -- it provides a capture point before the bypass takes effect. Build SIEM rules that search Event 4104 for these patterns and alert immediately.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detect AMSI Bypass via ETW (Event Tracing for Windows)
Event Tracing for Windows provides lower-level visibility into AMSI activity that bypasses cannot easily avoid. The Microsoft-Windows-AMSI ETW provider generates events for every AMSI scan call including: the content being scanned, the scan result, and the process that called AMSI. Register an ETW trace: logman start AMSITrace -p Microsoft-Windows-AMSI 0xffffffffffffffff 0xff -ets. This captures all AMSI scan calls. Defender for Endpoint (MDE) uses ETW-based AMSI monitoring and generates alerts when AMSI bypass attempts are detected. If you have MDE, the AMSI bypass detection is built in -- verify it is enabled and generating alerts. For environments without MDE: deploy a lightweight ETW consumer (e.g., SilkETW) that subscribes to Microsoft-Windows-AMSI events and forwards them to your SIEM. An anomalous AMSI pattern -- many scan calls returning clean results followed by a PowerShell process that makes unusual network connections -- is a behavioral indicator of bypass.
Constrained Language Mode as a Defense
PowerShell Constrained Language Mode (CLM) restricts the .NET types and methods available in PowerShell to a safe subset. CLM is enforced when WDAC (Windows Defender Application Control) or AppLocker policies are applied. CLM prevents the .NET reflection calls that most memory-patching AMSI bypass techniques rely on -- the bypass code cannot load amsi.dll via reflection and cannot call VirtualProtect from within a constrained PowerShell session. CLM is the strongest defense against AMSI memory patch bypasses because it removes the reflection mechanism the bypass requires, not just the AMSI detection. Deploy CLM via WDAC: create a WDAC policy that puts PowerShell in CLM for all scripts not signed by your code signing certificate. Verify CLM is active: $ExecutionContext.SessionState.LanguageMode should return ConstrainedLanguage on CLM-enforced systems. Downgrades: PowerShell 2.0 (if installed) does not support AMSI or CLM -- disable the PowerShell 2.0 Windows optional feature via GPO as previously noted.
Enterprise Hardening Checklist for AMSI
Comprehensive AMSI hardening in priority order: Enable PowerShell Script Block Logging (Event 4104) on all systems -- this captures bypass attempts even when AMSI is patched. Enable PowerShell Module Logging and Transcription as secondary capture points. Disable PowerShell 2.0 (which has no AMSI support) -- Enable-WindowsOptionalFeature issue aside, use GPO to disable: Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies. Deploy Windows Defender Application Control (WDAC) with CLM enforcement for all PowerShell scripts not from your code signing CA -- this removes the reflection mechanism for AMSI bypasses. Ensure Windows Defender or your AV product has AMSI integration enabled -- some third-party AV products disable or replace the AMSI provider. Verify: Get-MpComputerStatus | Select-Object AMServiceEnabled, AntispywareEnabled. Enable Tamper Protection in Windows Defender -- this prevents attackers from disabling Defender's AMSI provider registration. Alert in your SIEM on Event 4104 for AMSI bypass indicator strings.
The bottom line
AMSI bypass is a prerequisite step for most modern in-memory PowerShell attacks. The bypass attempt itself is detectable via Script Block Logging (Event 4104) before the bypass succeeds -- this makes Script Block Logging the most important AMSI defense control. Constrained Language Mode via WDAC removes the reflection mechanism bypasses require. Disabling PowerShell 2.0 closes the AMSI-free downgrade path. Alert on AMSI bypass indicator strings in Event 4104 as a high-confidence precursor to attacker activity.
Frequently asked questions
Does AMSI only apply to PowerShell?
No. AMSI is integrated into multiple Windows scripting engines: PowerShell (most common), Windows Script Host (VBScript, JScript), .NET CLR (for all .NET-loaded assemblies), Microsoft Office VBA macros (when Office AMSI integration is enabled), and Equation Editor. Security vendors can also integrate their own applications with AMSI to scan arbitrary content. However, PowerShell is the most common attack vector that uses AMSI bypass, and Script Block Logging captures PowerShell AMSI content most reliably.
Can AMSI bypass affect Windows Defender if a third-party AV is installed?
AMSI routes scan requests to the registered antimalware provider -- whichever AV is set as the primary provider. If a third-party AV replaces Windows Defender as the primary provider and that AV has AMSI integration, AMSI bypass redirects around that AV's real-time scanning. If the third-party AV does not have AMSI integration (some do not), AMSI calls may fail silently. Verify that your AV's AMSI provider is properly registered: Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\AMSI\Providers' should show both Defender and any third-party AV providers.
Is there an AMSI bypass that works even with Script Block Logging enabled?
Script Block Logging captures content before AMSI processes it, so even a successful AMSI bypass does not prevent Script Block Logging from capturing the bypass code. However, if the bypass is implemented entirely in compiled C# code (loaded as an assembly, not executed as a PowerShell script), Script Block Logging does not capture the C# assembly content. MDE's ETW-based monitoring captures some of these reflective assembly loads via different telemetry sources. The defense-in-depth answer is: Script Block Logging plus ETW monitoring plus MDE behavioral detection together cover a wider range of bypass techniques than any single control.
How do I test if AMSI is working on an endpoint?
Run the AMSI test string from PowerShell: 'amsicontext' (this specific string is flagged by all AMSI-integrated AV products as a test signature, similar to EICAR). If AMSI is working, PowerShell returns a warning or error: 'This script contains malicious content and has been blocked by your antivirus software.' If the string is accepted without error, AMSI may be disabled, the AV may not have AMSI integration, or Tamper Protection may have been disabled. Also check: [System.Management.Automation.AmsiUtils]::AmsiInitFailed should return $false -- if it returns $true, AMSI initialization has been bypassed in this session.
What is Constrained Language Mode in PowerShell and how does it block AMSI bypass techniques?
Constrained Language Mode (CLM) restricts the .NET types and APIs that PowerShell scripts can use. Most AMSI bypass techniques rely on using PowerShell's Add-Type cmdlet or direct .NET reflection (System.Reflection.Assembly::Load, [System.Runtime.InteropServices.Marshal]) to access and patch the amsi.dll in memory. Under CLM, these reflection-based operations are blocked -- the .NET types required are restricted. CLM is enforced via WDAC (Windows Defender Application Control) policies configured with script enforcement. Without WDAC, PowerShell CLM can be set via an environment variable or registry key, but these can be bypassed by attackers who spawn a new PowerShell process. WDAC-enforced CLM cannot be bypassed without also bypassing WDAC, which requires kernel-level access.
How do you detect AMSI bypass attempts in your environment and what SIEM rules are most effective?
AMSI bypass detection relies on multiple layers because no single signal is definitive. Effective SIEM rules: PowerShell Script Block Logging (Event ID 4104) generates events containing the full script content -- search for strings commonly associated with AMSI bypass techniques: 'amsiInitFailed', 'AmsiUtils', 'System.Management.Automation.AmsiUtils', '[Runtime.InteropServices.Marshal]', and 'Reflection.Assembly'. These strings appearing in Event 4104 indicate an active bypass attempt. Defender detections: Windows Defender AV generates an alert with detection name 'Trojan:PowerShell/AmsiBypass' when known bypass patterns are detected before AMSI is patched. Event ID 7045 (new service installed) combined with process creation for PowerShell shortly after may indicate a BYOVD-assisted AMSI bypass at the kernel level. Baseline normal PowerShell encoding depth: production PowerShell that uses Base64 encoding more than two levels deep (encoded inside encoded inside encoded) is almost always an obfuscation technique associated with AMSI bypass or malware loading. Alert on PowerShell processes with three or more levels of encoding in the process command line.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.