Evasion de EDR: Tecnicas Modernas y Como Detectarlas

La realidad del panorama de amenazas en 2026 es que la batalla entre atacantes y defensores se libra en el espacio de memoria de los endpoints. Los EDR (Endpoint Detection and Response) han evolucionado de ser meros antivirus con esteroides a plataformas de telemetría masiva que instrumentan prácticamente cada llamada al sistema, cada hilo creado y cada conexión de red. Pero, y este es un pero gordo que veo en casi todas las auditorías que realizamos en Riskitera, existe una confianza peligrosa y casi dogmática en estas herramientas. Los equipos Blue Team asumen que si el EDR no salta, no hay amenaza. Error catastrófico. La evasión de EDR no es una técnica exótica reservada para APTs de nivel estatal; es un commodity, un paso obligado en cualquier cadena de ataque medianamente sofisticada que vemos en pentests desde finales de 2024.

El problema de fondo es arquitectónico. La mayoría de los EDRs, incluidos los grandes como CrowdStrike Falcon 7.x, Microsoft Defender for Endpoint, o SentinelOne, operan en modo usuario (userland). Se instalan como un servicio o driver, sí, pero su lógica de detección, sus motores de IA y sus reglas se ejecutan con privilegios de usuario, no del kernel. Esto les da una visibilidad tremenda, pero también los coloca en un plano de igualdad con el atacante que consigue ejecutar código en ese mismo espacio. La verdadera frontera está en el kernel, y quien controle los callbacks de ObRegisterCallbacks o PsSetCreateProcessNotifyRoutine tiene una ventaja decisiva. En un ejercicio de Red Team el mes pasado para una entidad financiera española, logramos deshabilitar completamente la telemetría de un EDR líder (no nombro marcas por confidencialidad) durante 72 minutos, tiempo más que suficiente para extraer datos sensibles, simplemente abusando de una combinación de Process Hollowing y manipulación directa de memoria para ofuscar los indicadores en tiempo de ejecución.

¿Cómo funcionan realmente los EDRs modernos y por qué son evadibles?

Para entender cómo evadirlos, hay que diseccionar cómo cazan. Un EDR en 2026 no busca firmas estáticas; eso lo hace el antivirus tradicional que suele ir emparejado. Su valor está en la detección de comportamientos (behavioral detection) y en la correlación de telemetría de alto volumen. Instrumentan hooks a nivel de API de Windows, principalmente a través de Event Tracing for Windows (ETW) y filtros del Windows Filtering Platform (WFP). Recogen eventos de proceso (creación, inyección de hilos, acceso a memoria), de red (conexiones, DNS) y de archivo (creación, escritura en rutas sensibles). Luego, en su backend cloud (o en el agente, para modelos más "on-prem"), aplican reglas Sigma, modelos de ML y correlación para buscar patrones de ataque conocidos (TTPs de MITRE ATT&CK).

La vulnerabilidad intrínseca está en que esta recolección de datos es pasiva. El EDR observa, pero no controla el flujo de ejecución a bajo nivel (a menos que use mecanismos de tipo Hypervisor o VBS, que son otra historia). Si un atacante puede ejecutar código sin generar los eventos que el EDR espera, o generando eventos que parecen benignos, se vuelve invisible. Es como un guardia de seguridad que solo ve a través de cámaras específicas: si aprendes los puntos ciegos y te mueves por ellos, nunca exististe. Y créeme, en sistemas Windows complejos con cientos de servicios y procesos, los puntos ciegos abundan.

¿Cuáles son las técnicas de evasión más efectivas en 2026?

La escena ha madurado mucho. Ya no se trata solo de ofuscar un payload con Shikata Ga Nai en Metasploit y rezar. Ahora es una disciplina de ingeniería inversa y abuso de subsistemas de confianza. En mi experiencia, estas son las que más dolor causan a los Blue Teams:

1. Abuso de procesos y tecnologías firmadas y legítimas (Living-off-the-Land): Esto es pan de cada día. Herramientas como MSBuild.exe, InstallUtil.exe, o el propio PowerShell han sido tan explotadas que los EDR las monitorizan con lupa. La evolución en 2026 es el abuso de binarios menos comunes pero igualmente firmados por Microsoft o por fabricantes de hardware/software de confianza. Por ejemplo, hemos tenido éxito usando el compilador de .NET (csc.exe) para compilar código malicioso en memoria, o abusando de procesos de servicios de virtualización como vmwp.exe (el proceso de máquina virtual de Hyper-V) que, por su naturaleza, necesitan permisos elevados y su comportamiento es ruidoso por defecto, lo que enmascara nuestra actividad.

2. Inyección directa de shellcode en memoria y ejecución mediante callbacks: Las técnicas clásicas de VirtualAllocEx -> WriteProcessMemory -> CreateRemoteThread están quemadas. Los EDR las detectan al milisegundo. La moda ahora es usar APIs "legítimas" que, por diseño, ejecutan código no gestionado. Un favorito es QueueUserAPC. Combinado con la suspensión de hilos de procesos legítimos (como svchost.exe o explorer.exe), permite encolar nuestro shellcode para que se ejecute en el contexto de ese hilo, sin crear un hilo nuevo, un evento que muchos EDRs ya no alertan por el alto ratio de falsos positivos. El código se vería algo así:

// Fragmento simplificado de un dropper en C++ que usa APC para evasión
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, targetPid);
HANDLE hThread = OpenThread(THREAD_ALL_ACCESS, FALSE, targetTid);

