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. Este texto desarma, capa por capa, por que estos bypasses siguen funcionando, como reproducirlos limpiamente en laboratorio y que cambia de verdad el juego del lado azul sin comprar otro EDR caro.
Que es AMSI en realidad y por que vive dentro del proceso de la victima
AMSI (Antimalware Scan Interface) es un puente, no un muro. PowerShell, VBScript, JScript, WMI e incluso macros de Office llaman a AmsiScanBuffer para preguntarle al antivirus registrado si el contenido en memoria es malicioso. El detalle decisivo es que esa llamada ocurre dentro del propio proceso objetivo, con sus permisos y en su espacio de direcciones. Si el atacante ya ejecuta codigo dentro de powershell.exe, esta del mismo lado de la frontera de confianza que la rutina de escaneo. Puede escribir en la region .text de amsi.dll, cambiar el prologo de AmsiScanBuffer por mov eax, 0x80070057; ret (E_INVALIDARG, leido como "limpio") y apagar la luz. Matt Graeber publico la variante clasica por reflection en 2016, y siguen apareciendo variantes con hardware breakpoints, patching de AmsiOpenSession y corrupcion del amsiContext.
La longevidad es estructural, no descuido. Mientras la instrumentacion viva en user-mode y en el mismo proceso, es por definicion manipulable por cualquiera que ejecute codigo en ese proceso. 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. Microsoft endurece la superficie (firmas de bytes de patch conocidos, integridad AMSI mas estricta en PowerShell 7), pero el principio se mantiene: el defensor pone su sensor en la sala del atacante.
ETW como capa mas profunda con el mismo talon de Aquiles
ETW (Event Tracing for Windows) es mas profundo en el sistema pero comparte la debilidad. Providers como Microsoft-Windows-Threat-Intelligence emiten eventos sobre NtAllocateVirtualMemory, 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 simple xor eax,eax; ret, y listo: el provider sigue registrado, pero nada sale del proceso. Las variantes modernas tocan EtwpEventWriteFull, quitan el provider del TRACE_ENABLE_INFO o bajan los niveles de trace por thread. 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 justo lo que la regla positiva no detecta. El valor de ETW-TI es que nace en el kernel; el bypass, en cambio, ocurre en user-mode antes de que el evento salga del proceso. Mueve la recoleccion mas cerca del kernel o fuera del host y el patch de user-mode pierde efecto.
El patch clasico de AMSI paso a paso
Conceptualmente el bypass por reflection funciona asi: obtienes el campo amsiInitFailed via [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') y lo pones en true, y PowerShell salta el escaneo. El patch de memoria mas robusto resuelve la direccion de AmsiScanBuffer con GetProcAddress(LoadLibrary("amsi.dll"), "AmsiScanBuffer"), llama a VirtualProtect con PAGE_EXECUTE_READWRITE, escribe los bytes del stub de retorno y restaura la proteccion. La variante con hardware breakpoints es mas elegante: no toca .text, sino que setea registros de debug (Dr0-Dr7) sobre AmsiScanBuffer via SetThreadContext y falsifica el valor de retorno en un manejador de excepciones. Como no modifica codigo, pasa integrity checks debiles que solo buscan bytes parcheados.
Importante para el analisis defensivo: el patch por reflection deja una traza muy caracteristica en ScriptBlockLogging (Event ID 4104) porque las cadenas AmsiUtils y amsiInitFailed se loguean antes de que AMSI quede desactivado. El patch de memoria, en cambio, es visible via NtProtectVirtualMemory sobre amsi.dll. Cada tecnica cambia sigilo por complejidad, y ninguna es invisible si miras en el lugar correcto.
Montaje de laboratorio para ver lo que el azul realmente captura
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 la variante con hardware breakpoints, 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 aislamiento es parte del ejercicio: sin domain join entre laboratorio y produccion, sin egress a internet que pueda exfiltrar los payloads probados, y snapshots antes de cada corrida para que la baseline sea reproducible. Mide siempre primero el estado nulo (que se loguea sin bypass) y despues el estado con bypass. La diferencia es tu oportunidad de deteccion.
Hardening real: lo que de verdad le cuesta al atacante
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 (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 priorizacion importa: WDAC/Constrained Language Mode y ScriptBlockLogging reenviado rinden mas por hora invertida que otra licencia de EDR. El objetivo no es hacer imposible el bypass (no se puede, en el mismo proceso) sino hacerlo caro, ruidoso y rastreable.
Deteccion: patrones concretos e IOCs
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. Agrega reglas de comportamiento: un proceso PowerShell que carga amsi.dll y poco despues asigna una region RWX es mas sospechoso que cualquier indicador aislado.
Errores comunes de ambos lados
Del lado azul, el error mas comun es confiar en AMSI 4104 sin asegurar el forwarding: si el atacante puede borrar logs locales, tu IOC desaparece. Un segundo error es buscar solo firmas de bytes del patch clasico y perder por completo la variante con hardware breakpoints. Del lado ofensivo (laboratorio), el error mas comun es probar bypasses contra activos de produccion o publicar PoCs sin contexto defensivo. Un tercero, muy pasado por alto: muchos asumen que un bypass de AMSI tambien desactiva ETW; no lo hace, son mecanismos separados y deben ser bypassed por separado y detectados por separado.
Checklist para blue teams
Corto y accionable: (1) habilita ScriptBlockLogging y Module Logging y reenvia fuera del host via WEF. (2) fuerza Constrained Language Mode via WDAC para usuarios estandar. (3) activa RunAsPPL y Credential Guard. (4) Sysmon 15 con config curada mas Event ID 10 sobre amsi.dll/ntdll.dll. (5) baseline por endpoint del volumen de eventos ETW-TI con alerta ante caidas. (6) busqueda 4104 de "amsiInitFailed"/"AmsiUtils". (7) documenta la deteccion con la regla Sigma, no con la captura de mimikatz. (8) valida cada control en un ciclo purple team contra bypasses reales, no en papel.
FAQ: Alcanza un EDR moderno contra el bypass de AMSI/ETW?
No, no solo. Un buen EDR dificulta y detecta bypasses via kernel callbacks y analisis de comportamiento, pero una vez que el atacante esta en el proceso puede manipular sensores de user-mode, y con BYOVD atacar componentes de kernel. El valor esta en defensa en profundidad: EDR mas ScriptBlockLogging reenviado mas WDAC mas telemetria fuera del host. Ningun producto unico cierra la brecha porque la brecha es arquitectonica, no de producto.
FAQ: Es legal investigar y publicar estos bypasses?
Reproducirlos en tu propio laboratorio aislado es investigacion defensiva legitima. Publicar exige cuidado etico. Un bypass de AMSI/ETW no es un 0day, pero publicar una PoC sin angulo defensivo ayuda sobre todo 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. Si tu trabajo toca a un cliente, alinea alcance por escrito; si toca infra propia, practica OPSEC para Investigadores de Seguridad: Modelo de Amenaza Personal.
Conclusion
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. El hilo conductor es siempre el mismo: el defensor que asume que su sensor de host puede ser manipulado, y por eso pone la deteccion fuera del host y basada en comportamiento, le gana a un bypass que apuesta a la comodidad del defensor.
