Entraron a través de SonicWall. Luego intentaron eliminar todas las herramientas de seguridad

Resumen

A principios de febrero de 2026, Huntress respondió a una intrusión donde actores de amenazas aprovecharon credenciales comprometidas de SonicWall SSLVPN para obtener acceso inicial a la red de la víctima. Una vez dentro, el atacante implementó un EDR killer que abusa de un controlador forense legítimo de Guidance Software (EnCase) con un certificado revocado para terminar procesos de seguridad desde el modo kernel, una técnica conocida como Bring Your Own Vulnerable Driver (BYOVD).

El ataque se interrumpió antes de la implementación del ransomware, pero el caso destaca una tendencia creciente: los actores de amenazas utilizan como arma controladores firmados y legítimos para cegar la seguridad de los endpoints. El certificado del controlador de EnCase expiró en 2010 y luego se revocó, pero Windows aún lo carga, una brecha en Driver Signature Enforcement que los atacantes siguen aprovechando.

Análisis técnico

Huntress Managed SIEM ingirió la telemetría de SonicWall del entorno de la víctima, lo cual resultó fundamental para detectar y reconstruir la línea de tiempo de la intrusión. El análisis de los registros de autenticación de VPN reveló que el actor de amenazas se autenticó con éxito en el SonicWall SSLVPN desde una dirección IP externa maliciosa en febrero de 2026.

Cabe destacar que los registros también capturaron un intento denegado de inicio de sesión en el portal desde 193.160.216[.]221 apenas un minuto antes; la cuenta no tenía privilegios para acceder al portal desde esa ubicación. Luego, el atacante se autenticó con éxito mediante el cliente VPN desde una IP diferente 69.10.60[.]250.

Figura 1: Panel de Huntress SIEM que muestra eventos de autenticación exitosos desde la IP del actor de amenazas

La correlación entre la telemetría del SIEM y la visibilidad de endpoints permitió a Huntress identificar rápidamente la amenaza, poner en cuarentena los sistemas afectados y brindar al cliente recomendaciones prácticas de remediación.

Figura 2: Correlación del SIEM con la detección de EDR

Descubrimiento

Una vez autenticado, el actor de amenazas realizó un reconocimiento agresivo de la red. Las alertas de IPS de SonicWall capturaron barridos de ping ICMP, sondeos de solicitud de nombre NetBIOS y actividad dirigida a SMB, incluido un comportamiento de inundación SYN con tasas que superaban los 370 SYN por segundo.

Ejecución

EDR killer

El binario es un ejecutable de Windows de 64 bits que implementa un controlador de kernel para terminar procesos de software de seguridad. Se hace pasar por una utilidad legítima de actualización de firmware.

BYOVD incorporado

El binario del EDR killer utiliza un esquema de codificación personalizado para ocultar su payload de controlador de kernel incorporado. En lugar de almacenar el controlador como bytes sin procesar o usar cifrado tradicional, los desarrolladores del malware optaron por un cifrado de sustitución basado en una lista de palabras que transforma cada byte del controlador en una palabra en inglés. Esta técnica es particularmente eficaz para evadir las herramientas de análisis estático, ya que el payload codificado parece ser solo texto inocuo en inglés disperso por la sección de datos del binario.

En el centro de este esquema de codificación hay un diccionario de 256 palabras incorporado en el binario. Cada palabra de este diccionario corresponde a un valor de byte específico; el índice de la palabra en el arreglo equivale al byte que representa. Por ejemplo, "about" está en el índice 0 y se decodifica como 0x00, "block" en el índice 77 se decodifica como 0x4D (el valor ASCII de "M"), y "both" en el índice 90 se decodifica como 0x5A (ASCII "Z"). El payload codificado del controlador en sí se almacena como una cadena de 384,528 bytes de palabras en inglés separadas por espacios. Al decodificarse, estas palabras se traducen de nuevo al controlador de kernel original.

