Técnicas de evasión de EDR: unhooking, direct syscalls y AMSI (y cómo detectarlas)

Los EDR (Endpoint Detection and Response) son la pieza central de la defensa moderna en endpoints. Combinan agentes en cada equipo, telemetría en tiempo real, análisis de comportamiento y capacidad de respuesta automatizada. Pero no son infalibles: existen técnicas documentadas públicamente que permiten a un adversario reducir la visibilidad del EDR o evadir sus controles.

Esta lección explica esas técnicas de evasión a nivel conceptual — no como manual de ataque, sino como conocimiento imprescindible para el defensor. Cada técnica de evasión se presenta junto a su método de detección correspondiente, porque un blue teamer que no entiende los ataques que enfrenta no puede construir defensas eficaces. Es la décima lección de la Tanda 8.

El objetivo de esta lección es estrictamente defensivo. Conocer las técnicas de evasión permite diseñar detecciones más robustas, evaluar la postura de seguridad de un EDR y cerrar gaps antes de que un adversario real los explote. Toda práctica debe realizarse únicamente en entornos autorizados.

Qué es un EDR y cómo funciona#

Un EDR moderno opera en tres capas de visibilidad, cada una con mecanismos distintos:

User-mode hooks. El agente EDR inyecta su DLL en cada proceso y modifica las primeras instrucciones de funciones críticas dentro de ntdll.dll — la biblioteca que sirve de puente entre las aplicaciones de usuario y el kernel de Windows. Cuando un proceso invoca NtAllocateVirtualMemory o NtWriteVirtualMemory, el hook desvía la ejecución hacia el código del EDR, que inspecciona los argumentos, decide si la operación es sospechosa, y solo entonces la deja continuar o la bloquea.

Kernel callbacks. A nivel de kernel, el driver del EDR registra callbacks mediante APIs como PsSetCreateProcessNotifyRoutine (creación de procesos), PsSetCreateThreadNotifyRoutine (creación de threads) y ObRegisterCallbacks (operaciones sobre handles). Estos callbacks se ejecutan dentro del kernel, donde el código de usuario no puede manipularlos directamente. Además, los minifilter drivers interceptan operaciones de I/O sobre el sistema de archivos, lo que permite detectar patrones como el renombrado masivo típico del ransomware.

ETW (Event Tracing for Windows). Windows genera eventos de telemetría a través de providers ETW. El provider Microsoft-Windows-Threat-Intelligence (ETW-TI) opera a nivel de kernel y reporta operaciones como inyección de código en procesos remotos, modificación de memoria protegida y carga de drivers sin firma. Estos eventos son especialmente valiosos porque no dependen de hooks que el adversario pueda parchear desde user-mode.

Por qué el defensor necesita entender la evasión#

El principio es simple: si no sabes cómo te pueden cegar, no puedes proteger tu visibilidad. Un equipo de detection engineering que desconoce las técnicas de evasión comete errores como:

• Confiar exclusivamente en hooks de user-mode que un adversario puede desactivar.
• No monitorizar la integridad de los componentes del propio EDR.
• Asumir que la telemetría ETW siempre llega sin verificar que nadie la ha silenciado.
• Desconocer que un ataque puede ser invisible para una capa y perfectamente visible para otra.

Entender la evasión te permite diseñar detecciones en múltiples capas, de forma que la evasión de una no deje al adversario invisible. Este enfoque se llama defense in depth aplicado a detección.

Técnicas de evasión y su detección#

Las técnicas descritas a continuación están documentadas públicamente en investigaciones de seguridad, conferencias (DEF CON, Black Hat), y en el propio framework MITRE ATT&CK. Se explican a nivel conceptual para que el defensor entienda el mecanismo y pueda construir detecciones.

Unhooking de ntdll.dll#

Concepto. El EDR modifica las primeras instrucciones de funciones en ntdll.dll dentro del proceso. La evasión consiste en restaurar esas instrucciones a su estado original. El método más conocido lee una copia limpia de ntdll.dll directamente desde disco (C:\Windows\System32\ntdll.dll) y sobrescribe la sección .text de la copia en memoria con los bytes originales. Tras esta operación, las funciones de ntdll.dll ejecutan el código real del sistema operativo sin pasar por los hooks del EDR.

Detección. Un EDR puede verificar periódicamente que sus hooks siguen intactos comparando los bytes actuales de las funciones hookeadas con los bytes esperados. Si detecta que un hook fue removido, genera una alerta de alta prioridad. Además, la propia operación de leer ntdll.dll desde disco y mapearla genera eventos en el minifilter (lectura del archivo) y potencialmente en ETW (carga de sección de imagen), que son observables desde kernel. Algunos EDR modernos también monitorizan llamadas a NtMapViewOfSection con el archivo ntdll.dll como target.

Direct syscalls#

Concepto. En Windows, las funciones de ntdll.dll son wrappers que colocan un número de syscall en un registro y ejecutan la instrucción syscall para transferir control al kernel. Si un proceso conoce el número de syscall correcto, puede ejecutar la instrucción syscall directamente sin pasar por ntdll.dll, evitando los hooks del EDR. Proyectos de investigación pública como SysWhispers documentan los números de syscall de cada versión de Windows para facilitar este análisis.

Detección. Los hooks de user-mode no ven esta técnica, pero los kernel callbacks sí. El kernel no distingue si la syscall vino de ntdll.dll o de código arbitrario: el callback PsSetCreateProcessNotifyRoutine se ejecuta igual cuando se crea un proceso. Además, el provider ETW-TI reporta operaciones de inyección de memoria aunque la syscall se haya invocado directamente. Un indicador adicional es que la dirección de retorno de la syscall no apunta a ntdll.dll sino a una región de memoria inusual; algunos EDR inspeccionan el call stack para detectar este patrón.

AMSI bypass#

Concepto. AMSI (Antimalware Scan Interface) es una API de Windows que permite a engines antimalware escanear contenido de scripts antes de que se ejecuten. PowerShell, VBA, JScript, y .NET envían el contenido a AMSI antes de interpretarlo. La evasión consiste en modificar en memoria la función AmsiScanBuffer de amsi.dll dentro del proceso, de forma que siempre retorne un resultado limpio sin escanear realmente el contenido. Esto no modifica archivos en disco; solo afecta al proceso actual.

Detección. El acceso de escritura a la región de memoria de amsi.dll genera eventos de protección de memoria observables por el EDR. Una regla Sigma puede detectar patrones asociados a la manipulación de AMSI. Ejemplo conceptual:

title: Potential AMSI Bypass via Memory Patching
logsource:
    category: process_creation
    product: windows
detection:
    selection_powershell:
        ParentImage|endswith: '\powershell.exe'
    selection_indicators:
        CommandLine|contains:
            - 'AmsiScanBuffer'
            - 'amsiInitFailed'
            - 'AmsiUtils'
    condition: selection_powershell and selection_indicators
level: high
tags:
    - attack.defense_evasion
    - attack.t1562.001

Adicionalmente, el propio AMSI puede reportar que fue deshabilitado si el EDR verifica su estado antes y después de la carga de scripts. El provider ETW Microsoft-Windows-AMSI registra cada escaneo; si un proceso PowerShell deja de generar eventos AMSI, eso es una anomalía detectable.

ETW patching#

Concepto. ETW es la columna vertebral de la telemetría de Windows. La función EtwEventWrite en ntdll.dll es el punto de entrada que usan los providers ETW para enviar eventos. Si un proceso parchea esta función en memoria (por ejemplo, insertando una instrucción de retorno inmediato), los eventos de ese proceso dejan de generarse. Esto ciega tanto al EDR como a cualquier otra herramienta que dependa de ETW en user-mode.

Detección. La defensa más robusta contra el patching de ETW es usar ETW a nivel de kernel. El provider Microsoft-Windows-Threat-Intelligence (ETW-TI) es un provider protegido que opera en kernel-mode; parchearlo requiere un driver con firma, lo que está fuera del alcance de la mayoría de adversarios. Otra estrategia es implementar eventos canario: el EDR genera periódicamente eventos ETW de control desde sus propios procesos. Si esos eventos dejan de llegar, alguien parchó ETW. Un tercer enfoque es verificar la integridad de la función EtwEventWrite en memoria, de forma análoga a la verificación de hooks.

Defensas modernas de los EDR#

Los EDR han evolucionado para no depender exclusivamente de hooks de user-mode. Las defensas actuales incluyen:

ETW-TI (Threat Intelligence provider). Introducido en Windows 10, este provider ETW opera desde el kernel y es inaccesible desde user-mode. Reporta operaciones críticas como inyección de código remoto, modificación de memoria protegida, y carga de drivers. Un EDR que consume ETW-TI mantiene visibilidad incluso cuando sus hooks de user-mode han sido removidos.

Tamper protection. Los EDR modernos protegen sus propios procesos, servicios y drivers contra modificación. Windows Defender, por ejemplo, usa Protected Process Light (PPL) para evitar que otros procesos lean o modifiquen su memoria. Desactivar tamper protection requiere privilegios de kernel o acceso físico.

Cloud correlation. La telemetría de un endpoint se envía al backend cloud del EDR, donde se correlaciona con datos de millones de otros endpoints. Patrones que parecen benignos en un solo equipo pueden ser claramente maliciosos cuando se observan a escala. Un adversario puede silenciar la telemetría local, pero no puede eliminar los eventos que ya llegaron al cloud.

Kernel callbacks. Los callbacks registrados en el kernel son independientes de los hooks de user-mode. No importa si el proceso invocó una syscall directamente o si parcheó ntdll.dll: cuando el kernel ejecuta la operación, el callback se dispara. Esto hace que las técnicas puramente de user-mode sean insuficientes contra un EDR con driver de kernel.

Por qué la evasión solo de user-mode es insuficiente#

Un punto clave que el defensor debe entender: las cuatro técnicas descritas operan en user-mode. Modifican código en el espacio de memoria de un proceso, no en el kernel. Esto significa que:

• Los kernel callbacks se ejecutan independientemente de lo que pase en user-mode.
• ETW-TI reporta desde el kernel y no es parcheable sin driver firmado.
• El minifilter del EDR sigue interceptando I/O de archivos.
• La telemetría que ya llegó al cloud no se puede borrar retroactivamente.

Un adversario que solo opera en user-mode puede cegar los hooks del EDR en su proceso, pero deja rastro visible en kernel. Para evadir también esa capa, necesitaría cargar un driver malicioso en el kernel, lo que requiere una vulnerabilidad en un driver firmado (técnica conocida como Bring Your Own Vulnerable Driver, BYOVD, T1068) — un nivel de sofisticación significativamente mayor.

Cómo se detecta en la práctica#

El detection engineer debe construir detecciones en las capas que el adversario NO puede evadir fácilmente. Estrategia recomendada:

La regla de oro es: nunca dependas de una sola capa. Si tu única detección de inyección de proceso son los hooks de user-mode en NtWriteVirtualMemory, un unhooking te ciega completamente. Si además tienes un kernel callback en ObRegisterCallbacks que alerta sobre handles a procesos protegidos, la detección sobrevive.

Errores comunes al defenderse#

• Confiar solo en hooks de user-mode. Es la capa más fácil de evadir. Los hooks son necesarios pero no suficientes.
• No verificar integridad del propio EDR. Si el adversario desactiva el agente y nadie lo nota, toda la inversión en EDR es inútil. Implementar alertas de heartbeat.
• Ignorar ETW-TI. Muchos SOC no consumen los eventos de Threat Intelligence provider porque requieren un consumer protegido. Es telemetría de altísimo valor.
• No correlacionar con red. Un adversario puede evadir el EDR del endpoint pero el C2 traffic sigue visible para el IDS de red.
• Desconocer la arquitectura del propio EDR. Si no sabes si tu EDR tiene driver de kernel, qué callbacks registra, o si usa ETW-TI, no puedes evaluar tu postura real de seguridad.
• Bloquear sin alertar. Si el EDR bloquea una técnica pero no genera alerta, el SOC no se entera de que hay un adversario activo. Configurar alertas para todo bloqueo.

Ejemplo en laboratorio#

Los laboratorios de whoami-labs permiten practicar la mentalidad purple team con estos conceptos:

Paso 1: reconocer técnicas de evasión en orthrus#

El laboratorio orthrus presenta un entorno Active Directory donde la habilidad clave es Defender-Aware Living off the Land — el uso de herramientas legítimas del sistema para operar sin activar el antivirus. Conecta por WinRM o SSH al entorno y observa qué herramientas nativas están disponibles:

