Evasión de EDR sin malware: el tradecraft que tu EDR considera normal

Imagina comprometer el directorio activo de una organización sin ejecutar un solo binario sospechoso: sin loader que parchee el AMSI, sin dropper que cargue shellcode en memoria. No es ciencia ficción. Es lo que defiende Jeremy Erazo, red teamer ecuatoriano del equipo Red Spear Labs (Devel Group), en su charla "EDR Evasion Without Malware: Tradecraft No Convencional" de la DragonJAR Security Conference 2026.

La evasión de EDR sin malware que propone parte de una premisa incómoda para los defensores: el atacante no evade el EDR con código malicioso, evade el EDR operando dentro de los comportamientos que la propia organización considera normales. Java y su JVM, el binario mshta.exe firmado por Microsoft, las herramientas forenses de análisis de memoria y hasta la inteligencia artificial generativa se convierten en mecanismos de acceso remoto, persistencia y movimiento lateral sin generar alertas relevantes en EDRs y XDR actuales.

Por qué la evasión de EDR se complicó de más

Jeremy abre con una provocación: la mayoría de certificaciones enseñan evasión de EDR como un examen de bajo nivel de Windows. Process Hollowing, syscalls manuales, polimorfismo binario. Todo eso funciona, sí. Pero deja huella: los binarios grandes generan mucha trazabilidad para la recolección de eventos nativa de Windows, y un EDR maduro termina correlacionando la cadena completa.

El punto clave: en una simulación de adversarios, comprometer el directorio activo no es el objetivo principal. El objetivo principal es que el SOC no se entere. Si lo comprometiste pero generaste mil alertas, no es un buen hallazgo. Por eso, dice, el camino creativo suele rendir más que el camino técnico, y ese camino se llama abuso de entornos de confianza.

Qué es un EDR (y por qué no es inteligencia artificial)

La charla desarma un mito muy común. El EDR es la evolución del antivirus: un agente en el endpoint que implementa un conjunto de reglas muy específicas. La narrativa del mercado habla de inteligencia artificial; en la práctica, recuerda Jeremy, eso no es IA por ningún lado: son reglas. Para comprobarlo recomienda el trabajo de Saad Hala, creador de la certificación de reversing de agentes EDR de Altered Security: al leer el reversing completo de un agente se descubre que el EDR es un SOC empaquetado en un binario con reglas, nada más.

La consecuencia operativa es clara: cualquier técnica que no coincida con una regla existente pasa. El truco del atacante no es romper la regla; es evitarla.

Los tres retos de la evasión de EDR

Antes de las soluciones, Jeremy clasifica lo que el EDR vigila:

• Comportamiento estático: todo lo que un archivo expone sin ejecutarse: cabeceras PE, hashes, metadatos, imports. Se bypasea cifrando cabeceras, ofuscando con XOR o AES y cargando en memoria.
• Comportamiento dinámico: lo que el binario hace en ejecución: conexiones salientes, procesos hijos, cambios de permisos. Aquí la evasión pasa por elegir entornos que el EDR ya considera benignos.
• Correlación de eventos (telemetría): secuencias de pasos que el EDR detecta como cadena. CrowdStrike y algunos otros productos correlacionan TTPs completas. Romper la correlación es tan simple como desordenarla o apoyarse en herramientas ya blanqueadas.

El adagio del atacante con presupuesto (y el del que no)

Jeremy lo dice sin filtro: la persona que tiene plata hace lo que sea. Existen productos comerciales como valiskit que, por alrededor de mil dólares, funcionan como builder: metes un binario y sale indetectable. Subes un Rubeus y obtienes un Rubeus que el EDR no marca. Interesante para un estudio, dice, pero está del lado equivocado: los Red Teams sin presupuesto no pueden comprar evasión, tienen que ser creativos. Y esa creatividad es donde vive la verdadera tradecraft.

Java y la JVM: evasión con un entorno de confianza

Java es una de las fuentes más interesantes para evasión de EDR. La razón es simple: la JVM es un proceso confiable, con permisos para acceder a cámara, pantalla y drivers, y muy presente en Windows. Lo que el EDR ve no es tu binario ejecutándose: es Java ejecutando algo. Para Windows, eso es totalmente normal.

Cómo ejecuta Java un programa (y por qué importa)

Una aplicación nativa de Windows pasa por un loader con sus estructuras PE y su código nativo, y el EDR puede leer cada paso. La historia con Java es diferente: el código fuente se compila con javac en bytecode (un archivo .class), y de ahí la cadena continúa así:

