AMSI and ETW Bypass for Defensive Research: What Blue Teams Should Know

An operator throws Invoke-Mimikatz at PowerShell 5.1 with zero obfuscation and nothing happens. Defender does not scream, the SOC gets no alert, and the ticket stays silent while lsass memory has already been read. This is not magic: it is a one-line patch in amsi.dll that zeroes AmsiScanBuffer in two instructions. In 2026, AMSI and ETW are still the skeleton of Windows telemetry, and they are still neutralized by four-line scripts that have been on GitHub since 2016. This article dissects, layer by layer, why these bypasses keep working, how to reproduce them cleanly in a lab, and what actually moves the needle for the blue side without buying yet another expensive EDR.

What AMSI really is and why it lives inside the victim process

AMSI (Antimalware Scan Interface) is a bridge, not a wall. PowerShell, VBScript, JScript, WMI and even Office macros call AmsiScanBuffer to ask the registered antivirus whether in-memory content is malicious. The decisive detail is that the call happens inside the target process itself, with target permissions and in the target address space. If the attacker is already running code inside powershell.exe, they sit on the same side of the trust boundary as the scan routine. They can write to the .text region of amsi.dll, swap the AmsiScanBuffer prologue for mov eax, 0x80070057; ret (E_INVALIDARG, read as "clean") and turn the lights off. Matt Graeber published the classic reflection variant in 2016, and variants using hardware breakpoints, AmsiOpenSession patching and amsiContext corruption keep showing up.

The longevity is structural, not sloppy. As long as the instrumentation lives in user mode and in the same process, it is by definition tamperable by anyone executing code in that process. Anyone working with EDR Evasion for Research: Direct Syscalls Explained Without the Hype recognizes the pattern: user-mode instrumentation is always soft power. Microsoft hardens the surface (signatures for known patch bytes, stricter AMSI integrity in PowerShell 7), but the core principle remains: the defender places the sensor in the attacker's living room.

ETW as the deeper layer with the same Achilles heel

ETW (Event Tracing for Windows) sits deeper in the system but shares the weakness. Providers like Microsoft-Windows-Threat-Intelligence emit events on NtAllocateVirtualMemory, lsass handle opens and remote thread injection, feeding nearly every commercial EDR. The canonical bypass patches EtwEventWrite in ntdll.dll with a simple xor eax,eax; ret, and that is it: the provider stays registered but nothing leaves the process. Modern variants touch EtwpEventWriteFull, scrub the provider from TRACE_ENABLE_INFO, or lower per-thread trace levels. Because these bypasses are local and silent, hunting based on the absence of expected events becomes more valuable than signature hunting.

Anyone already building Threat Hunting with Sigma and Elastic: From Indicator to Detection Rule knows that "abnormal silence" rules are painful to tune, but catch exactly what positive rules cannot. The core value of ETW-TI is that it originates in the kernel; the bypass, however, happens in user mode before the event leaves the process. Move collection closer to the kernel or off-host and the user-mode patch loses its effect.

The classic AMSI patch step by step

