Más allá de los drivers

Puntos clave de este blogpost:

• Los EDR killers son una parte fundamental de las intrusiones de ransomware modernas; los afiliados prefieren una ventana corta y confiable para ejecutar los cifradores en lugar de modificar constantemente los payloads.
• Son los afiliados, no los operadores, quienes eligen los EDR killers; cuanto mayor es el conjunto de afiliados, mayor es la diversidad de herramientas.
• El mismo driver aparece en herramientas no relacionadas, y la misma herramienta puede migrar entre drivers. En consecuencia, la atribución basada en drivers suele ser engañosa.
• El modelo packer como servicio y EDR killer como producto aumentan la disponibilidad, complican la atribución y agregan desafíos para la defensa.
• Los EDR killers implementan técnicas de evasión defensiva, mientras que los encryptors se enfocan exclusivamente en la cifrado.
• Sospechamos firmemente que la IA asistió en el desarrollo de algunos EDR killers, y proporcionamos un ejemplo concreto con la pandilla Warlock.
• Aunque BYOVD domina, también se utilizan scripts personalizados, anti‑rootkits y EDR killers sin driver.

El panorama de los EDR killers

Fiabilidad y sencillez operativa para los desarrolladores de cifradores

Bajo costo, alta potencia

Como se muestra a lo largo de esta publicación, los EDR killers son extremadamente accesibles. No todos los intrusos o afiliados tienen las habilidades necesarias para desarrollar sus propias técnicas de evasión defensiva. Pero gracias a grandes colecciones de PoCs públicos, los EDR killers se han vuelto esencialmente plug‑and‑play.

Al mismo tiempo, los EDR killers suelen apoyarse en drivers legítimos pero vulnerables, lo que hace que la defensa sea significativamente más difícil sin arriesgar la interrupción de software empresarial o heredado. El resultado es una clase de herramientas que ofrecen impacto a nivel de kernel con un esfuerzo de desarrollo mínimo, lo que las vuelve desproporcionadamente poderosas dada su simplicidad.

Previsibilidad y repetibilidad durante las intrusiones

Empaquetar o inyectar código puede ayudar a que un implant pase inadvertido, pero no garantiza la estabilidad a largo plazo del payload de ransomware durante la fase final de la intrusión. Debido a la protección en capas que proporcionan los productos de seguridad, incluso los encryptors empaquetados pueden ser detectados en memoria o en otras etapas de ejecución. Los EDR killers, en cambio, proporcionan un paso predecible y reproducible en la cadena de ataque, dando a los atacantes un flujo de trabajo más determinista. Además, los EDR killers apuntan a interrumpir la solución de seguridad en su totalidad, eliminando efectivamente todas las capas de protección.

La tecnología detrás de los EDR killers

Scripts

Los EDR killers más simples no dependen de drivers vulnerables ni de otras técnicas avanzadas. En su lugar, abusan de herramientas y comandos administrativos integrados como taskkill, net stop o sc delete delete para manipular los procesos y servicios de los productos de seguridad. Estos enfoques rudimentarios todavía aparecen ocasionalmente, pero hoy se asocian principalmente con actores de ransomware de bajo nivel y malware de tipo commodity.

Variantes ligeramente más sofisticadas combinan scripting con el Modo Seguro de Windows. Como el Modo Seguro carga solo un subconjunto mínimo del sistema operativo —y las soluciones de seguridad normalmente no están incluidas—, el malware tiene más posibilidades de desactivar la protección. Al mismo tiempo, este tipo de actividad es muy ruidosa, ya que requiere un reinicio, lo cual es riesgoso e inestable en entornos desconocidos. Por lo tanto, se observa solo de manera esporádica in the wild.

Zona gris: Anti-rootkits

Hace años, antes de que Microsoft exigiera la firma de drivers en modo kernel, los rootkits proliferaban en el ecosistema del cibercrimen, ocultando actividad maliciosa mediante la manipulación de estructuras del kernel. Su prevalencia llevó al desarrollo de herramientas especializadas de anti‑rootkit diseñadas para detectarlos y eliminarlos. Debido a que los rootkits operan en modo kernel, estas herramientas requieren naturalmente privilegios elevados y sus propios drivers para descubrir, enumerar y neutralizar los rootkits.

Hoy en día, los afiliados de ransomware abusan con frecuencia de estas mismas herramientas anti‑rootkit: no para eliminar rootkits, sino para inutilizar soluciones de seguridad. Muchos anti‑rootkits ofrecen una interfaz gráfica amigable (GUI) que permite a los usuarios —incluidos atacantes con poca capacidad técnica— finalizar procesos o servicios protegidos. En otras palabras, herramientas legítimas de remediación se han convertido en EDR killers convenientes cuando son mal utilizadas. Entre estas herramientas se incluyen GMER (ver Figura 1), HRSword y PC Hunter.

Rootkits

Aunque los rootkits son en gran medida raros en el cibercrimen moderno, todavía aparecen excepciones notables. Un ejemplo del año pasado es ABYSSWORKER, un rootkit en modo kernel que llamó la atención después de que sus creadores lograran firmarlo utilizando certificados robados de empresas chinas. Estos certificados también habían sido usados para firmar otros tipos de malware y, por lo tanto, no son específicos de ABYSSWORKER. Dado que los certificados robados pertenecen a una cadena de certificados confiable, un driver firmado con ellos aún puede ejecutarse en el kernel. Y, para complicar aún más las cosas, incluso la revocación de certificados no es una solución infalible, como demostró recientemente Huntress.

Drivers vulnerables

La técnica BYOVD se ha convertido en el sello distintivo de los EDR killers modernos: dominante, confiable y ampliamente utilizada. En un escenario típico, un atacante deja caer un driver legítimo pero vulnerable en la máquina de la víctima, instala ese driver y luego ejecuta malware que abusa de la vulnerabilidad del driver. El objetivo es terminar procesos protegidos o desactivar callbacks de los que dependen los productos de seguridad.

Aunque existen miles de drivers legítimos vulnerables, solo un subconjunto relativamente pequeño es explotado de manera activa en incidentes de ransomware. Sin embargo, la disponibilidad de PoCs públicos significa que, en la práctica, no hay límite para la cantidad de actores que pueden adoptar o adaptar exploits para estas vulnerabilidades. Algunos atacantes reutilizan bases de código existentes con cambios mínimos o nulos; otros no cambian la lógica pero los reimplementan en su lenguaje de programación preferido; y algunos incluso desarrollan EDR killers completamente nuevos (manteniendo solo una pequeña parte del código original responsable de la explotación del driver) que luego usan ellos mismos u ofrecen como servicio.

Anuladores de EDR sin driver (driverless)

¿Quién desarrolla los EDR Killers?

En 2025, los investigadores de ESET publicaron un análisis de EDRKillShifter, un EDR killer desarrollado por los operadores de RansomHub y ofrecido directamente a sus afiliados. Al momento de redactar este artículo, no tenemos conocimiento de ningún otro programa RaaS cuyos operadores proporcionen sus propios EDR killers propietarios. Esto convierte al ya desaparecido RansomHub en una excepción notable dentro del panorama del ransomware.

En cambio, la mayoría de los actores de amenaza pertenecen a una de las siguientes categorías:

• bandas no-RaaS que desarrollan sus propios EDR killers,
• atacantes que hacen forks y modifican ligeramente código de prueba de concepto público, o
• atacantes que compran un EDR killer en mercados underground.

Veamos cada una de estas situaciones con mayor detalle.

Grupos cerrados

Las bandas no-RaaS suelen operar como ecosistemas completamente cerrados: sin afiliados, sin brokers de acceso inicial ni socios externos. Estos grupos mantienen un control estricto sobre sus flujos de trabajo de intrusión y típicamente dependen de un conjunto repetible e internamente consistente de TTPs. Dado este nivel de disciplina operativa, desarrollar sus propios EDR killers se convierte en una extensión natural de su arsenal.

Los investigadores de ESET destacaron un ejemplo temprano de este modelo de desarrollo interno en 2024 con la banda Embargo. En ese momento, Embargo se apoyaba en dos EDR killers:

• un script personalizado de Modo Seguro, aprovechando la técnica ya descrita anteriormente, y
• MS4Killer, una herramienta inspirada en el PoC públicamente disponible s4killer.

Aunque MS4Killer se basaba en un PoC disponible, sus desarrolladores realizaron cambios significativos: añadieron paralelismo, modificaron el flujo de código, y cifraron las strings y el driver embebido. Desde la publicación de esa investigación, Embargo ha migrado a otro PoC público, evil-mhyprot-cli, esta vez con modificaciones mínimas al código.

Un segundo ejemplo, más reciente, es la banda DeadLock. DeadLock mantiene un perfil bajo al no tener un sitio de filtraciones dedicado y realizar todas sus negociaciones a través de Session, una alternativa popular al más común Tox. Los investigadores de ESET han observado a DeadLock utilizando dos EDR killers, DLKiller (también mencionado como loader sin nombre por Cisco Talos) y Susanoo, además de anti-rootkits como GMER y PC Hunter. Los investigadores de ESET creen con baja confianza que DLKiller y el encryptor de DeadLock son obra del mismo desarrollador, debido a similitudes de código notables pero, por sí solas, no concluyentes. Curiosamente, Susanoo proporciona una pantalla de carga y una GUI, ambas presentadas en la Figura 2, permitiendo la interacción manual y esperando que el atacante tenga acceso interactivo a la máquina de la víctima.

Como demuestra claramente la captura de pantalla, Susanoo ofrece botones para precargar la lista de procesos monitoreados: uno dedicado dirigido a procesos relacionados con Sophos y uno “TNT” dirigido a todos los procesos que Susanoo conoce.

El tercer y último ejemplo es Warlock. Aunque el sitio de filtraciones de Warlock ha estado en silencio desde el 6 de noviembre de 2025, el grupo sigue operativo y continúa expandiendo su arsenal técnico. La banda es conocida por su disposición a experimentar: adaptó la técnica de abuso de VS Code para el acceso remoto sigiloso, documentadapreviamente en septiembre de 2024 y utilizada por el grupo APT Mustang Panda, y también fue pionera en el uso malicioso de Velociraptor. Desde entonces, Warlock ha confiado consistentemente en estas técnicas. Su enfoque respecto a los encryptors refleja este mismo patrón: Warlock ha empleado múltiples encryptors diferentes a lo largo del tiempo, desde versiones personalizadas hasta variantes basadas en Babyk o generadas con el builder filtrado de LockBit Black.

Dado todo esto, la experimentación de Warlock con EDR killers no sorprende. Desde que la banda apareció por primera vez, ha desplegado rutinariamente múltiples EDR killers por intrusión, en ocasiones incluso decenas durante operaciones recientes, forzando a fuerza bruta la búsqueda de una solución funcional. El arsenal de Warlock es diverso no solo en cantidad sino también en profundidad técnica: la banda no se limita a un único driver vulnerable y ha abusado de al menos nueve drivers diferentes hasta la fecha, incluyendo algunos sin ningún PoC disponible públicamente (al menos según nuestro conocimiento); un detalle que subraya la competencia técnica del grupo y su capacidad para adaptar herramientas ofensivas más allá de lo que está fácilmente disponible de forma pública.

Modificación de un PoC

Este es, por lejos, el enfoque más común observado en intrusiones de ransomware. Los actores de amenaza frecuentemente toman un PoC existente y bien probado, y ajustan solo los componentes no críticos antes de desplegarlo en ataques reales. Estas modificaciones típicamente incluyen:

• eliminar o alterar mensajes de depuración,
• agregar ofuscación de código,
• ajustar la lista de productos de seguridad objetivo, y
• reescribir la herramienta en un lenguaje de programación diferente.

El punto crucial, sin embargo, es que la lógica central de explotación, especialmente la parte que interactúa con el driver vulnerable, casi nunca cambia. Esta lógica suele ser tan simple como llamar a la API de Windows DeviceIoControl con un valor dwIoControlCode “correcto” y el nombre del proceso a terminar en lpInBuffer. Si bien renombrar strings, reestructurar el codebase o reimplementar la herramienta en otro lenguaje son operaciones que no requieren conocimientos técnicos profundos, modificar la lógica de explotación sí lo requiere, y por ello típicamente se evita.

Aunque hay muchos PoC disponibles públicamente para los EDR killers, destaca un repositorio: BYOVD de BlackSnufkin. Actualizado regularmente, contiene (en el momento de escribir esto) PoCs para explotar 10 controladores vulnerables, cada uno implementado siguiendo la misma plantilla modular. La implementación permite modificaciones sencillas, extensiones y soporte de nuevos controladores. Además, el código está bien documentado (véase la Figura 3), lo que convierte a este repositorio en el más utilizado en la actividad de ransomware in the wild.

Detectamos uno de los EDR killers de BlackSnufkin,  TfSysMon-Killer, desplegado durante un ataque de ransomware Monti en febrero de 2025; la variante desplegada era idéntica en cuanto a funcionalidad, pero fue reimplementada de Rust a C++, probablemente para alinearse con otras herramientas del actor de amenaza. Otro ejemplo de cambio de lenguaje es dead-av, cuyo autor describe abiertamente como una reescritura en Go de GhostDriver, otro PoC creado por BlackSnufkin.

Un esfuerzo de modificación más extenso puede verse en SmilingKiller, un EDR killer observado recientemente por investigadores de ESET durante intrusiones de LockBit y Dire Wolf. Su desarrollador se inspiró en kill-floor, un PoC de EDR killer que abusa del aswArPot.sys de Avast. Además de modificar los mensajes de depuración y agregar ofuscación por control-flow flattening (ver Figura 4), el autor también cambió el driver abusado a K7RKScan.sys, el mismo driver que abusa K7Terminator, otro de los PoCs de BlackSnufkin.

EDR killer como servicio

Dada la fuerte y creciente demanda de herramientas de disrupción de EDR, no sorprende que haya surgido un mercado paralelo de EDR killers comerciales. La variedad de ofertas es amplia: algunos anuncios ofrecen solo promesas vagas sin detalles técnicos, mientras que otros incluyen listas extensas de funcionalidades, instrucciones de uso e incluso demostraciones en video. A continuación presentamos tres ejemplos destacados.

Uno de esos anuncios, revelado por Flare en octubre de 2025, provenía de un actor de amenaza que usaba el apodo Бафомет. El actor de amenaza anunciaba un EDR killer que los investigadores de ESET denominaron posteriormente DemoKiller. La telemetría de ESET confirma que DemoKiller ha sido utilizado por afiliados de las bandas Qilin, Akira y Gentlemen, y también lo observamos desplegado en una ocasión durante una intrusión de RansomHouse. El anuncio se muestra en la Figura 5.

Otro EDR killer de pago gira en torno al rootkit ABYSSWORKER, mencionado anteriormente en este blogpost. Al combinarse con su componente loader empaquetado con HeartCrypt, al que los investigadores de ESET denominaron AbyssKiller, este EDR killer se ha convertido en uno de los más observados comercialmente in the wild. Los investigadores de ESET han visto a AbyssKiller utilizado por afiliados de las bandas Medusa, DragonForce y ahora desarticulada, esta última ya desmantelada.

El último ejemplo destacado es un EDR killer al que llamamos CardSpaceKiller. Esta herramienta se empaqueta consistentemente usando VX Crypt, un packer as a service relativamente nuevo analizado por Sophos a finales de 2025. VX Crypt no es exclusivo de este EDR killer; también ha sido utilizado para proteger otras familias de malware como BumbleBee. Según Sophos, CardSpaceKiller ha aparecido en intrusiones que involucran a Akira, Medusa, Qilin y Crytox. La telemetría de ESET coincide con estos hallazgos y muestra adicionalmente su despliegue durante incidentes de MedusaLocker. Al analizar el payload desempaquetado, queda inmediatamente claro que este EDR killer proviene de una oferta comercial, donde el desarrollador intenta manejar casos límite con una advertencia (ver Figura 6).

La naturaleza y el precio de estas herramientas anunciadas comercialmente varían. Algunas afirman vender el código fuente, otras solo builds individuales. El precio suele ser una cuestión de negociación individual; cuando se ha revelado públicamente, ha oscilado entre cientos y miles de dólares estadounidenses.

EDR killers e IA

Si bien el conjunto de drivers vulnerables abusados sigue siendo relativamente pequeño, el número de componentes en modo usuario distintos que forman parte de los EDR killers modernos in the wild está creciendo rápidamente. Dado este aumento en volumen y variedad, es natural en 2026 preguntarse: ¿está la IA contribuyendo a esta proliferación?

Determinar si la IA asistió directamente en la producción de un codebase específico suele ser prácticamente imposible. No existe un marcador forense definitivo que distinga de manera confiable el código generado por IA del código escrito por humanos, especialmente cuando los atacantes lo post-procesan u ofuscan. Sin embargo, los investigadores de ESET evalúan que al menos algunos EDR killers observados recientemente exhiben características que sugieren fuertemente una generación asistida por IA.

Un ejemplo claro aparece en un EDR killer desplegado recientemente por Warlock. La herramienta contiene una sección de código que no solo imprime una lista de Possible fixes, un patrón típico del boilerplate generado por IA, sino que también, en lugar de explotar un driver específico, implementa un mecanismo de prueba y error que recorre varios nombres de dispositivos comúnmente abusados y no relacionados hasta encontrar uno que funcione. El código correspondiente se muestra en la Figura 7.

Más allá de los drivers

Comprender cabalmente el ecosistema de los EDR killers requiere mirar mucho más allá de los drivers vulnerables. Si bien la explotación de drivers sigue siendo un pilar dominante de muchas herramientas, es solo una parte de un panorama mucho más amplio. Nuestra investigación muestra que centrarse únicamente en los drivers oscurece relaciones significativas entre herramientas, afiliados y clusters de actividad.

Una observación clave es la división del trabajo en los ecosistemas RaaS. Los operadores típicamente suministran el encryptor y la infraestructura de soporte, pero la selección del EDR killer queda en manos de los afiliados. Esto significa que cuanto mayor es el pool de afiliados, más diverso se vuelve el arsenal de EDR killers. Al mismo tiempo, la reutilización consistente de herramientas específicas dentro de clusters particulares puede ayudar a identificar nuevas afiliaciones, fortalecer los vínculos de infraestructura y revelar relaciones operador-afiliado que permanecerían invisibles si uno se enfocara únicamente en las familias de encryptors.

Reutilización y cambio de controladores

Los PoCs públicos han hecho que la explotación de drivers sea ampliamente accesible, pero esto ha generado una situación engañosa: el mismo driver vulnerable es frecuentemente reutilizado en EDR killers no relacionados, y el mismo EDR killer puede utilizar diferentes drivers a lo largo del tiempo. Como resultado, la atribución basada únicamente en drivers es propensa a errores.

Un ejemplo claro es el driver de Baidu Antivirus BdApiUtil.sys, que aparece en múltiples proyectos independientes, incluyendo:

• dead-av,
• BdApiUtil-Killer,
• DLKiller,
• HexKiller, one of Warlock’s EDR killers, and
• SevexKiller, a recent EDR killer detected during Akira deployments.

El mismo patrón aparece con el driver TfSysMon.sys (ThreatFire System Monitor). Es abusado por TfSysMon-Killer, Susanoo y EDRKillShifter: tres codebases con implementaciones e historiales de desarrollo distintos.

El cambio de driver es igualmente común. CardSpaceKiller, por ejemplo, inicialmente dependía de HwRwDrv.sys, pero variantes posteriores migraron a ThrottleStop.sys  con cambios mínimos en la lógica restante. El driver es intercambiable; la capa de explotación permanece prácticamente igual.

Esto ilustra el punto central: los drivers son un recurso commodity, y su sola presencia ofrece poca información sobre la sofisticación o las relaciones del actor de amenaza.

Evasión de detección

Los atacantes no están invirtiendo mucho esfuerzo en hacer que sus encryptors sean indetectables. Más bien, todas las sofisticadas técnicas de evasión de defensas se han trasladado a los componentes en modo usuario de los EDR killers. Esta tendencia es más visible en los EDR killers comerciales, que frecuentemente incorporan capacidades maduras de anti-análisis y anti-detección. Las técnicas recurrentes más destacadas incluyen:

Desacoplamiento del driver. El killer y el driver suelen entregarse por separado. Los afiliados instalan el driver manualmente primero, verificando que cargue correctamente antes de ejecutar el componente del EDR killer propiamente dicho.

Uso de packers comerciales. Packers como VX Crypt (usado con CardSpaceKiller) y HeartCrypt (usado con AbyssKiller) proporcionan ofuscación a nivel de estructura, comportamiento anti-VM y repacking continuo para evadir firmas estáticas. También se favorecen protectores de virtualización de código populares como VMProtect y Themida.

Drivers embebidos cifrados. Cuando un driver está incluido en un EDR killer, frecuentemente se almacena en forma cifrada.

Payloads externos cifrados. Algunos EDR killers almacenan shellcode cifrado o componentes auxiliares en archivos separados. Este enfoque oculta efectivamente partes cruciales del killer, dificultando su acceso a los defensores.

Ofuscación de código. Las técnicas comunes incluyen control-flow flattening (SmilingKiller), resolución de llamadas por hash (CardSpaceKiller) y ofuscación de strings.

Protección con contraseña. EDRKillShifter es un ejemplo perfecto del uso de esta técnica. Proteger una parte crucial del EDR killer con contraseña genera desafíos de detección, pero también ofrece oportunidades para la investigación.

• Uso de empaquetadores comerciales. Los empaquetadores como VX Crypt (utilizado con CardSpaceKiller) y HeartCrypt (utilizado con AbyssKiller) proporcionan ofuscación a nivel de estructura, comportamiento anti-VM y reempaquetado continuo para evadir las firmas estáticas. Los protectores de virtualización de código más populares, como VMProtect y Themida, también se ven favorecidos.
• Controladores integrados cifrados. Cuando un controlador se incluye con un asesino EDR, a menudo se almacena cifrado.
• Cargas cifradas externas. Algunos asesinos de EDR almacenan shellcode cifrado o componentes auxiliares en archivos independientes. Este método impide que los defensores puedan acceder fácilmente a partes cruciales del asesino.
• Ofuscación del código. Entre las técnicas más comunes se incluyen el aplanamiento del flujo de control (SmilingKiller), la resolución llamada por hash (CardSpaceKiller) y la ofuscación de cadenas
• Protección por contraseña. EDRKillShifter es un ejemplo perfecto del uso de esta técnica. Proteger una parte crucial del asesino EDR con una contraseña crea retos de detección, pero también ofrece oportunidades de investigación.

Defensa contra el ransomware y los EDR killers

Defenderse del ransomware requiere una mentalidad fundamentalmente diferente a la de defenderse de amenazas automatizadas. Los emails de phishing, el malware commodity y las cadenas de exploits se detienen una vez que las soluciones de seguridad los detectan y neutralizan; las intrusiones de ransomware no. Son operaciones interactivas, dirigidas por humanos, y los intrusos se adaptan continuamente a las detecciones, las fallas de herramientas y los obstáculos del entorno. Como resultado, incluso cuando se detectan pasos individuales, estos solo tienen valor defensivo si los defensores, ya sea un equipo SOC interno, un MSSP o un proveedor MDR, responden correctamente, de inmediato y con suficiente decisión.

La mayoría de los EDR killers se apoyan en drivers legítimos pero vulnerables, razón por la cual los defensores instintivamente se enfocan en el bloqueo de drivers. Bloquear la carga del driver es un paso crucial y efectivamente neutraliza el EDR killer, pero solo en el último momento posible. Para cuando un afiliado intenta instalar el driver, típicamente ya tiene altos privilegios y está a segundos de lanzar el encryptor. Si el EDR killer falla, simplemente intentará con otra herramienta.

Dado que estos drivers son legítimos, un bloqueo demasiado agresivo arriesga interrumpir software crítico para el negocio, complicando el manejo de incidentes. El bloqueo focalizado también enfrenta desafíos. En febrero de 2025, Check Point demostró que los actores de amenaza pudieron crear más de 2.500 muestras de Truesight.sys, todas ellas con firma válida debido a una debilidad en el proceso de verificación de validez de firma. Truesight.sys es también uno de los muchos ejemplos de una debilidad  en la política de firma de drivers de Microsoft. Un año después, en febrero de 2026, Huntress analizó una intrusión donde EnPortv.sys fue abusado a pesar de que su certificado estaba vencido y explícitamente revocado.

Por eso es esencial una estrategia que de prioridad a la prevención. Bloquear la carga de los drivers más comúnmente abusados es un mecanismo de defensa efectivo y necesario, pero no debería ser el único. Estudiar los EDR killers permite a los defensores desarrollar una estrategia en múltiples capas que amplía los horizontes; el objetivo es detener el EDR killer antes de su ejecución. Al fin y al cabo, cuando se trata de ransomware, la estrategia de defensa más efectiva es contar con métodos para detectar, contener y remediar la amenaza en cada paso posible.

Conclusión

Los EDR killers perduran porque son baratos, consistentes y están desacoplados del encryptor: un ajuste perfecto tanto para los desarrolladores de encryptors, que no necesitan enfocarse en hacer sus encryptors indetectables, como para los afiliados, que cuentan con una utilidad poderosa y fácil de usar para neutralizar las defensas antes del cifrado.

Nuestra investigación presenta insights respaldados por telemetría sobre el ecosistema de los EDR killers que van más allá del enfoque centrado en drivers que suele verse. Documentamos cómo son los afiliados, y no los operadores, quienes moldean la diversidad de herramientas, y cómo los codebases reutilizan e intercambian drivers de forma rutinaria. Describimos cómo el último año vio ofertas cada vez más comercializadas de EDR killers, y mostramos cómo los EDR killers comerciales en particular pueden proveer las técnicas de evasión de defensas que típicamente faltan en los encryptors.

Destacamos que si bien prevenir la carga de drivers vulnerables es un paso crucial en la línea de defensa, también puede generar potenciales interrupciones del negocio, razón por la cual no debe confiarse únicamente en esa medida, y debe apuntarse a neutralizar los EDR killers antes de que tengan la oportunidad de cargar el driver. Además, demostramos que los enfoques sin drivers, ya sean basados en scripts o en vulnerabilidades, son una adición favorecida en el arsenal de cualquier actor de amenaza de ransomware.

Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, póngase en contacto con nosotros en threatintel@eset.com.

ESET Research ofrece informes privados de inteligencia APT y fuentes de datos. Para cualquier consulta sobre este servicio, visite la página de ESET Threat Intelligence.

IoCs

Puede encontrar una lista completa de indicadores de compromiso (IoCs) y muestras en nuestro repositorio GitHub.

Archivos

Técnicas ATT&CK de MITRE

Esta tabla se ha creado utilizando la versión 18 del marco MITRE ATT&CK.

¡Para todos nuestros lectores!

Aprovechen esta oportunidad de obtener un trial gratuito de 30 días para Google Workspace, la mejor solución para tu empresa. Disfruta de todas sus funcionalidades, como correo electrónico personalizado, almacenamiento en la nube y herramientas de colaboración.

Comienza tu prueba gratuita