Bypass de AMSI y ETW para Investigacion Defensiva: Lo que los Blue Teams Deben Saber
Analisis tecnico honesto de como funcionan los bypasses publicos de AMSI y ETW, y como los equipos defensivos pueden endurecer la telemetria de Windows sin quedar como tontos.
Un operador lanza Invoke-Mimikatz en un PowerShell 5.1 sin ninguna ofuscacion y no pasa nada. Defender no grita, el SOC no recibe alertas, y el ticket queda en silencio mientras la memoria de lsass ya fue leida. No es magia: es una linea de patch en amsi.dll que pone a cero AmsiScanBuffer en dos instrucciones. En 2026, AMSI y ETW siguen siendo el esqueleto de la telemetria de Windows, y siguen siendo neutralizados por scripts de cuatro lineas que circulan en GitHub desde 2016. Antes de comprar otro EDR mas, conviene entender por que estos bypasses siguen funcionando y que cambia de verdad el juego del lado azul.
AMSI (Antimalware Scan Interface) es un puente. PowerShell, VBScript, JScript, WMI e incluso macros de Office llaman a AmsiScanBuffer para preguntarle al antivirus si el contenido en memoria es malicioso. El detalle incomodo es que esa llamada ocurre dentro del propio proceso objetivo, con sus permisos. Si el atacante ya ejecuta codigo dentro de powershell.exe, puede escribir en la region .text de amsi.dll, cambiar el prologo de AmsiScanBuffer por mov eax, 0x80070057; ret y apagar la luz. Matt Graeber publico la version clasica en 2016 y siguen apareciendo variantes con hardware breakpoints, patching de AmsiOpenSession y corrupcion del amsiContext. Quien trabaja con Evasion de EDR para Investigacion: Direct Syscalls Explicados sin Romantizar reconoce el patron: la instrumentacion en user-mode siempre es soft-power.
ETW (Event Tracing for Windows) es mas profundo, pero tiene el mismo talon de Aquiles. Providers como Microsoft-Windows-Threat-Intelligence emiten eventos sobre AllocateVirtualMemory, apertura de handles a lsass e inyeccion de threads remotos, alimentando practicamente a todo EDR comercial. El bypass canonico parchea EtwEventWrite en ntdll.dll con un ret simple (xor eax,eax; ret), y listo: el provider sigue registrado, pero nada sale. Las variantes modernas tocan EtwpEventWriteFull o quitan el provider del TRACE_ENABLE_INFO. Como estos bypasses son locales y silenciosos, el hunting basado en ausencia de eventos esperados resulta mas valioso que el hunting de firma. Quien ya monta Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion sabe que las reglas de 'silencio anormal' cuestan de calibrar, pero detectan lo que la regla positiva no detecta.
Desde el lado ofensivo etico, reproducir estos bypasses en laboratorio es obligatorio para entender lo que el blue team realmente ve. Un setup minimo: Windows 11 23H2 con Defender activo, Sysmon 15 con la config de Olaf Hartong, y Elastic Agent enviando a un cluster de pruebas. Ejecuta el patch clasico de AMSI via reflection, despues con hardware breakpoints (que no tocan la .text y por eso pasan integrity checks debiles), y compara lo que Defender y Sysmon registran en cada caso. Sorpresa comun: el Event ID 4104 de PowerShell sigue capturando el bloque de script malicioso porque ScriptBlockLogging es independiente de AMSI. Este tipo de ejercicio encaja bien en un ciclo de Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue y ensena mas que leer whitepapers.
El hardening real arranca aceptando que el bypass en user-mode es barato. Habilita PowerShell Constrained Language Mode via WDAC para usuarios estandar, activa ScriptBlockLogging y Module Logging con forwarding fuera de la maquina (porque el log local el atacante lo borra), y fuerza PowerShell 7+ con la integracion AMSI verificada. Habilita Protected Process Light en Defender, activa LSA Protection (RunAsPPL) y considera Credential Guard para subir el costo de quien llego hasta lsass. A nivel ETW, lo que cambia el juego es mover la deteccion fuera del host: Sysmon + WEF a un colector dedicado, y donde sea posible kernel callbacks via driver propio del EDR, que el atacante solo derriba con BYOVD. Quien ya hace Hardening de Windows 11 para Estaciones de Trabajo de Alto Riesgo tiene buena parte del camino recorrido.
La deteccion de bypass tiene patrones claros y baratos de implementar. Busca NtProtectVirtualMemory cambiando permisos en amsi.dll o ntdll.dll dentro de procesos que no son instaladores (Sysmon Event ID 10 + filtros de imagen objetivo). Mira PowerShell que carga System.Management.Automation.AmsiUtils via reflection (Event 4104 con 'amsiInitFailed' es casi IOC literal). Monitorea la divergencia entre eventos esperados de ETW-TI y lo que llega al SIEM por host: si un endpoint empezo a emitir 70% menos eventos sin cambio de carga, algo parcheo EtwEventWrite. Esta logica de baseline por host conecta con Hunting de Living-off-the-Land Binaries en Windows con KQL y con Persistencia en Windows: 10 Tecnicas Documentadas y sus Contramedidas, donde el silencio tambien es senal.
Reportar investigacion en esta area exige cuidado etico. Un bypass de AMSI/ETW no es un 0day, pero publicar una PoC nueva sin coordinacion con Microsoft y sin foco defensivo contamina el ecosistema y ayuda a quien no necesita ayuda. El estandar sano: reproduce en lab aislado, documenta el IOC defensivo antes del exploit, y cuando publiques, lidera con la regla Sigma, no con la captura de mimikatz feliz. Si tu trabajo toca a un cliente, alinea alcance por escrito antes; si toca infra propia, practica OPSEC para Investigadores de Seguridad: Modelo de Amenaza Personal para no convertirte en blanco de lo que tu mismo estudias. Takeaway practico: asume que AMSI y ETW van a ser bypassed en el host comprometido, e invierte en ScriptBlockLogging reenviado, Sysmon con config curada y baseline de volumen de eventos por endpoint. Estos tres controles solos atrapan la mayoria de los bypasses publicos vistos en 2025-2026, sin depender de ningun vendor especifico.