Conceptually the reflection bypass works like this: obtain the amsiInitFailed field via [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') and set it to true so PowerShell skips the scan. The more robust memory patch resolves the address of AmsiScanBuffer via GetProcAddress(LoadLibrary("amsi.dll"), "AmsiScanBuffer"), calls VirtualProtect with PAGE_EXECUTE_READWRITE, writes the return stub bytes, and restores protection. The hardware breakpoint variant is more elegant: it never touches .text, instead setting debug registers (Dr0-Dr7) on AmsiScanBuffer via SetThreadContext and forging the return value in an exception handler. Because it modifies no code, it slips past weak integrity checks that only look for patched bytes.

Important for defensive analysis: the reflection patch leaves a very characteristic trace in PowerShell ScriptBlockLogging (Event ID 4104) because the strings AmsiUtils and amsiInitFailed are logged before AMSI is disabled. The memory patch, by contrast, is visible through NtProtectVirtualMemory on amsi.dll. Each technique trades stealth for complexity, and none is invisible if you look in the right place.

Lab setup to see what blue actually captures

From the ethical offensive side, reproducing these bypasses in a lab is mandatory if you want to understand what the blue team actually sees. A minimum setup: Windows 11 23H2 with Defender enabled, Sysmon 15 with Olaf Hartong's config, and Elastic Agent shipping to a test cluster. Run the classic reflection-based AMSI patch, then the hardware breakpoint variant, and compare what Defender and Sysmon record in each case. Common surprise: PowerShell Event ID 4104 still captures the malicious script block because ScriptBlockLogging is independent of AMSI. This kind of drill fits naturally into a Purple Team in Practice: Building a Red vs Blue Feedback Loop cycle and teaches more than any whitepaper.

Isolation is part of the drill: no domain join between lab and production, no internet egress that could exfiltrate tested payloads, and snapshots before each run so the baseline stays reproducible. Always measure the null state first (what gets logged with no bypass?), then the bypass state. The difference is your detection opportunity.

Real hardening: what actually costs the attacker

Real hardening starts from accepting that user-mode bypass is cheap. Enable PowerShell Constrained Language Mode via WDAC for standard users, turn on ScriptBlockLogging and Module Logging with forwarding off the box (local logs get wiped), and force PowerShell 7+ with verified AMSI integration. Enable Protected Process Light for Defender, switch on LSA Protection (RunAsPPL) and consider Credential Guard to raise the cost of anyone who reaches lsass. At the ETW layer, the game-changer is moving detection off the host: Sysmon plus WEF to a dedicated collector, and where possible kernel callbacks via the EDR's own driver, which only falls to BYOVD.

Anyone already running Windows 11 Hardening for High-Risk Offensive Security Workstations has half the road done. Prioritization matters: WDAC/Constrained Language Mode and forwarded ScriptBlockLogging return more per hour invested than another EDR license. The goal is not to make the bypass impossible (it cannot be, in the same process) but to make it expensive, loud and traceable.

Detection: concrete patterns and IOCs

Bypass detection has clear, cheap patterns to ship. Hunt for NtProtectVirtualMemory changing permissions on amsi.dll or ntdll.dll inside processes that are not installers (Sysmon Event ID 10 plus target image filters). Look at PowerShell loading System.Management.Automation.AmsiUtils via reflection (Event 4104 containing "amsiInitFailed" is almost a literal IOC). Watch the divergence between expected ETW-TI events and what reaches the SIEM per host: if an endpoint suddenly emits 70 percent fewer events with no workload change, something patched EtwEventWrite.

This per-host baselining ties into Hunting Living-off-the-Land Binaries on Windows with KQL and into Windows Persistence: 10 Documented Techniques and Their Countermeasures, where silence is also a signal. Add behavioral rules: a PowerShell process that loads amsi.dll and shortly after allocates an RWX region is more suspicious than any single indicator on its own.

Common mistakes on both sides

On the blue side, the most common mistake is trusting AMSI 4104 without securing forwarding: if the attacker can wipe local logs, your IOC is gone. A second is hunting only for byte signatures of the classic patch and missing the hardware breakpoint variant entirely. On the offensive (lab) side, the most common mistake is testing bypasses against production assets or publishing PoCs with no defensive context. A third, often overlooked: many assume an AMSI bypass also disables ETW — it does not, they are separate mechanisms and must be bypassed separately and detected separately.

Checklist for blue teams

Short and actionable: (1) enable ScriptBlockLogging and Module Logging and forward off-host via WEF. (2) enforce Constrained Language Mode via WDAC for standard users. (3) enable RunAsPPL and Credential Guard. (4) Sysmon 15 with a curated config plus Event ID 10 on amsi.dll/ntdll.dll. (5) per-endpoint baseline of ETW-TI event volume with an alert on drops. (6) 4104 search for "amsiInitFailed"/"AmsiUtils". (7) document detection with the Sigma rule, not the mimikatz screenshot. (8) validate every control in a purple-team cycle against real bypasses, not on paper.

FAQ: Is a modern EDR enough against AMSI/ETW bypass?

No, not alone. A good EDR makes bypasses harder and detects them through kernel callbacks and behavioral analysis, but once the attacker is in the process they can tamper with user-mode sensors, and with BYOVD attack kernel components too. The value is defense in depth: EDR plus forwarded ScriptBlockLogging plus WDAC plus off-host telemetry. No single product closes the gap because the gap is architectural, not product-specific.

FAQ: Is it legal to research and publish these bypasses?

Reproducing them in your own isolated lab is legitimate defensive research. Publishing requires ethical care. An AMSI/ETW bypass is not a zero-day, but publishing a PoC with no defensive angle mostly helps people who do not need help. The healthy standard: reproduce in an isolated lab, document the defensive IOC before the exploit, and when you publish, lead with the Sigma rule. If your work touches a client, lock scope in writing; if it touches your own infra, practice OPSEC for Security Researchers: Building a Personal Threat Model.

Conclusion

Practical takeaway: assume AMSI and ETW will be bypassed on a compromised host, and invest in forwarded ScriptBlockLogging, a curated Sysmon config and a per-endpoint event-volume baseline. Those three controls alone catch most public bypasses seen in 2025-2026, with no specific vendor required. The through-line is always the same: the defender who assumes the host sensor can be tampered with, and therefore places detection off-host and behavioral, beats a bypass that bets on the defender's convenience.