Figura 3: Fragmento del diccionario de palabras

Figura 4: Payload del controlador codificado con lista de palabras

La rutina de decodificación implementa un algoritmo de búsqueda sencillo. Inicializa un analizador sintáctico de cadenas para fragmentar el blob codificado palabra por palabra, y luego itera por cada palabra extraída. Para cada palabra encontrada, la función realiza una búsqueda lineal en la lista de 256 palabras, comparando la palabra actual con cada entrada del diccionario hasta encontrar una coincidencia. Una vez encontrada la coincidencia, el índice de la palabra se convierte en el valor de byte decodificado, que se agrega a un búfer de salida.

Las primeras palabras del payload codificado demuestran claramente esta transformación: "block both choice about" se decodifica como "4D 5A 90 00", la conocida firma MZ de un encabezado de ejecutable DOS. Esto confirma que la salida decodificada es un archivo PE de Windows válido. El controlador decodificado se escribe luego en “C:\ProgramData\OEM\Firmware\OemHwUpd.sys”, después de lo cual el binario aplica medidas antiforenses: configura los atributos del archivo como oculto y de sistema para ocultarlo de una exploración casual de directorios, y copia las marcas de tiempo del ntdll.dll legítimo para que el controlador malicioso se mezcle con los archivos del sistema.

Figura 5: Timestomping: el binario copia marcas de tiempo del ntdll.dll al controlador implantado para mezclarse con archivos de sistema legítimos

Este enfoque de codificación ofrece varias ventajas para el atacante. La detección tradicional basada en cadenas falla porque el payload no contiene nombres de API sospechosos, rutas de archivo ni firmas binarias en su forma codificada. El análisis basado en entropía diseñado para detectar malware empaquetado o cifrado puede ser ineficaz aquí; el payload codificado con la lista de palabras registra alrededor de 4 bits por byte, muy por debajo del umbral de 7 a 8 bits por byte que normalmente señala contenido cifrado o comprimido sospechoso.

Figura 6: Entropía del binario svchost.exe (Fuente: DiE)

Identificación de objetivos

El binario mantiene una lista de 59 nombres de procesos objetivo que se convierten en hash durante la inicialización mediante FNV-1a (semilla 0x811C9DC5). Durante la ejecución, enumera los procesos en ejecución mediante CreateToolhelp32Snapshot, convierte cada nombre a minúsculas, calcula su hash FNV-1a y lo compara con los hashes objetivo precalculados. Esto permite una comparación rápida de enteros en lugar de 59 comparaciones de cadenas por proceso.

El bucle de terminación se ejecuta continuamente con un intervalo de suspensión de 1 segundo, lo que garantiza que cualquier proceso de seguridad que se reinicie se vuelva a terminar de inmediato.

El EDR killer tiene como objetivo 59 procesos pertenecientes a los principales proveedores de seguridad de endpoints:

¿Quién está notablemente ausente de la lista de terminación? Huntress. Si bien el EDR killer apunta a casi todos los principales proveedores de EDR y antivirus del mercado, el agente de Huntress no estuvo entre los 59 procesos marcados para su terminación.

Persistencia

Una vez que el controlador de kernel se decodifica y se escribe en el disco, el binario establece persistencia registrándolo como un servicio de kernel de Windows. Esto permite que el controlador se cargue en el kernel y sobreviva a los reinicios del sistema.

El binario primero verifica si ya existe un servicio con el mismo nombre; si es así, elimina el servicio antiguo antes de crear uno nuevo. Luego registra el controlador con el Administrador de control de servicios usando nombres cuidadosamente elegidos diseñados para parecer software legítimo de un OEM:

Service Name: OemHwUpd

Display Name: OEM Hardware HAL Service

Description: Manages hardware abstraction layer compatibility

Binary Path: C:\ProgramData\OEM\Firmware\OemHwUpd.sys

Service Type: Kernel Driver

Start Type: Demand Start

Figura 7: Persistencia del controlador (Fuente: portal de Huntress)

Driver Signature Enforcement

Desde Windows Vista x64, Microsoft exige que todos los controladores en modo kernel estén firmados digitalmente por una autoridad certificadora de confianza. Esta política, conocida como Driver Signature Enforcement (DSE), impide que controladores sin firmar o manipulados se carguen en el kernel. Cuando se carga un controlador, Windows verifica que la firma digital sea criptográficamente válida y que se encadene a un certificado raíz de confianza de Microsoft.

Sin embargo, hay una brecha crítica en este proceso de verificación: el kernel no revisa las listas de revocación de certificados (CRL). Aunque Windows puede verificar que una firma sea matemáticamente válida y haya sido emitida por una autoridad de confianza, no puede determinar si esa autoridad certificadora emisora ya la revocó. Esta limitación existe por razones prácticas: los controladores se cargan temprano en el proceso de arranque, antes de que los servicios de red estén disponibles, y las verificaciones de CRL afectarían significativamente el rendimiento del arranque. Incluso cuando se importa manualmente una CRL al almacén local de certificados, el kernel omite por completo esta verificación.

El controlador de EnCase explotado en este ataque ilustra perfectamente esta brecha. Su certificado de firma expiró en enero de 2010 y posteriormente fue revocado, pero Windows aún acepta la firma porque la verificación criptográfica se cumple. Desde la perspectiva del kernel, la firma sigue siendo válida.

El enfoque de lista de bloqueo de Microsoft

En lugar de implementar la verificación de CRL, Microsoft introdujo la lista de bloqueo de controladores vulnerables, una lista de denegación basada en hashes que impide que se carguen controladores específicos conocidos como maliciosos. Desde la actualización de Windows 11 22H2, esta lista de bloqueo está habilitada de forma predeterminada cuando está activa la integridad de código protegida por hipervisor (HVCI) o la integridad de memoria. La lista de bloqueo se actualiza con cada versión importante de Windows, generalmente una o dos veces al año.

Este enfoque ofrece una precisión que la revocación de certificados no puede lograr: bloquear hashes de controladores individuales evita el daño colateral de revocar un certificado completo, lo que podría afectar software legítimo del mismo proveedor. Sin embargo, es inherentemente reactivo; un controlador primero debe identificarse como vulnerable, reportarse a Microsoft y agregarse a la lista de bloqueo antes de que la protección entre en vigor.

El certificado del controlador “EnPortv.sys” que implementó el actor de amenazas lleva más de 15 años vencido y posteriormente fue revocado, pero Windows lo acepta porque el kernel solo valida la cadena criptográfica, no el estado de vencimiento o revocación.

Una vez cargado, el controlador expone una interfaz IOCTL que permite a los procesos en modo usuario terminar procesos arbitrarios directamente desde el modo kernel. Esto evade todas las protecciones en modo usuario, incluido Protected Process Light (PPL), que normalmente protege los procesos críticos del sistema y los agentes EDR.

A pesar del estado inválido del certificado, Windows carga este controlador porque:

• La excepción del 29 de julio de 2015: A partir de Windows 10 versión 1607, Microsoft exigió que todos los controladores de kernel nuevos estuvieran firmados a través de Hardware Dev Center. Sin embargo, para mantener la compatibilidad con versiones anteriores, Microsoft creó una excepción: los controladores firmados con certificados emitidos antes del 29 de julio de 2015, que se encadenan a una CA de firma cruzada compatible, aún pueden cargarse. El certificado del controlador de EnCase se emitió el 15 de diciembre de 2006, mucho antes de esta fecha límite.

• Marca de tiempo válida: El controlador contiene una marca de tiempo de Thawte Timestamping CA (un servicio de VeriSign). Cuando el código se firma con una marca de tiempo, Windows valida la firma según el momento en que se creó la firma, no la fecha actual. Debido a que el controlador recibió su marca de tiempo mientras el certificado aún era válido (antes del 31 de enero de 2010), la firma sigue siendo válida indefinidamente, aunque el certificado haya expirado desde entonces.

• Cadena de certificados de confianza: La firma se encadena a través de VeriSign Class 3 Code Signing 2004 CA hasta Microsoft Code Verification Root, en la que Windows confía para la firma de código en modo kernel.

Una vez cargado, el controlador expone una interfaz IOCTL que permite que procesos en modo usuario terminen procesos arbitrarios directamente desde el modo kernel. Esto evita todas las protecciones del modo usuario, incluido Protected Process Light (PPL), que normalmente protege los procesos críticos del sistema y los agentes EDR.

El controlador forense de EnCase (EnPortv.sys) expone más de 18 funciones IOCTL diseñadas para la adquisición forense, incluida la terminación de procesos (KillProc), el ocultamiento de procesos mediante DKOM (HideProc/UnhideProc), la eliminación de archivos en modo kernel (DeleteFile), el acceso a la memoria física (OpenPhysicalMemory/ReadPhysicalMemory), la lectura de memoria de procesos (PidMemory) y la enumeración de VAD (GetVadList).

De todas estas capacidades, los actores de amenazas en este incidente solo usaron el IOCTL 0x223078 (KillProc) para terminar procesos de EDR. El componente en modo usuario abre un identificador al dispositivo del controlador (\\.\OemHwUpd) y envía los PID objetivo mediante DeviceIoControl. El controlador, que se ejecuta en modo kernel, llama a ZwOpenProcess con acceso PROCESS_TERMINATE, seguido de ZwTerminateProcess. Cuando el código en modo kernel llama a las funciones Zw*, el wrapper establece PreviousMode en KernelMode, lo que indica que los parámetros provienen de una fuente confiable, y Windows omite la validación de seguridad que aplicaría a los llamadores en modo usuario.

Figura 8: Componente en modo usuario que envía el PID objetivo al controlador de kernel mediante el IOCTL 0x223078 (Fuente: svchost.exe)

Figura 9: Implementación de KillProc (desde el controlador)

Conclusión

Esta intrusión demuestra cómo los ataques BYOVD se han convertido en un componente estándar del manual moderno de ransomware. Al reutilizar una herramienta forense legítima firmada hace más de 15 años, los actores de amenazas pueden evadir la aplicación de firma de controladores y obtener capacidades a nivel de kernel para terminar cualquier proceso de seguridad en el sistema.

La cadena de ataque con credenciales de VPN comprometidas y despliegue de un EDR killer sigue un patrón bien establecido observado en actividad precursora de ransomware.

Mira el video a continuación, grabado en vivo en Black Hat USA 2026. Greg Bailey, gerente de Operaciones de Seguridad de Huntress, explica paso a paso los ataques bring your own vulnerable driver (BYOVD) y qué pueden hacer los equipos de seguridad al respecto.

Recomendación

• Habilita MFA en todos los servicios de acceso remoto: el compromiso inicial fue posible porque la cuenta de SonicWall SSLVPN no tenía autenticación multifactor

• Revisa los registros de autenticación de VPN en busca de patrones de inicio de sesión anómalos e intentos de acceso denegados antes de una autenticación exitosa

• Habilita HVCI/Memory Integrity: garantiza que se aplique la lista de bloqueo de drivers vulnerables de Microsoft

• Alerta y monitorea servicios con nombres que imitan componentes OEM/hardware creados fuera del despliegue normal de software

• Implementa las reglas de bloqueo de drivers recomendadas por Microsoft mediante WDAC para bloquear drivers vulnerables conocidos

• Habilita la regla ASR "Bloquear el abuso de drivers firmados vulnerables explotados" para impedir que las aplicaciones escriban drivers vulnerables en el disco

Indicadores de compromiso