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 técnicas para evadir la detección de EDR. Entender estas técnicas no es opcional para un defensor: es imprescindible para evaluar las limitaciones de tu EDR y disenar capas de detección complementarias.

Este artículo analiza las técnicas de evasion más 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 detección 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	Creación 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	Tráfico 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 función como NtAllocateVirtualMemory o NtWriteVirtualMemory, el hook del EDR intercepta la llamada, inspecciona los parámetros, 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 están 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 técnicas de bypass.

Técnica 1: API Unhooking

Como funciona

API unhooking consiste en restaurar el código 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 sesión, o desde una sección de la imagen del kernel)
3. El atacante sobreescribe la sección .text de la ntdll.dll parcheada con la versión 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 sección .text sobre la versión en memoria. Es la variante más simple.

Unhook desde KnownDlls: usar la sección \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).

Detección 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

Técnica 2: Direct Syscalls

Como funciona

En lugar de llamar a las funciones de ntdll.dll (que están hookeadas), el atacante invoca directamente las system calls del kernel. Cada función de ntdll.dll es un wrapper fino que coloca el número de syscall en un registro y ejecuta la instrucción 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 función parcheada siempre dice que no hay amenaza.

Variantes

Patch de AmsiScanBuffer: sobreescribir los primeros bytes con un retorno exitoso. Es la técnica más conocida y documentada.

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

Manipulación 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.

Detección 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 técnicas 1-5 explotan el mismo problema fundamental: el EDR instala mecanismos de monitorización 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 solución: kernel

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

Mecanismo kernel	Protección	Bypasseable desde userland
Kernel callbacks (PsSetCreate...)	Creación 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)	Tráfico de red	No

El dilema del driver

Para operar en el kernel, el EDR necesita un driver. Los drivers son código 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 versión de Windows y cada actualización 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 decisión de arquitectura critica para los vendors de EDR.

Como probar tu EDR

Herramientas de testing

Herramienta	Propósito	Nivel
Atomic Red Team	Técnicas ATT&CK individuales	Básico
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 configuración actual
2. Atomic tests: ejecutar técnicas individuales con Atomic Red Team
3. Evasion básica: probar unhooking simple y AMSI bypass
4. Evasion avanzada: direct syscalls, ETW patching
5. Analizar gaps: documentar que técnicas 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 técnicas 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 tráfico C2 es más difícil 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 técnicas de bypass de EDR están 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 más efectivas: si un atacante necesita desactivar tu EDR, eso en si mismo es una alerta de alta prioridad.

Conclusion

Las técnicas de bypass de EDR no son secretas ni teoricas: se usan activamente en ataques reales y están 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 detección para intentos de bypass (T1562), y verificación periodica de la cobertura real del EDR en tu entorno.