1. Class Loader: importa las dependencias necesarias para la ejecución.
2. Bytecode Verification: revisa que las estructuras estén correctas.
3. Interpreter: ejecuta el bytecode instrucción por instrucción.
4. JIT Compiler: para tareas repetitivas, traduce a código nativo en memoria.
5. El resultado sale a Windows como código nativo. Pero lo hizo Java, no tu binario.

El detalle ofensivo: en muchos entornos la JVM corre con permisos altos, y el EDR no marca la cadena porque técnicamente no es tu binario ejecutándose.

Demo: un Command & Control en Java sin ofuscación

En la demo, Jeremy muestra un C2 escrito en Java "full ChatGPT", sin una sola línea ofuscada, sin packers, sin cifrado de cabeceras. La única separación operativa es que la IP y el puerto del listener viven en un archivo de configuración aparte. El implante se conecta y ejecuta patrones muy específicos; en una segunda etapa, enumera drivers, identifica máquinas virtuales, revisa la papelera y hace capturas de pantalla, devolviendo los resultados al servidor.

El C2 es público y modificable. Jeremy lo probó contra Palo Alto en su laboratorio: pasa. Y funciona, dice, contra CrowdStrike y otros EDRs más fuertes, porque la cadena entera corre bajo la firma de la JVM.

Archivos HTA y mshta.exe: el loader firmado por Microsoft

El segundo caso arranca con una pregunta al público: ¿cuántos saben hacer una página web con HTML y CSS? Casi todos. Pues con eso se evade un EDR. Los archivos HTA (HTML Application) son aplicaciones HTML ejecutadas por mshta.exe, un binario firmado digitalmente por Microsoft, preinstalado en todos los Windows y residente en System32 con muchísima confianza del sistema. Combina HTML, CSS y JavaScript o VBScript, y abre acceso total a COM objects que normalmente están restringidos:

• WScript.Shell: ejecuta comandos como una shell real. Bypasea las restricciones típicas contra CMD y PowerShell que aplican muchos entornos, sobre todo los bancarios, vía Active Directory o Application Allow Listing.
• FileSystemObject: leer y escribir archivos en disco.
• ADOdb: consultas a bases de datos y bypass de los filtros WFP que monitorean el tráfico de red saliente. Un implante dentro de mshta.exe genera tráfico fuera del navegador, con los mismos privilegios que un script nativo de Windows.

AppLocker, WDAC y la casilla del Mark of the Web

Las políticas de Application Allow Listing (AppLocker, WDAC) restringen al usuario a ejecutar solo lo que está en la allow list. Pero los HTA escapan a esa restricción porque mshta.exe es nativo de Windows y rara vez está bloqueado por el EDR. En entornos muy restrictivos sí se controla, aclara, pero en la mayoría no.

Y el detalle final: cuando descargas un HTA de internet, Windows muestra la ventana "el archivo proviene de otro equipo y podría bloquearse". Basta con abrir Propiedades, marcar Desbloquear y aceptar para que el HTA ejecute sin ningún tipo de permiso. Es lo menos seguro del mundo, dice Jeremy. La PoC que mostró en vivo, construida con llamadas de ADOdb, enumeró prácticamente todo el directorio activo de un entorno de prueba.

Herramientas forenses como vector ofensivo

El tercer caso es el más contraintuitivo. Las herramientas forenses suelen estar en la lista blanca del EDR porque los equipos de defensa las usan a diario. Eso las convierte en vectores ofensivos de primera línea: el flujo es ejecutar un dumper de memoria —Jeremy usó PLT, un binario sencillo disponible para Windows y Linux— para volcar la RAM completa del equipo. Es lento (horas o días según la memoria), pero efectivo. Después, Volatility 3 analiza el dump para reconstruir LSASS, extraer tokens y credenciales, y obtener una estimación razonable de una infraestructura desconocida. Cero payloads maliciosos, cero alertas.

Inteligencia artificial para generar código ofensivo

El último caso es el más reciente. Hoy todas las IAs pueden generar malware, pero hay que pedirlo con inteligencia: no "dame un ransomware", sino "crea un archivo que ponga en AES todo lo que está en esta carpeta". Funciones puntuales que luego se integran en un binario o script que ya corre en un entorno permitido. Jeremy lo probó en laboratorio con un beacon custom de Sliver: se lo pasó a la IA en un entorno controlado y ella revisó temas de directorio activo y encontró lo que buscaba sin asistencia adicional. Los EDRs más básicos (Check Point y similares) se aplastan solo con carga en memoria y cambios de permisos.

Las preguntas del público: el acceso inicial real

La primera pregunta obligó a aterrizar la teoría. En la vida real, casi el 100% de los accesos iniciales que su equipo ejecuta llegan por phishing: documentos Word o Excel maliciosos, mucho más fáciles de hacer llegar a una persona que un payload exótico. El patrón habitual: data leak previo de la empresa, enumeración de correos, ingeniería social para entregar el archivo y, de ahí en adelante, todo lo demás.

