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. Before buying yet another EDR, it pays to understand why these bypasses keep working and what actually moves the needle for the blue side.

AMSI (Antimalware Scan Interface) is a bridge. PowerShell, VBScript, JScript, WMI and even Office macros call AmsiScanBuffer to ask the antivirus whether in-memory content is malicious. The awkward detail is that the call happens inside the target process itself, with target permissions. If the attacker is already running code inside powershell.exe, they can write to the .text region of amsi.dll, swap the AmsiScanBuffer prologue for mov eax, 0x80070057; ret and turn the lights off. Matt Graeber published the classic version in 2016 and variants using hardware breakpoints, AmsiOpenSession patching and amsiContext corruption keep showing up. Anyone working with EDR Evasion for Research: Direct Syscalls Explained Without the Hype recognizes the pattern: user-mode instrumentation is always soft power.

ETW (Event Tracing for Windows) sits deeper, but has the same Achilles heel. Providers like Microsoft-Windows-Threat-Intelligence emit events on AllocateVirtualMemory, lsass handle opens and remote thread injection, feeding nearly every commercial EDR. The canonical bypass patches EtwEventWrite in ntdll.dll with a simple ret (xor eax,eax; ret), and that is it: the provider stays registered but nothing leaves. Modern variants touch EtwpEventWriteFull or scrub the provider from TRACE_ENABLE_INFO. Because these bypasses are local and silent, hunting based on 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 what positive rules cannot.

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 run the hardware breakpoint variant (which does not touch .text and slips past weak integrity checks), 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.

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.

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.

Reporting research in this area calls for ethical care. AMSI/ETW bypass is not a zero-day, but publishing yet another PoC without Microsoft coordination and without a defensive angle pollutes the ecosystem and 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, not the happy mimikatz screenshot. If your work touches a client, lock scope in writing first; if it touches your own infra, practice OPSEC for Security Researchers: Building a Personal Threat Model so you do not become a target of what you study. 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.