ssh usuario@IP_DEL_LAB

Desde la perspectiva del defensor, el ejercicio es: ¿qué telemetría debería haber capturado cada acción del atacante? ¿Qué reglas Sigma detectarían Kerberoasting, AS-REP Roasting y living-off-the-land?

Paso 2: evaluar evasión de filtros en cerberus#

El laboratorio cerberus entrena evasión avanzada de filtros y encadenamiento de exploits. Desde el lado defensivo, analiza: ¿qué capas de protección tiene? ¿Dónde falla la defensa? ¿Qué telemetría adicional habría detectado la cadena completa?

nmap -sV -p- IP_DEL_LAB

El objetivo no es explotar sino analizar: por cada técnica ofensiva que descubras, documenta qué detección la habría parado.

Qué puede lograr un atacante con evasión de EDR#

Preguntas frecuentes#

¿Los EDR gratuitos tienen las mismas defensas?#

No. Las implementaciones varían enormemente. Windows Defender (incluido con Windows) tiene driver de kernel, ETW-TI, tamper protection y cloud intelligence. EDR comerciales premium añaden custom kernel callbacks, threat hunting integrado y response automatizado. Evalúa las capacidades reales de tu EDR, no asumas.

¿Puedo detectar unhooking sin driver de kernel?#

Parcialmente. Puedes verificar la integridad de los hooks desde el propio proceso del agente EDR en user-mode, pero un adversario con suficiente sofisticación puede evadir también esa verificación. La defensa robusta requiere telemetría de kernel que no dependa de user-mode.

¿BYOVD invalida todas las defensas?#

BYOVD (Bring Your Own Vulnerable Driver) permite al adversario cargar un driver firmado pero vulnerable y usarlo para ejecutar código en kernel. Esto puede desactivar el driver del EDR. Las defensas incluyen: listas de bloqueo de drivers vulnerables (Microsoft Vulnerable Driver Blocklist), HVCI (Hypervisor-protected Code Integrity) que impide la carga de drivers no autorizados, y monitorización de carga de drivers con alertas. Es una técnica real usada por grupos avanzados, pero tiene contramedidas efectivas.

¿Cómo evalúo si mi EDR es vulnerable?#

Frameworks como MITRE ATT&CK Evaluations publican evaluaciones de EDR comerciales contra técnicas de adversarios reales. Internamente, un ejercicio purple team con herramientas como Atomic Red Team permite probar si las técnicas de evasión funcionan contra tu configuración específica. No confíes en la hoja de datos del fabricante; prueba.

¿Esta lección sirve como receta para atacar?#

No. Las técnicas se explican a nivel conceptual — la información equivalente está publicada en conferencias de seguridad, papers académicos, y en el propio MITRE ATT&CK. El valor de la lección está en la perspectiva defensiva: cada técnica se presenta con su detección correspondiente. Un defensor que no entiende los ataques que enfrenta es un defensor ciego.

Resumen#

• EDR moderno opera en tres capas: hooks user-mode, kernel callbacks y ETW. Entender las tres es obligatorio para el defensor.
• Unhooking y direct syscalls evaden hooks de user-mode, pero no evitan kernel callbacks ni ETW-TI.
• AMSI bypass deshabilita escaneo de scripts en el proceso afectado. Detectable vía integridad de memoria y ausencia de eventos AMSI.
• ETW patching silencia telemetría en user-mode. ETW-TI en kernel-mode no es afectado.
• Defense in depth aplicado a detección: no depender nunca de una sola capa. Si el adversario evade user-mode, la detección en kernel sobrevive.
• Purple team es la práctica ideal: el red team ejecuta técnicas de evasión y el blue team verifica sus detecciones en tiempo real.

Fuentes y lecturas recomendadas#

• MITRE ATT&CK T1562.001 — Impair Defenses: Disable or Modify Tools
• MITRE ATT&CK T1562.006 — Impair Defenses: Indicator Blocking
• MITRE ATT&CK Evaluations
• Elastic — Hunting for Suspicious Windows API Usage
• Microsoft — Antimalware Scan Interface (AMSI)
• Microsoft — Event Tracing for Windows (ETW)
• Microsoft — Vulnerable Driver Blocklist