Sobre la IA, Jeremy reconoció que las versiones actuales de Claude tienen políticas mucho más duras que la 4.6, y que la alternativa para saltarse esos guardrails son los modelos locales sin censura o servicios externos como los de DragonJAR. La conversación cerró con la pregunta que todo Blue Team se hace: ¿un antivirus tradicional es suficiente hoy? Su respuesta: no. El antivirus solo ve firmas; los EDR añaden reglas y correlación, y aun así hace falta combinar con webfilter, segmentación y defensa en profundidad. Él mismo lo ha vivido: bypaseó todo el EDR y el webfilter le impidió seguir.

Lecciones para los defensores

• Las reglas del EDR no son IA. Cualquier técnica que no coincida con una regla existente pasa: mapea las reglas y audita los gaps.
• Java, mshta.exe y PowerShell firmado son superficies ofensivas. Permitir la JVM sin restricciones abre una puerta lateral bajo firma de Microsoft.
• AppLocker y WDAC deben bloquear archivos HTA y binarios firmados de uso ofensivo. La allow list por defecto de Windows es demasiado laxa.
• Las herramientas forenses son un vector real. Lo que whitelisteas para tu Blue Team puede usarlo el Red Team en tu contra.
• Antivirus solo no alcanza. EDR sin webfilter y sin segmentación deja huecos que un atacante creativo cierra rápido.

Como cerró Jeremy: la evasión de EDR ya no va de escribir mejor el código malicioso, va de entender mejor aquello que el propio sistema considera confiable.

Preguntas frecuentes

¿Qué es exactamente la evasión de EDR sin malware?

Es un conjunto de técnicas ofensivas que bypassean EDRs como CrowdStrike o Palo Alto sin escribir un binario malicioso propio. Se apoyan en herramientas firmadas y entornos que el endpoint ya considera benignos: la JVM de Java, mshta.exe firmado por Microsoft y herramientas forenses como Volatility 3 y los dumperes de memoria. La cadena corre bajo la firma de binarios legítimos.

¿Por qué un archivo HTA evade el EDR?

Porque mshta.exe es nativo de Windows, está firmado digitalmente por Microsoft y vive en System32 con muchísima confianza del sistema. Los EDRs actuales no marcan su ejecución como sospechosa. Dentro del HTA puedes usar COM objects como WScript.Shell (ejecutar comandos), FileSystemObject (leer y escribir disco) y ADOdb (consultas a bases de datos y bypass de filtros de red), todo con privilegios de script nativo.

¿Qué ventaja tiene abusar de la JVM frente a un binario nativo?

El EDR no ve tu binario ejecutándose: ve Java ejecutando bytecode. La telemetría queda enmascarada bajo la JVM, un proceso firmado por Microsoft y con permisos altos en muchos entornos. El bytecode se compila en memoria (Interpreter + JIT) sin tocar disco, lo que elimina las cabeceras PE visibles para las reglas estáticas.

¿Es legal probar estas técnicas?

Solo en entornos con autorización explícita: laboratorios personales, bug bounty con alcance definido o ejercicios de Red Team contratados. Replicarlas contra sistemas sin permiso es delito. Jeremy lo repitió en la charla: la creatividad ofensiva exige responsabilidad profesional.

Conclusión: cuando el atacante opera donde el EDR confía

La charla de Jeremy Erazo deja una lección incómoda: el modelo clásico del atacante —escribir malware sofisticado que bypasee firmas y reglas— ya no es el más eficiente. Un adversario creativo con Java, mshta.exe, herramientas forenses y una IA generativa puede comprometer el directorio activo de una empresa sin generar una sola alerta de alta fidelidad. La evasión de EDR ya no se mide por la calidad del código malicioso: se mide por la calidad de la pregunta "¿qué considera confiable mi propio endpoint?".

Para seguir aprendiendo sobre seguridad ofensiva a partir de casos reales, regístrate en https://www.dragonjarcon.org. Allí podrás acceder a charlas como la que acabas de leer y conocer más sobre DragonJARCON, el congreso anual que reúne en Colombia a profesionales e investigadores de la seguridad informática.

Y si tu organización necesita este mismo nivel de análisis y escrutinio, conoce los servicios de seguridad ofensiva de DragonJAR en https://www.dragonjar.org/servicios-de-seguridad-informatica.

Mira la Charla Completa Sobre evasión de EDR sin malware

Toda la charla de Jeremy Erazo —del Java C2 a los archivos HTA firmados por Microsoft y el experimento con Sliver e IA— está disponible en YouTube: