EDR Bypass: Técnicas de Evasión y Cómo Mejorar la Detección

La carrera armamentistica

Los EDR son la principal linea de defensa en endpoints modernos. Pero no son infalibles. Existe una comunidad activa de investigadores (tanto ofensivos como defensivos) que desarrolla tecnicas para evadir la deteccion de EDR. Entender estas tecnicas no es opcional para un defensor: es imprescindible para evaluar las limitaciones de tu EDR y disenar capas de deteccion complementarias.

Este articulo analiza las tecnicas de evasion mas relevantes desde la perspectiva defensiva: como funcionan, por que funcionan, y que puede hacer un equipo de seguridad para detectarlas o mitigar su impacto.

Como funciona la deteccion de un EDR

Para entender el bypass, primero hay que entender que monitoriza un EDR y como lo hace.

Fuentes de telemetria

Un EDR moderno combina multiples fuentes:

Fuente	Nivel	Que captura
API Hooks (userland)	Ring 3	Llamadas a APIs de Windows (ntdll, kernel32)
ETW (Event Tracing for Windows)	Ring 3/Kernel	Eventos del sistema (procesos, red, archivos)
Kernel Callbacks	Ring 0	Creacion de procesos, carga de drivers, operaciones de registro
Minifilters	Ring 0	Operaciones del sistema de archivos
AMSI	Ring 3	Contenido de scripts (PowerShell, VBScript, JScript)
Network filters	Ring 0 / NDIS	Trafico de red del endpoint

Userland hooks: el talon de Aquiles

La mayoria de EDR instalan hooks (desvios) en las funciones de ntdll.dll, la DLL de bajo nivel que sirve como puerta de entrada al kernel de Windows. Cuando un proceso llama a una funcion como NtAllocateVirtualMemory o NtWriteVirtualMemory, el hook del EDR intercepta la llamada, inspecciona los parametros, y decide si permitirla o bloquearla.

El problema fundamental: ntdll.dll se carga en el espacio de memoria del proceso (Ring 3, userland). Esto significa que el proceso que se esta monitorizando tiene acceso de lectura y escritura a la memoria donde estan los hooks. Un proceso con los privilegios adecuados puede modificar o eliminar los hooks del EDR.

Esta limitacion arquitectonica es la raiz de la mayoria de las tecnicas de bypass.

Tecnica 1: API Unhooking

Como funciona

API unhooking consiste en restaurar el codigo original de ntdll.dll, eliminando los hooks del EDR. El concepto es simple:

1. El EDR parchea funciones de ntdll.dll en memoria para interceptar llamadas
2. El atacante obtiene una copia limpia de ntdll.dll (desde disco, desde otra sesion, o desde una seccion de la imagen del kernel)
3. El atacante sobreescribe la seccion .text de la ntdll.dll parcheada con la version limpia
4. Las llamadas a la API ya no pasan por el EDR

Variantes

Unhook desde disco: leer ntdll.dll desde C:\Windows\System32\ntdll.dll y copiar la seccion .text sobre la version en memoria. Es la variante mas simple.

Unhook desde KnownDlls: usar la seccion \KnownDlls\ntdll.dll del Object Manager de Windows, que contiene una copia mapeada de la DLL.

Unhook desde un proceso suspendido: crear un nuevo proceso en estado suspendido, leer su ntdll.dll (que aun no ha sido parcheada por el EDR), y usarla para restaurar la propia.

Unhook selectivo: en lugar de restaurar toda la DLL, restaurar solo las funciones especificas que se necesitan (NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThreadEx).

Deteccion defensiva

• Monitorizar lecturas de ntdll.dll desde disco: un proceso que lee ntdll.dll del disco es sospechoso (los procesos normales no necesitan hacerlo)
• Verificar integridad de hooks: el EDR puede verificar periodicamente que sus hooks siguen intactos
• Detectar llamadas a NtMapViewOfSection sobre ntdll.dll: mapear ntdll.dll desde KnownDlls es un indicador de unhooking
• No depender exclusivamente de userland hooks: usar ETW y kernel callbacks como fuentes complementarias

Tecnica 2: Direct Syscalls

Como funciona

En lugar de llamar a las funciones de ntdll.dll (que estan hookeadas), el atacante invoca directamente las system calls del kernel. Cada funcion de ntdll.dll es un wrapper fino que coloca el numero de syscall en un registro y ejecuta la instruccion syscall. El atacante puede replicar este comportamiento sin pasar por ntdll.dll.

El flujo normal:

Proceso → ntdll!NtAllocateVirtualMemory (hookeado) → EDR inspecciona → syscall → Kernel

Con direct syscalls:

Proceso → syscall directo (numero de syscall hardcodeado) → Kernel

El EDR nunca ve la llamada porque el codigo nunca pasa por ntdll.dll.

Variantes

Syscall numbers hardcodeados: incluir los numeros de syscall directamente en el codigo. Problema: los numeros cambian entre versiones de Windows.

Syscall number resolution dinamica: leer ntdll.dll en memoria para extraer los numeros de syscall en tiempo de ejecucion. Funciona en cualquier version de Windows.

Indirect syscalls: en lugar de ejecutar la instruccion syscall desde el codigo del atacante (que seria sospechoso por la ubicacion de memoria), saltar a la instruccion syscall dentro de ntdll.dll. Esto evita la deteccion basada en la ubicacion de la instruccion syscall.

Hell's Gate, Halo's Gate, Tartarus Gate: frameworks publicos que implementan resolucion dinamica de syscalls con diferentes estrategias para encontrar los numeros incluso cuando ntdll.dll esta parcheada.

Deteccion defensiva

• Stack trace analysis: cuando una syscall legitima se ejecuta, el call stack incluye ntdll.dll. Si el call stack no pasa por ntdll.dll, es un indicador fuerte de direct syscall
• Kernel callbacks: las callbacks de creacion de procesos y threads (PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine) se ejecutan en el kernel, independientemente de como se invoco la syscall
• ETW Microsoft-Windows-Threat-Intelligence: proveedor de ETW que genera eventos desde el kernel, no bypasseable desde userland
• Deteccion de unbacked memory execution: si la instruccion syscall se ejecuta desde memoria que no esta respaldada por un archivo en disco (memory-mapped), es altamente sospechoso

Tecnica 3: PPID Spoofing

Como funciona

Los EDR usan la relacion padre-hijo entre procesos para detectar anomalias. Por ejemplo, si cmd.exe es hijo de winword.exe, eso es sospechoso (indica ejecucion de comandos desde un documento Office).

PPID spoofing permite crear un proceso con un Parent Process ID falso. El atacante puede hacer que un proceso malicioso parezca hijo de explorer.exe o svchost.exe, ocultando la cadena de ejecucion real.

La tecnica usa la API CreateProcess con el atributo PROC_THREAD_ATTRIBUTE_PARENT_PROCESS para especificar un proceso padre diferente del real.

Impacto

• Rompe las reglas de deteccion basadas en relaciones padre-hijo
• Oculta la cadena de ejecucion del ataque
• Puede evadir herramientas de analisis que confian en el arbol de procesos

Deteccion defensiva

• ETW Process Creation events: el proveedor Microsoft-Windows-Kernel-Process registra tanto el PID del proceso real que llamo a CreateProcess como el ParentProcessId declarado. Si difieren, es PPID spoofing
• Verificar el handle al proceso padre: el proceso que hace el spoofing necesita un handle al proceso "padre" falso. Detectar handles abiertos a procesos criticos del sistema (explorer.exe, svchost.exe) desde procesos inusuales
• Correlacion temporal: el "hijo" se crea despues de que el "padre" ya estuviera en ejecucion, pero el handle al padre se abrio desde un tercer proceso. Esta triangulacion revela el spoofing

Tecnica 4: ETW Patching

Como funciona

Event Tracing for Windows (ETW) es una fuente critica de telemetria para los EDR. Muchos EDR consumen eventos de proveedores ETW como:

• Microsoft-Windows-Kernel-Process
• Microsoft-Windows-Kernel-File
• Microsoft-Windows-DNS-Client
• Microsoft-Windows-DotNETRuntime (carga de assemblies .NET)
• Microsoft-Windows-Threat-Intelligence (operaciones sensibles)

El ataque consiste en parchear en memoria la funcion EtwEventWrite (o NtTraceEvent) de ntdll.dll para que retorne inmediatamente sin generar eventos. Esto silencia la telemetria ETW desde el proceso del atacante.

Variantes

Patch de EtwEventWrite: sobreescribir los primeros bytes de la funcion con un ret (instruccion de retorno). Todas las llamadas a ETW desde ese proceso retornan sin hacer nada.

Patch selectivo por proveedor: en lugar de silenciar todo ETW, desactivar solo los proveedores que usa el EDR.

Patch de NtTraceEvent: parchear la funcion de nivel mas bajo en ntdll.dll. Mas sigiloso porque no toca la funcion de nivel alto.

Deteccion defensiva

• Verificar integridad de EtwEventWrite: el EDR puede verificar periodicamente que la funcion no ha sido parcheada
• Kernel-level ETW consumers: algunos proveedores ETW generan eventos desde el kernel, donde el proceso no puede parchearlos
• Microsoft-Windows-Threat-Intelligence: este proveedor requiere privilegios PPL (Protected Process Light) y no puede ser parcheado desde userland
• Detectar la ausencia de eventos: si un proceso esta activo pero no genera ningun evento ETW, eso mismo es anomalo

Tecnica 5: AMSI Bypass

Como funciona

AMSI (Antimalware Scan Interface) es la interfaz de Windows que permite a los motores antimalware inspeccionar el contenido de scripts antes de su ejecucion. PowerShell, VBScript, JScript y macros de Office envian su contenido a AMSI para inspeccion.

El bypass mas comun parchea la funcion AmsiScanBuffer en amsi.dll para que siempre retorne "limpio" (AMSI_RESULT_CLEAN). Despues del patch, PowerShell (por ejemplo) sigue enviando contenido a AMSI, pero la funcion parcheada siempre dice que no hay amenaza.

Variantes

Patch de AmsiScanBuffer: sobreescribir los primeros bytes con un retorno exitoso. Es la tecnica mas conocida y documentada.

Forzar error de inicializacion: provocar que AMSI falle al inicializarse, lo que hace que PowerShell continue sin inspeccion.

Manipulacion de AmsiContext: corromper la estructura amsiContext para que las llamadas posteriores fallen.

Reflection-based: usar .NET reflection para modificar campos internos del motor AMSI sin parchear memoria.

Deteccion defensiva

• Monitorizar acceso a amsi.dll en memoria: las operaciones WriteProcessMemory sobre amsi.dll son altamente sospechosas
• ETW proveedor de AMSI: Microsoft-Windows-AMSI genera eventos cuando AMSI es invocado. Si un proceso de PowerShell no genera eventos AMSI, algo va mal
• Script Block Logging: registra el contenido completo de los scripts PowerShell en Event Log (Event ID 4104), independiente de AMSI
• Constrained Language Mode: PowerShell en modo restringido limita las operaciones que pueden usarse para bypass

Userland vs Kernel: la batalla arquitectonica

El problema fundamental

Las tecnicas 1-5 explotan el mismo problema fundamental: el EDR instala mecanismos de monitorizacion en el espacio de memoria del proceso que esta monitorizando (userland, Ring 3). El proceso tiene los mismos privilegios de acceso a esa memoria que el EDR. Es como poner una camara de seguridad dentro de la celda del prisionero: si el prisionero puede alcanzarla, puede taparla.

La solucion: kernel

Los mecanismos de deteccion en el kernel (Ring 0) no son accesibles desde userland:

Mecanismo kernel	Proteccion	Bypasseable desde userland
Kernel callbacks (PsSetCreate...)	Creacion de procesos/threads	No
Minifilters (FltRegister...)	Operaciones de archivos	No
Object callbacks (ObRegister...)	Acceso a handles de procesos	No
ETW Threat Intelligence	Operaciones sensibles (proceso, memoria)	No (requiere PPL)
WFP (Windows Filtering Platform)	Trafico de red	No

El dilema del driver

Para operar en el kernel, el EDR necesita un driver. Los drivers son codigo en Ring 0, con acceso total al sistema. Esto implica:

• Estabilidad: un bug en el driver causa BSOD (pantalla azul). El incidente de CrowdStrike en julio de 2024 lo demostro de forma catastrofica
• Compatibilidad: los drivers deben ser compatibles con cada version de Windows y cada actualizacion del kernel
• Firma: Microsoft requiere firma WHQL para drivers de kernel en Windows 10+ con Secure Boot
• Rendimiento: operaciones en el kernel tienen mayor impacto en rendimiento

El equilibrio entre userland hooks (bypasseables pero seguros) y kernel drivers (robustos pero arriesgados) es una decision de arquitectura critica para los vendors de EDR.

Como probar tu EDR

Herramientas de testing

Herramienta	Proposito	Nivel
Atomic Red Team	Tecnicas ATT&CK individuales	Basico
MITRE Caldera	Adversary emulation automatizada	Intermedio
Sliver / Havoc	C2 framework open source	Avanzado
ScareCrow	Loader con unhooking y syscalls	Avanzado
SharpBlock	Bypass de EDR para .NET	Avanzado
TelemetrySourcerer	Verificar fuentes de telemetria del EDR	Avanzado

Proceso de testing defensivo

1. Baseline: documentar que detecta el EDR con su configuracion actual
2. Atomic tests: ejecutar tecnicas individuales con Atomic Red Team
3. Evasion basica: probar unhooking simple y AMSI bypass
4. Evasion avanzada: direct syscalls, ETW patching
5. Analizar gaps: documentar que tecnicas pasaron desapercibidas
6. Mitigar: implementar detecciones complementarias (Sysmon, YARA, reglas SIEM)
7. Reportar al vendor: compartir los gaps con el vendor para que mejore el producto
8. Repetir: este ciclo debe ser continuo, no puntual

Detecciones complementarias

Para los gaps que el EDR no cubre, considerar:

• Sysmon: genera telemetria adicional que puede detectar tecnicas que el EDR no ve
• Script Block Logging: PowerShell Event ID 4104 registra contenido de scripts independientemente de AMSI
• YARA rules en memoria: escanear memoria de procesos con firmas de herramientas de bypass
• Network detection: el trafico C2 es mas dificil de ocultar que la actividad en el endpoint
• Behavioral analytics en SIEM: correlacionar eventos de multiples fuentes para detectar patrones que un EDR individual no ve

Perspectiva: T1562 (Impair Defenses)

Las tecnicas de bypass de EDR estan catalogadas en MITRE ATT&CK bajo T1562 (Impair Defenses):

• T1562.001: Disable or Modify Tools (unhooking, AMSI bypass)
• T1562.002: Disable Windows Event Logging
• T1562.006: Indicator Blocking (ETW patching)

Monitorizar estos IDs en tu SIEM y crear alertas especificas para intentos de desactivar defensas es una de las medidas mas efectivas: si un atacante necesita desactivar tu EDR, eso en si mismo es una alerta de alta prioridad.

Conclusion

Las tecnicas de bypass de EDR no son secretas ni teoricas: se usan activamente en ataques reales y estan documentadas en herramientas open source. Un equipo de seguridad que no las conoce esta operando a ciegas sobre las limitaciones de su principal herramienta de defensa.

La respuesta no es panico ni desconfianza en los EDR. La respuesta es defense in depth: asumir que el EDR puede ser evadido y complementar con telemetria adicional (Sysmon, ETW, logs de red), reglas de deteccion para intentos de bypass (T1562), y verificacion periodica de la cobertura real del EDR en tu entorno.