Windows Defender Bypass Techniques: 2026 Methods

In early 2026, the Lazarus Group’s campaign targeting financial sector endpoints relied on a well-documented AMSI bypass to drop a Cobalt Strike beacon — undetected for 11 days. The technique wasn’t novel. It was a patched variant of something red teamers have known for years. Defender is good, but it has seams. Here’s where they are right now.

AMSI Patching: Still Alive in 2026

AMSI (Antimalware Scan Interface) is the bridge between PowerShell and Defender. Every script you run gets scanned through it. Attackers patch it in memory to make it return a clean result before Defender ever sees the payload.

The classic string-based patch was burned long ago. Defender’s signature catches AmsiScanBuffer patches written in plain PowerShell. What works today is indirect patching via a C# loader that calls the Win32 API through a reflectively loaded assembly — keeping the malicious string out of the PowerShell pipeline entirely.

Here’s a sanitized, conceptual representation of what the loader does at the API level, as captured by a ProcMon trace on host CORP-WS04 (192.0.2.44), user jreynolds:

Process:   powershell.exe PID: 4812
Operation: WriteProcessMemory
Path:      \Device\HarddiskVolume3\Windows\System32\amsi.dll
Address:   0x00007FFD3C1A2B40   (AmsiScanBuffer offset)
PrevBytes: 4C 8B DC 49 89 5B 08
NewBytes:  B8 57 00 07 80 C3 00   ; ret AMSI_RESULT_CLEAN
Result:    SUCCESS

Those seven bytes are the patch. B8 57 00 07 80 loads the value 0x80070057 (E_INVALIDARG) into EAX, then C3 returns immediately. The scan never runs. From this point, any PowerShell code executes without hitting Defender’s engine.

As a defender, this is your signal. If EDR telemetry shows WriteProcessMemory targeting amsi.dll offsets from a PowerShell child process — that’s your alert. Correlate it with the parent process tree. In incident response, the jreynolds session above would show a Word macro as the grandparent.

Defender Exclusion Abuse: The Quiet Kill

Patching AMSI is noisy if your EDR is tuned. The quieter technique is abusing Defender exclusions that already exist on the machine. Enterprise environments routinely exclude backup agent directories, AV product folders, and dev tool paths. Attackers enumerate them first.

This one-liner runs under a standard user context and reads exclusions from the registry on CORP-WS04:

PS C:\Users\jreynolds> Get-ItemProperty \
  "HKLM:\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths" | \
  Select-Object -Property * -ExcludeProperty PS*

Name                           Value
----                           -----
C:\ProgramData\Veeam\Backup     0
C:\DevTools\node_modules        0
C:\Temp\BuildOutput             0
PSPath                         Microsoft.PowerShell.Core\Registry::...

Three excluded paths, readable without elevation. C:\Temp\BuildOutput is the jackpot. An attacker drops a staged payload there — no AMSI scan, no real-time protection, no quarantine. The file sits at rest and executes cleanly.

This is why exclusion hygiene matters more than most teams realize. Each of those paths was added by an admin solving a legitimate problem — a backup job failing, a Node build throwing false positives. Nobody audited them afterward.

For the red teamer: after enumerating exclusions, drop a renamed Meterpreter DLL into C:\Temp\BuildOutput\, then trigger it via a scheduled task or a DLL hijack in the same directory. Execution is clean. For the defender: exclusions should be time-bounded and logged. If your SIEM isn’t alerting on registry writes to HKLM:\SOFTWARE\Microsoft\Windows Defender\Exclusions, fix that today.

ETW Blinding: Cutting Defender’s Telemetry Feed

Defender’s behavioral engine depends on Event Tracing for Windows (ETW) — a kernel-level telemetry pipeline. Blind it and Defender loses visibility into what’s running, even if AMSI is intact.

The technique targets the ETW session that feeds the Microsoft-Windows-Threat-Intelligence provider. A process with SeDebugPrivilege can patch EtwEventWrite in ntdll.dll to return immediately, suppressing events system-wide for that process’s lifetime.

The impact shows up in Defender’s own logs on CORP-WS04:

EventID: 5004  Source: Microsoft-Windows-Windows Defender
Date:    2026-09-14 03:17:42
Message: Windows Defender Real-Time Protection feature has changed.
         Feature: IOAV
         New Value: 0 (Disabled)

EventID: 1120  Source: Microsoft-Windows-ETW
Date:    2026-09-14 03:17:43
Message: ETW session "EventLog-Security" lost events.
         Lost Events: 847
         Reason: Buffer overflow / consumer too slow

847 lost events in one second is not a buffer issue. That’s ETW blinding. The attacker’s process ran, did its work, and exited — leaving a gap in telemetry that looks like a logging hiccup. Correlate EventID 1120 spikes with process creation logs in the same second. That’s your pivot.

What To Do Now

Open PowerShell as admin on one of your Windows endpoints right now and run Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension. Export the output. For every path listed, ask: who added this, when, and is it still needed? Revoke anything you can’t justify. Then push an alert rule in your SIEM for any future writes to the Defender exclusions registry key. That single audit will close more real risk than a week of theoretical threat modeling.