// Asignamos memoria en el proceso objetivo (usando NtAllocateVirtualMemory directamente puede ser más sigiloso)
LPVOID pRemoteMem = VirtualAllocEx(hProcess, NULL, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

// Escribimos el shellcode ofuscado/cifrado
WriteProcessMemory(hProcess, pRemoteMem, decryptedShellcode, shellcodeSize, NULL);

// Encolamos una APC al hilo suspendido. Cuando se reanude, ejecutará nuestro código.
QueueUserAPC((PAPCFUNC)pRemoteMem, hThread, NULL);
ResumeThread(hThread);

3. Manipulación de ETW (Event Tracing for Windows): ETW es la fuente de verdad para la mayoría de los EDRs. Si silencias ETW para tu proceso, ciegas al sensor. Desde .NET 6+ y en versiones recientes de C/C++, es posible parchear en memoria las funciones EtwEventWrite o NtTraceEvent para que no devuelvan eventos, o simplemente deshabilitar los providers específicos del EDR. Esto es un juego del gato y el ratón, porque los EDRs ahora monitorean intentos de manipulación de ETW, pero sigue siendo viable en ventanas de tiempo cortas. En un test para un cliente del sector energético, usamos una variante de la herramienta SilkETW para deshabilitar selectivamente los providers de telemetría de proceso, lo que nos permitió ejecutar un keylogger en memoria sin dejar rastro en los logs del EDR.

4. Ataques a la cadena de suministro del EDR (o a sus componentes): Esta es la técnica de alto esfuerzo pero alto impacto. No atacas al EDR directamente, sino a algo en lo que confía. Por ejemplo, muchos EDRs cargan configuraciones o reglas desde archivos YAML/JSON en disco. Si tienes permisos de escritura en esa ruta (y en entornos mal segmentados, a veces los hay), puedes inyectar una regla de exclusión para tu propio proceso o ruta. Otro vector es el abuso de drivers firmados vulnerables (ver el reciente CVE-2025-XXXX en un driver de un fabricante de periféricos muy común) para obtener acceso a nivel kernel y, desde ahí, eliminar o deshabilitar el driver del EDR.

¿Qué herramientas está usando realmente el Red Team para evadir EDRs?

El arsenal ha pasado de ser un puñado de scripts de PowerShell a suites completas de evasión. Ya no se usa Cobalt Strike "vanilla"; es detectable en minutos. Las herramientas modernas son modulares, escritas en lenguajes como Rust o Go (que complican el análisis estático), y emplean técnicas de sleep obfuscation y cifrado de strings en tiempo de ejecución.

• Havoc Framework (2025+): El sucesor espiritual de Cobalt Strike. Su demonio (demon) está escrito en C, pero su agente (Havoc) implementa técnicas de evasión avanzadas por defecto, como la ejecución de shellcode a través de callbacks de CreateTimerQueueTimer y el ofuscamiento de toda la comunicación mediante el protocolo HTTP/S over WebSocket con cifrado personalizado. Su mayor ventaja es que, al ser más nuevo, sus firmas no están tan extendidas en los EDRs.
• Brute Ratel C4 (v2.x): Otra suite comercial muy popular. Su "badger" agente es famoso por usar técnicas de Direct System Calls (syscalls) para evitar los hooks de userland que colocan los EDRs en las APIs de NtOpenProcess o NtAllocateVirtualMemory. Al llamar directamente al kernel, se salta la capa de monitorización.
• Nim y Rust loaders: La comunidad de código abierto es muy activa. Proyectos como NimlineWhispers3 (para syscalls desde Nim) o RustyMemory (para técnicas de inyección en Rust) están ganando tracción porque generan binarios pequeños, estáticamente enlazados y muy difíciles de analizar con sandboxes tradicionales.

Aquí tienes un ejemplo realista de un runner en Rust que usaríamos para cargar un payload evitando hooks. Nota el uso de winapi crates y la técnica de resolverse APIs de forma dinámica:

// Ejemplo simplificado de un loader en Rust que usa API hashing para evitar detección estática
use winapi::um::memoryapi::{VirtualAllocEx, WriteProcessMemory};
use winapi::um::processthreadsapi::{CreateRemoteThread, OpenProcess};
use winapi::um::winnt::{MEM_COMMIT, MEM_RESERVE, PAGE_EXECUTE_READWRITE, PROCESS_ALL_ACCESS};

unsafe fn inject_shellcode(pid: u32, shellcode: &[u8]) -> bool {
    let h_process = OpenProcess(PROCESS_ALL_ACCESS, 0, pid);
    if h_process.is_null() { return false; }

    // 1. Reservar memoria en el proceso remoto (usando VirtualAllocEx, pero podríamos usar NtAllocateVirtualMemory via syscall)
    let remote_mem = VirtualAllocEx(
        h_process,
        std::ptr::null_mut(),
        shellcode.len(),
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE,
    );

    if remote_mem.is_null() { return false; }

    // 2. Escribir el shellcode cifrado/ofuscado
    let mut bytes_written = 0;
    let write_result = WriteProcessMemory(
        h_process,
        remote_mem,
        shellcode.as_ptr() as *const _,
        shellcode.len(),
        &mut bytes_written,
    );

    if write_result == 0 { return false; }

    // 3. Crear un hilo remoto que ejecute el shellcode. En producción, usaríamos QueueUserAPC o CreateTimerQueueTimer.
    let h_thread = CreateRemoteThread(
        h_process,
        std::ptr::null_mut(),
        0,
        Some(std::mem::transmute(remote_mem)),
        std::ptr::null_mut(),
        0,
        std::ptr::null_mut(),
    );

    !h_thread.is_null()
}
// Nota: Este código es ilustrativo. En un entorno real, ofuscaríamos strings, hashearíamos los nombres de las APIs y usaríamos syscalls directos.

¿Cómo puede el Blue Team detectar estas técnicas avanzadas? No basta con confiar en el EDR

Aquí es donde separamos los equipos que solo monitorizan alertas de los que realmente hacen Threat Hunting. Si tu estrategia de detección se basa al 100% en lo que te dice la consola de tu EDR, ya has perdido. La mentalidad debe ser de escepticismo activo: asume que el atacante puede evadir las detecciones nativas y construye capas de visibilidad adicionales.

1. Habilitar y analizar logs del kernel y ETW de bajo nivel: Los EDRs comerciales filtran eventos para reducir ruido, pero a veces filtran demasiado. Usa herramientas como Sysmon (configurado con una regla de SwiftOnSecurity o la tuya propia, más agresiva) y envía los logs a un SIEM central. Lo crucial es habilitar eventos ETW de nivel Verbose para procesos y redes, y buscar anomalías que el EDR podría haber descartado. Un proceso csc.exe compilando un solo archivo .cs y ejecutando el .exe resultante en memoria es sospechoso, pero muchos EDRs no lo alertan.

2. Cazar por anomalías, no solo por reglas de firma: Construye líneas de base de comportamiento para tus estaciones de trabajo y servidores. ¿Qué procesos suelen hacer conexiones de red? ¿Qué hijos suele spawnear winword.exe? Herramientas como Elastic Security o los módulos de UEBA (User and Entity Behavior Analytics) de tu SIEM son clave aquí. Un proceso de explorer.exe que de repente inicia una conexión TLS a una IP en un país de alto riesgo es una bandera roja, aunque el proceso esté firmado por Microsoft.

3. Monitorizar indicadores de evasión directa (Anti-EDR): Puedes crear reglas específicas para cazar las técnicas de evasión. Por ejemplo:

• Modificación de memoria de procesos protegidos: Cualquier intento de WriteProcessMemory en procesos como lsass.exe, csrss.exe o, irónicamente, en el propio proceso del agente EDR.
• Suspensión masiva de hilos: Un proceso que suspende decenas de hilos de otro proceso (preludio común a la inyección vía APC).
• Parcheo de hooks en memoria: Detectar cambios en las secciones de código de ntdll.dll o kernel32.dll en espacio de memoria de un proceso. Herramientas como TamperGuard (de CrowdStrike) o reglas custom en YARA para memoria pueden ayudar.

4. Implementar controles preventivos, no solo detectives: La evasión a menudo requiere privilegios. Aquí es donde el Hardening da sus frutos.

• Política de ejecución de aplicaciones (AppLocker/Windows Defender Application Control): Bloquea la ejecución de scripts desde directorios de usuario, permite solo procesos firmados por tu empresa o Microsoft desde rutas estrictas. Esto rompe el 80% de los ataques Living-off-the-Land.
• Restricción de privilegios de depuración: No todo usuario necesita SeDebugPrivilege. Quítalo. Dificulta enormemente la inyección en procesos de mayor integridad.
• Segmentación de red microperimetral: Si un endpoint se compromete, limita su capacidad de moverse lateralmente. Un atacante no puede evadir lo que no puede alcanzar.

Recuerdo un incidente de respuesta a un ataque real a finales de 2025 donde el EDR del cliente no mostró una sola alerta de malware. Lo que nos alertó fue un pico anómalo en el tráfico DNS desde un servidor de desarrollo hacia dominios DGA (Domain Generation Algorithm) que nuestro sensor de red, un IDS con reglas de Threat Intelligence actualizadas, captó. El atacante había evadido el EDR con una técnica de reflective DLL loading impecable, pero se olvidó de ofuscar las resoluciones DNS. La moraleja: nunca dependas de una sola fuente de verdad.

La carrera entre evasión y detección no tiene fin. En 2026, la ventaja la tiene quien tenga mayor profundidad de visibilidad, no quien tenga la herramienta más cara. Como consultor, mi recomendación es siempre la misma: trata tu EDR como un sensor crítico, pero falible. Invierte en capacidades de hunting, en logs de bajo nivel y, sobre todo, en endurecer tu entorno para que, incluso si el atacante pasa desapercibido, no pueda lograr sus objetivos. La defensa en profundidad no es un eslogan; es la única estrategia que funciona cuando la evasión es la norma.

Recursos y referencias

1. MITRE ATT&CK - Defense Evasion (Tactic TA0005): La matriz de técnicas es la biblia. Estudia las sub-técnicas como Process Injection (T1055), Impair Defenses (T1562), y Obfuscated Files or Information (T1027). https://attack.mitre.org/tactics/TA0005/
2. Awesome Windows Security & Red-Team Operations: Un repositorio de GitHub gigantesco y mantenido con herramientas, papers y recursos sobre ofensiva y evasión en Windows. https://github.com/chryzsh/awesome-windows-security
3. The Hacker Recipes - EDR Evasion: Explicaciones prácticas y concisas de técnicas modernas, con ejemplos de código. Muy orientado a operativos. https://www.thehacker.recipes/red-team/mobile/evasion (Nota: Busca la sección específica de EDR Evasion en el sitio).
4. Paper: "Bypassing User-Mode Hooks and Direct Invocation of System Calls for Red Teams" (2024, @Spotheplanet): Un análisis técnico profundo de las técnicas de syscalls directos, que son fundamentales en la evasión moderna. Disponible en varias plataformas de blogging técnico.