De W-2 a BYOVD: cómo una búsqueda de impuestos lleva a la eliminación de AV/EDR en modo kernel

Antecedentes 

Como dice el dicho, solo dos cosas son seguras en la vida: la muerte y los impuestos. Pero, con la fecha límite del 15 de abril para declarar impuestos acercándose rápidamente, hay una tercera certeza con la que los actores de amenazas han aprendido a contar: millones de usuarios buscando los mismos formularios de impuestos, bajo presión de tiempo, confiando en el primer resultado que ven en Google.

Durante una investigación retrospectiva de amenazas, el equipo de Huntress Tactical Response descubrió recientemente una campaña de malvertising a gran escala que ha estado activa desde al menos enero de 2026, dirigida a personas en EE. UU. que buscan documentos relacionados con impuestos. Los señuelos son específicamente formularios de impuestos de EE. UU. (W-2, W-9), y las páginas de destino falsas hacen referencia al cumplimiento con el IRS, abarcando empleados, freelancers, contratistas y pequeñas empresas durante la temporada de declaración de impuestos. La campaña abusa de Google Ads para distribuir instaladores falsos de ScreenConnect (ConnectWise Control), lo que finalmente entrega un eliminador de EDR tipo BYOVD que instala un controlador en modo kernel para cegar las herramientas de seguridad antes de una mayor vulneración. En toda nuestra base de clientes, reportamos más de 60 casos de sesiones falsas de ScreenConnect vinculadas a esta campaña y utilizadas como vector de acceso inicial.

La cadena de ataque tiene varias capas: dos servicios comerciales de cloaking filtran a investigadores y escáneres, instancias de prueba de ScreenConnect brindan acceso manual al teclado, un crypter de múltiples etapas evade los antivirus con un truco de asignación de memoria de 2 GB, y el payload final abusa de un controlador de audio de Huawei previamente no documentado para terminar procesos de Defender, Kaspersky y SentinelOne desde modo kernel.

Más allá de los señuelos con temática de impuestos, el directorio abierto y expuesto del actor de amenazas también reveló una página falsa de actualización de Chrome con comentarios de JavaScript en ruso, lo que sugiere un kit de ingeniería social más amplio y un desarrollador de habla rusa. La evidencia de una segunda intrusión revela el probable objetivo final: después de cegar el EDR, el atacante pasó de inmediato a volcar credenciales de LSASS y a una recolección masiva de credenciales lateral en toda la red usando herramientas como NetExec. Estas tácticas son consistentes con un manual de pre-ransomware o de agente de acceso inicial, lo que indica que el actor de amenazas está preparando el despliegue de ransomware o monetizando el acceso a la red mediante su reventa a otros operadores. En este blog, desglosamos cada capa.

Puntos clave

• Google Ads sigue siendo tendencia. Toda la cadena de ataque comienza con un resultado de búsqueda patrocinado. Sin exploit kit, sin correo de phishing, solo un anuncio de Google a partir de búsquedas como “W2 tax form” y “W-9 Tax Forms 2026” que es indistinguible de un resultado legítimo. El malvertising se ha convertido en el vector de acceso inicial preferido para campañas como esta porque escala sin esfuerzo y apunta a los usuarios en el momento exacto en que buscan algo.
• El cloaking convierte los cierres en un juego del gato y el ratón. La configuración de cloaking de doble capa (JustCloakIt del lado del servidor + Adspect del lado del cliente) hace que los propios revisores de anuncios de Google, los escáneres de seguridad y los investigadores vean una página limpia. Solo las víctimas reales con navegadores reales en hardware real reciben el payload. Mientras servicios como Adspect anuncien abiertamente “sin reglas de contenido” por $299 al mes, las campañas de malvertising seguirán colándose por la revisión de las plataformas.
• Apilar herramientas RMM indica persistencia, no conveniencia. Cuando varios relés de ScreenConnect y herramientas de respaldo como FleetDeck aparecen en el mismo endpoint en cuestión de horas, no es coincidencia: es un atacante construyendo redundancia en su acceso. Esta campaña desplegó de forma constante dos o tres instancias de relé por endpoint en distintas organizaciones, asegurando poder sobrevivir a una remediación parcial.
• BYOVD no es solo para APT. Esta campaña muestra a actores de amenazas comunes usando un controlador firmado previamente no documentado para eliminar EDR desde modo kernel. Los atacantes no necesitaron encontrar un día cero, solo necesitaron un controlador firmado con un manejador de IOCTL descuidado.
• El señuelo de impuestos es solo una página del manual. El directorio abierto del mismo operador reveló una página falsa de actualización de Chrome junto a los señuelos con temática de impuestos, ambos obteniendo payloads de la misma infraestructura de 4sync. Los comentarios en ruso en el código fuente de JavaScript sugieren un desarrollador de habla rusa. Esta no es una operación de campaña única; la infraestructura compartida y las múltiples plantillas de ingeniería social apuntan a un operador que ejecuta campañas de señuelos en paralelo, adaptadas a lo que genere clics.

Cómo sucedió

El usuario buscó “W2 tax form”, y el primer resultado fue un enlace de Google Ads que redirigía a una página maliciosa que distribuía un instalador falso de ScreenConnect. El historial del navegador revela la cadena de redirección: el clic en el anuncio de Google Ads llevó a anukitax[.]com/forminw9/, que luego redirigía a bringetax[.]com/humu/, la página real de distribución del falso ScreenConnect. El payload en sí estaba alojado en 4sync, una plataforma de intercambio de archivos. Al momento del análisis, la página ya no distribuía payloads, pero el actor de amenazas dejó el directorio abierto, lo que nos dio algunas pistas.

Figura 1: Página falsa de distribución de ScreenConnect

Señuelo falso de actualización de navegador

Al explorar el directorio abierto también se reveló una página falsa de actualización de Chrome alojada en grinvan[.]com/vims/browser/. Esta página no está relacionada con el señuelo de impuestos, pero parece formar parte del mismo kit de herramientas del operador. La página presenta un aviso convincente de actualización de Google Chrome, diciéndole a la víctima "To CONTINUE you need to update your browser" y guiándola a través de un proceso de tres pasos: hacer clic en "Update Chrome", encontrar la descarga, y "unzip updater.zip and run updater.exe."

Por debajo, la página obtiene su payload de la misma plataforma de uso compartido de archivos 4sync utilizada en la campaña de impuestos. Cuando la víctima hace clic en el botón de actualización, el JavaScript obtiene la dirección IP y la geolocalización de la víctima mediante ipapi.co y envía una notificación en tiempo real al Bot de Telegram del operador, con la IP, el país y la URL de referencia de la víctima, lo que le da al actor de amenazas visibilidad inmediata de cada descarga exitosa. Luego, el payload se entrega de forma silenciosa a través de un iframe oculto que apunta a un enlace de descarga directa de 4sync.

El código fuente de JavaScript contiene comentarios en ruso a lo largo de todo el archivo, incluidos “Файл скачан!” (Archivo descargado), “Ошибка получения геоданных” (Error al obtener datos de geolocalización) y “Telegram уведомление отправлено” (Notificación de Telegram enviada), lo que da un indicio del idioma del desarrollador detrás de esta página.

Figura 2: Señuelo falso de actualización del navegador Google

Figura 3: Los comentarios en ruso revelan el idioma del desarrollador, mientras que el código recopila la dirección IP y la geolocalización de la víctima mediante ipapi[.]co y envía una notificación de Telegram en tiempo real al operador con cada descarga

Cloaking de Adspect 

El directorio expuesto reveló la configuración de cloaking del actor de amenazas. El cloaking es una técnica donde un sitio web malicioso muestra contenido diferente según quién lo visite: las víctimas reales ven el payload malicioso, mientras que los escáneres de seguridad, los revisores de anuncios, los Bots y los investigadores ven en su lugar una "página segura" inofensiva. Los actores de amenazas usan servicios comerciales de cloaking para mantener sus campañas de malvertising activas por más tiempo al evadir la detección de plataformas como Google Ads y proveedores de seguridad.

En este caso, la página de destino usa un sistema de distribución de tráfico (TDS) basado en PHP e impulsado por Adspect, un servicio comercial de cloaking que ha sido cada vez más explotado por actores de amenazas en campañas de malvertising y de cadena de suministro.

Adspect se promociona como una plataforma de "cloaking a prueba de balas" que "oculta de forma confiable cada plataforma publicitaria", con planes que van de $299 a $999 al mes. El servicio anuncia abiertamente una política de no hacer preguntas, y afirma que "no les importa lo que publiques y no aplican ninguna regla de contenido". Es compatible con el cloaking en Google Ads, Facebook, TikTok, Bing y otros, mientras bloquea activamente escáneres de seguridad, incluidos Google Safe Browsing, VirusTotal, Kaspersky, Confiant y GeoEdge. La plataforma usa huellas digitales de JavaScript, huellas digitales de TCP/IP y SSL/TLS, listas de bloqueo de IP que cubren más de 2 mil millones de direcciones IPv4, y un clasificador de aprendizaje automático bayesiano para distinguir a las víctimas reales de investigadores y Bots.

El archivo index de la página de destino contiene un script de integración de Adspect que hace una llamada a rpc.adspect[.]net/v2/ con el ID de stream f252d22c-19c3-487b-af3a-3d979b168a6d. En cada visita, el script recopila una huella digital del visitante, que incluye propiedades del navegador, información del renderizador WebGL, dimensiones de pantalla, desfase de zona horaria, comportamiento de la consola, compatibilidad con eventos táctiles y si la página se ejecuta dentro de un iframe; luego envía todo mediante POST de vuelta al backend de Adspect para obtener un veredicto en tiempo real.

El payload de huellas digitales está incrustado como un blob codificado en base64 dentro del atributo data-digest de una etiqueta <img> falsa. La imagen falla intencionalmente al cargar, lo que activa el controlador onerror, que decodifica y ejecuta el generador de huellas digitales en JavaScript.

El JavaScript decodificado recopila un objeto de huella digital que incluye:

• window: enumera todas las propiedades usando Object.getOwnPropertyNames(). Un navegador Chrome real tiene un objeto window.chrome con subpropiedades como chrome.runtime y chrome.loadTimes. Las versiones antiguas de Chrome headless carecían por completo de este objeto, e incluso el Chrome headless más reciente (posterior a 2023) puede tener diferencias sutiles en la lista de propiedades. Los navegadores controlados por Selenium también filtran propiedades adicionales, como identificadores de controlador con el prefijo cdc_. Al volcar cada nombre de propiedad, el backend de Adspect puede comparar la lista completa con perfiles conocidos como válidos para cada navegador y detectar discrepancias.
• navigator: se vuelcan todas las propiedades, sobre todo navigator.webdriver. Por defecto, Puppeteer y Selenium establecen navigator.webdriver = true para indicar que el navegador está bajo control de automatización. Aunque los desarrolladores de Bots suelen parchar esta marca, la forma en que la sobrescriben (por ejemplo, mediante Object.defineProperty) puede dejar rastros detectables en comparación con un navegador donde la propiedad es nativamente undefined.
• document.documentElement.attributes: enumera todos los atributos del elemento <html>. Los frameworks de automatización y las extensiones del navegador a veces inyectan atributos no estándar en la raíz del DOM (por ejemplo, atributos data- de Playwright, o atributos agregados por herramientas de seguridad de contenido), que no existirían en una visita de navegador limpia.
• WebGL UNMASKED_VENDOR_WEBGL / UNMASKED_RENDERER_WEBGL: consulta la cadena del renderizador de la GPU mediante la extensión WEBGL_debug_renderer_info. Una máquina real devuelve su GPU real (por ejemplo, "NVIDIA GeForce RTX 3080"), mientras que las máquinas virtuales y los entornos aislados exponen renderizadores por software como "Google SwiftShader" (el respaldo por software de Chrome), "llvmpipe" (el renderizador por CPU de Mesa) o "VMware SVGA 3D", todos indicadores sólidos de un entorno de análisis.
• Detección de iframe: window.self !== window.top verifica si la página se carga dentro de un iframe. Muchos entornos aislados de análisis automatizado y escáneres de URL renderizan páginas dentro de iframes para aislarlas, por lo que esto marca esos entornos.
• Detección de DevTools: crea una función con un toString personalizado, la pasa a console.log, y cuenta cuántas veces se llama a toString. En un navegador normal, console.log llama a toString una sola vez. Pero cuando DevTools está abierto, el panel de vista previa de la consola llama a toString una vez adicional para renderizar el objeto, por lo que un conteo mayor a 1 indica que alguien tiene el inspector abierto y probablemente esté analizando la página.

Luego, la huella digital completa se envía mediante un formulario oculto creado dinámicamente con un POST de vuelta a la misma página, donde la integración de Adspect del lado de PHP lo reenvía a rpc.adspect[.]net/v2/ para su clasificación.

Según la respuesta del backend de Adspect, el script admite una amplia gama de acciones de entrega:

• local - sirve un archivo directamente desde el sistema de archivos local del servidor (el payload malicioso está alojado en el mismo equipo)
• proxy - obtiene contenido de una URL remota mediante cURL y lo sirve al visitante, reescribiendo todos los enlaces internos para enrutarlos a través del proxy, de modo que el visitante nunca ve la URL real del backend
• fetch - similar a proxy, pero un simple pase directo sin reescritura de URL
• 301-308 - redirecciones HTTP a la URL de destino
• iframe - carga el destino en un iframe de página completa para ocultar la URL real de la barra de direcciones
• noop - devuelve null, lo que permite que la página segura/blanca original se renderice con normalidad como si nada hubiera pasado; esto es lo que ven los investigadores y los bots
• php - eval($target) para la ejecución arbitraria de código del lado del servidor, lo que le da al operador total flexibilidad sobre lo que se sirve a cada visitante

Segunda capa de ocultamiento: JustCloakIt (jcibj[.]com)

Además de Adspect, el archivo index.php de la landing page contiene una segunda capa de ocultamiento. Este script PHP usa ofuscación de códigos de caracteres para ocultar su URL hxxps://jcibj[.]com/pcl.php.

Al investigar jcibj[.]com en Validin se revela la conexión: el certificado TLS de este dominio (emitido por GoDaddy, válido desde el 21/05/2025) cubre jcibj[.]com, bjtrck[.]com, cdn.justcloakit[.]com, client.justcloakit[.]com, lo que lo vincula directamente con JustCloakIt (JCI), una plataforma comercial de ocultamiento ampliamente usada en publicidad black hat. El servidor de origen se encuentra en 192.175.104.189 (AS 32613, Leaseweb Canada).

Figura 4: DNS pasivo de Validin que muestra el certificado TLS en jcibj[.]com compartiendo SAN con cdn.justcloakit.com, client.justcloakit.com y bjtrck.com

En cada visita, el script envía datos del visitante por POST al backend de JCI, incluyendo IP, User-Agent, Referer, la cadena de consulta completa (que contiene el gclid de Google Ads) y una cookie de seguimiento. La solicitud está vinculada al ID de operador 507798 y al ID de usuario fxv76taie649fg9qffuyg34aj. El backend responde con un veredicto que determina si el visitante ve la página maliciosa o una página segura.

Los dos servicios de ocultamiento están apilados en el mismo index.php: el filtrado del lado del servidor de JCI se ejecuta primero, mientras que Adspect da una segunda capa con huellas digitales de JavaScript del lado del cliente.

Actividad de ScreenConnect no autorizado y RMM

Como se mencionó antes, identificamos más de 60 instancias de ScreenConnect no autorizado en nuestra base de clientes vinculadas a esta campaña. El caso detallado aquí es uno de muchos. En distintas organizaciones, observamos un patrón constante: el actor de amenazas desplegó múltiples instancias de relay de ScreenConnect en cada endpoint comprometido, junto con herramientas RMM adicionales para redundancia.

En este equipo en particular, el instalador inicial de ScreenConnect se entregó como form_w9.msi. Un indicador clave de que se trata de una instancia no autorizada: el nombre del relay instance-itsd8c-relay.screenconnect[.]com usa el patrón de prefijo instance-, característico de las instancias gratuitas o de prueba en la nube de ConnectWise, y los parámetros de sesión incluyen y=Guest, el rol predeterminado para configuraciones de prueba o no administradas. Las implementaciones empresariales legítimas suelen usar dominios personalizados o subdominios dedicados con roles de sesión con nombre.

El actor de amenazas no se detuvo en una sola. La cronología muestra varias sesiones de ScreenConnect implementadas en el mismo equipo: una segunda instancia de prueba (instance-sl1mb9-relay.screenconnect.com, sesión ba82af8c27011f84) apareció ese mismo día. Días después, surgió una tercera instancia de ScreenConnect que usaba un relay autoalojado completamente distinto en gripsmonga[.]sbs. Este patrón de apilar varios relays, combinando instancias de prueba en la nube, se repitió de forma consistente en equipos comprometidos de otras organizaciones. Junto con ScreenConnect, el atacante también instaló FleetDeck Agent como herramienta de RMM de respaldo.

Poco después, el atacante ejecutó el payload a través de la sesión de ScreenConnect:

-  C:\Windows\SystemTemp\ScreenConnect\25.9.5.9473\crypteds.exe

El archivo resultó ser un crypter de varias etapas que finalmente descifra y carga HwAudKiller, una herramienta BYOVD (Bring Your Own Vulnerable Driver) que coloca un controlador de kernel llamado “Havoc” para terminar procesos de AV/EDR. Veamos cómo el crypter deja caer el controlador de HwAudKiller.

Para efectos de seguimiento, lo llamaremos “FatMalloc” y más adelante entenderás por qué.

Una mirada más de cerca a FatMalloc

Antianálisis y ejecución indirecta

FatMalloc (crypted.exe) es un binario MinGW de 64 bits que es discreto y nunca llama a su payload directamente. En cambio, la cadena de ejecución usa varias técnicas de evasión antes de tocar el blob cifrado.

Asignación de 2 GB de memoria (evasión de AV/sandbox)

FatMalloc asigna 2 GB de memoria, los llena con ceros y luego los libera. Esto cumple un doble propósito. Primero, algunos sandboxes suelen ejecutarse con memoria limitada, así que una asignación de 2 GB probablemente falle, y como el payload solo se ejecuta dentro de la rama if (Block), una asignación fallida hace que el malware salga silenciosamente sin llegar nunca al código malicioso. Segundo, los motores de AV tienen presupuestos estrictos de tiempo y recursos al escanear archivos: sus emuladores no pueden darse el lujo de simular un memset de 2 mil millones de bytes, así que agotarán el tiempo y seguirán adelante antes de llegar al payload real. Ahora ya sabes de dónde viene el nombre “FatMalloc”.

Si pasa la verificación de 2 GB, el payload marca el blob de shellcode cifrado (188.837 bytes) como PAGE_EXECUTE_READWRITE.

Figura 5: función de asignación de 2 GB de memoria de FatMalloc

Ejecución indirecta mediante timeSetEvent

En lugar de llamar directamente al shellcode, el crypter usa la API del temporizador multimedia de Windows para invocarlo mediante una función de retorno de llamada. Esta es una técnica de evasión bien conocida: en vez de usar métodos de ejecución obvios como CreateThread apuntando a memoria RWX o una call/jmp directa a la dirección del shellcode, FatMalloc pasa la dirección del shellcode como el parámetro de datos dwUser (4.º argumento) a timeSetEvent, con una pequeña función envoltorio fptc como la función de retorno de llamada real (3.er argumento). Cuando el temporizador se activa después de 100 ms, winmm.dll invoca la función de retorno de llamada fptc, que a su vez llama al shellcode a través del puntero dwUser. Las herramientas de seguridad que monitorean la creación directa de hilos dirigidos a regiones RWX o transferencias sospechosas de flujo de control pueden pasar esto por alto porque la ejecución real se origina dentro del propio despacho del temporizador de winmm.dll, una DLL legítima del sistema que llama a una función de retorno de llamada, la cual a su vez llama al shellcode.

Figura 6: La dirección del shellcode se pasa como datos de usuario a timeSetEvent, que lo invoca indirectamente a través de la función de retorno de llamada fptc

Este patrón de ejecución basado en funciones de retorno de llamada es una de muchas variaciones documentadas; se ha observado que otro malware abusa de CreateThreadpoolWait, EnumDateFormats, EnumWindows y docenas de otras API de Windows que aceptan punteros de función como funciones de retorno de llamada para el mismo propósito.

Figura 7: Fragmento del shellcode incrustado

Desencriptación del shellcode

A partir del desplazamiento 0xF4 el shellcode está encriptado con XOR. Un fragmento decodificador al inicio del blob gestiona la desencriptación mediante un esquema XOR basado en bloques: los datos encriptados se dividen en bloques de 32 bytes donde el primer byte de cada bloque sirve como clave XOR para los 31 bytes restantes. Un valor 0xFB29FB29 marca el final del flujo encriptado. El decodificador se ejecuta en el mismo lugar, sobrescribiendo los datos encriptados con el shellcode del cargador decodificado, y luego salta directamente a él.

Figura 8: Decodificador XOR: cada bloque de 32 bytes se combina con XOR usando su primer byte (v9), repitiendo hasta el marcador 0xFB29FB29

Figura 9: Fragmento del shellcode encriptado

Shellcode del cargador con configuración CHOC

El shellcode decodificado resuelve API construyendo cadenas carácter por carácter en la pila para evadir la detección estática de cadenas. Una curiosidad divertida: cada cadena de nombre de API lleva el prefijo de la letra “Y” (por ejemplo, “YLocalFree”, “Ykernel32", “Yntdll”). El resolvedor luego hace string + 1 para saltar la "Y" antes de pasar el nombre real de la API.

¿Por qué “Y”? No tengo idea. Pero sí logra evitar que el nombre de API sin procesar quede al inicio del búfer de la pila, lo que dificulta un poco la coincidencia de patrones para los escáneres de memoria.

Figura 10: El nombre de la función se almacena como “YLocalFree” y se pasa a mw_resolve_api, saltando la “Y” inicial antes de llamar a GetProcAddress

El bloque de configuración CHOC

El encabezado de 40 bytes del bloque de configuración CHOC contiene el marcador mágico, el tamaño del encabezado (0x28), el tamaño de los datos comprimidos (0x21A31) y la clave XOR usada para desencriptar el payload final.

Figura 11: Bloque de configuración CHOC

Diseño del encabezado CHOC:

Figura 12: Cada byte se desencripta combinando con XOR la fuente con la clave (0x0D) más el byte previamente desencriptado

Después de la desencriptación XOR, los primeros cuatro bytes del búfer desencriptado contienen el tamaño del PE sin comprimir (195.072 bytes); esto no forma parte del PE en sí, sino un campo de tamaño que consume el cargador. El cargador asigna un segundo búfer y llama a RtlDecompressBuffer con el formato 0x102 (COMPRESSION_FORMAT_LZNT1 | COMPRESSION_ENGINE_MAXIMUM) para descomprimir los datos restantes en el PE final.

Después de la descompresión, el cargador verifica que la salida comience con un encabezado MZ válido y una firma PE, y luego la mapea en memoria usando su cargador de PE incorporado con procesamiento de reubicación. Curiosamente, el shellcode también resuelve API de hospedaje de .NET CLR (CorBindToRuntime y CLRCreateInstance de mscoree.dll), lo que sugiere que el cargador es un marco genérico diseñado también para manejar payloads de ensamblados .NET, aunque en este caso el payload final es un PE x64 nativo.

HwAudKiller

El payload que surge de esta cadena de desempaquetado es HwAudKiller, una herramienta BYOVD (Bring Your Own Vulnerable Driver) diseñada para terminar procesos de AV/EDR usando un controlador de kernel legítimo y firmado. El binario se ejecuta completamente en memoria dentro del proceso crypteds.exe y nunca toca el disco como archivo independiente. Su ruta PDB, C:\Users\Administrator\Downloads\Hwk\x64\Release\HwAudKiller.pdb, confirma el nombre del proyecto del desarrollador.

Al ejecutarse, HwAudKiller imprime “[+] Havoc Process Terminator” e intenta abrir un identificador hacia el dispositivo \\.\HWAudioX64. Si el controlador aún no está cargado, desencripta un controlador de kernel incrustado (47.240 bytes) usando XOR con una clave rotativa de 8 bytes (41 73 61 40 41 31 61 40), lo escribe en %TEMP%\Havoc.sys y lo carga como un servicio de kernel mediante sc create Havoc binPath= <path> type= kernel start= demand seguido de sc start Havoc.

Una vez que el controlador se carga, HwAudKiller entra en un bucle continuo: toma una instantánea de todos los procesos en ejecución con CreateToolhelp32Snapshot, recorre la lista de procesos con Process32First / Process32Next, y compara cada nombre de proceso con una lista de eliminación codificada de 23 entradas. Para cada coincidencia, envía el PID objetivo al controlador del kernel mediante DeviceIoControl con el código IOCTL 0x2248DC. Después de cada intento de eliminación, verifica la terminación llamando a OpenProcess; si el handle no es válido, se confirma que el proceso está muerto. El bucle se repite con un retraso de 100 ms, volviendo a eliminar los procesos si vuelven a generarse.

Procesos objetivo:

El controlador incrustado: controlador de audio de Huawei (BYOVD)

HwAudKiller incrusta un controlador de kernel de Huawei legítimo y firmado que usa para terminar procesos protegidos desde el modo kernel. Al momento de escribir esto, este controlador no aparece en la base de datos de LOLDrivers, en la lista de bloqueo de controladores recomendada por Microsoft, ni en ninguna investigación pública previa, lo que convierte a este en el primer caso documentado de este controlador de audio de Huawei siendo usado como arma mediante BYOVD.

Como se mencionó antes, el controlador descifrado se guarda en el disco como %TEMP%\Havoc.sys y se registra como un servicio de kernel llamado Havoc. El nombre de archivo original del controlador en su información de versión es HWAuidoOs2Ec.sys, firmado por Huawei Device Co., Ltd. El controlador crea el dispositivo \Device\HWAudioDevX64 con un enlace simbólico en \DosDevices\HWAudioX64, que el componente de modo usuario abre como \\.\HWAudioX64. Cuando HwAudKiller envía el IOCTL 0x2248DC con un PID de 4 bytes como búfer de entrada, el controlador termina el proceso objetivo desde el modo kernel, evitando cualquier protección de modo usuario en la que confían los productos de seguridad. Debido a que el controlador está legítimamente firmado por Huawei, Windows lo carga sin problema a pesar de la aplicación de firma de controladores (DSE).

Dentro del controlador

El controlador (HWAuidoOs2Ec.sys) es un controlador de kernel diseñado originalmente para el hardware de audio de laptops Huawei. Al inicializarse, registra el mensaje “[Os2EC] Enter DriverEntry” y crea el dispositivo \Device\HWAudioDevX64 con un descriptor de seguridad que restringe el acceso a SYSTEM y Administradores.

La debilidad explotable se encuentra en el controlador de despacho de IOCTL. Cuando recibe el IOCTL de eliminación, el controlador acepta un búfer de entrada de 4 bytes que contiene un PID, lo copia mediante memcpy_s, y lo pasa directamente a una función de eliminación. Esta función llama a ZwOpenProcess con PROCESS_ALL_ACCESS (0x1FFFFF) para obtener un handle de kernel al objetivo, y luego llama inmediatamente a ZwTerminateProcess para eliminarlo.

Figura 13: Función de eliminación descompilada del controlador de Huawei - mw_ZwOpenProcess_wrapper abre un handle al PID objetivo con PROCESS_ALL_ACCESS, luego ZwTerminateProcess lo elimina, y ZwClose libera el handle. No se realiza ninguna validación sobre el proceso objetivo.

Figura 14: Línea de tiempo de detección de Huntress que muestra la cadena de ataque: el instalador fraudulento de ScreenConnect (form_w9.msi) distribuido mediante malvertising, dos instancias de prueba de ScreenConnect apiladas en el mismo equipo (instance-itsd8c e instance-sl1mb9) y el crypter FatMalloc (crypteds.exe)

Descubriendo otra intrusión

Mientras buscábamos más instancias del driver de Havoc, descubrimos una intrusión aparte en la que el acceso inicial parece haber sido un compromiso de VPN, según la actividad que se originó en una estación de trabajo que identificamos como controlada por el atacante. En este caso, el actor de amenazas usó una variante distinta de HwAudKiller (nombrada internamente sent.exe, con una ruta PDB que hace referencia a una carpeta de proyecto llamada firskill: C:\Users\Administrator\Downloads\firskill\x64\Release\HwAudKiller.pdb) con una lista de eliminación ampliada que suma cinco procesos de FortiEDR a los objetivos originales.

El ataque siguió una progresión rápida y manual. Después de autenticarse mediante RDP desde una estación de trabajo maliciosa conocida, el actor de amenazas ejecutó sent.exe, que instaló el driver de kernel de Havoc y creó el servicio, de forma idéntica a la variante de la campaña fiscal. Con el eliminador de EDR en ejecución, el atacante avanzó rápidamente hacia la recolección de credenciales: usó comsvcs.dll mediante rundll32.exe para volcar la memoria del proceso LSASS, una técnica conocida de robo de credenciales que abusa de una DLL legítima de Windows para crear un minivolcado de LSASS.

-  cMd.ExE /Q /c for /f "tokens=1,2 delims= " %A in ('"tasklist
   /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe
   C:\windows\System32\comsvcs.dll, #+000024 %B \Windows\Temp\
   <random>.log full

A partir de ahí, el atacante pasó al reconocimiento de red usando NetScan, una herramienta de descubrimiento de red, y preparó una lista de direcciones IP objetivo. Luego implementó NetExec (nxc), una herramienta de posexplotación, para automatizar el volcado masivo de credenciales en toda la red usando los módulos lsassy y --dpapi, intentando extraer credenciales de múltiples equipos de forma simultánea mediante una cuenta de administrador comprometida.

La lista de eliminación ampliada de esta variante, que suma FortiEDR junto a los objetivos originales de Defender, Kaspersky y SentinelOne, sugiere que la herramienta se mantiene y se actualiza activamente a medida que los operadores se encuentran con distintos productos de seguridad en los entornos de las víctimas. Cabe destacar que esta compilación contiene un error en el que dos nombres de proceso (sentinelstaticenginescanner.exe y avpui.exe) quedan concatenados debido a la falta de un terminador nulo, una señal de desarrollo activo pero algo descuidado.

¿Qué podemos aprender? 

Esta campaña ilustra cómo las herramientas comunes han reducido la barrera para los ataques sofisticados. El actor de amenazas no necesitó exploits personalizados ni capacidades de nivel estatal: combinó servicios de encubrimiento disponibles comercialmente (Adspect y JustCloakIt), instancias gratuitas de ScreenConnect, un crypter listo para usar y un driver firmado de Huawei con una debilidad explotable para construir una cadena de ataque completa que va desde una búsqueda en Google hasta la terminación de EDR en modo kernel.

Un patrón constante en los endpoints comprometidos fue el apilamiento rápido de múltiples herramientas de acceso remoto. Después de establecer el relé fraudulento inicial de ScreenConnect, el actor de amenazas desplegó instancias de prueba adicionales de ScreenConnect en el mismo endpoint, a veces dos o tres en cuestión de horas, además de herramientas de RMM de respaldo como FleetDeck. Esta redundancia garantiza que el atacante mantenga el acceso incluso si se descubre y elimina uno de los relés. Los defensores deben tratar la aparición de múltiples instancias de ScreenConnect en un mismo endpoint, en especial instancias de prueba que no desplegaron ellos mismos, como un fuerte indicador de compromiso.

El uso de un controlador de audio de Huawei no documentado previamente (HWAuidoOs2Ec.sys) como arma BYOVD es particularmente notable. A pesar de ser un controlador legítimo y firmado de un importante proveedor de hardware, expone un IOCTL de terminación de procesos en modo kernel sin ninguna validación.

Las técnicas de evasión del crypter, una asignación de memoria de 2 GB para agotar los emuladores de antivirus, ejecución indirecta de shellcode mediante callbacks de timeSetEvent y una cadena de descifrado de varias capas, muestran los niveles de ofuscación empaquetados en la entrega. El prefijo "Y" en cada cadena de API fue un hallazgo curioso.

Para los defensores, las principales oportunidades de detección están en los extremos de esta cadena: instancias de prueba fraudulentas de ScreenConnect, binarios sospechosos ejecutados desde los directorios de trabajo de ScreenConnect (C:\Windows\SystemTemp\ScreenConnect\<ScreenConnect_version>\), la creación de un servicio de kernel llamado "Havoc" y la presencia de Havoc.sys en el directorio TEMP.

Detección

Yara

FatMalloc

https://github.com/RussianPanda95/Yara-Rules/blob/main/FatMalloc/win_mal_fatmalloc.yar

HwAudKiller

https://github.com/RussianPanda95/Yara-Rules/blob/main/FatMalloc/HwAudKiller.yar

Recomendaciones

Capacitación de concientización para usuarios: Esta campaña comienza con una búsqueda en Google. Hay que capacitar a los empleados para que reconozcan que los resultados de Google Ads no son inherentemente confiables, y que los resultados patrocinados que aparecen en la parte superior para formularios fiscales, documentos gubernamentales y herramientas financieras son un vector común de malvertising. La capacitación debe hacer énfasis en descargar los formularios fiscales solo desde IRS.gov o portales conocidos del empleador.

Inclusión en la lista de aceptados de RMM en lugar de bloqueo: En lugar de intentar bloquear cada instancia maliciosa de ScreenConnect, las organizaciones deben mantener una lista de aceptados de herramientas de RMM y nombres de los relés aprobados. Cualquier instancia de ScreenConnect que no esté en la lista aprobada, en particular aquellas que usan patrones de relé de prueba instance-* o roles de sesión y=Guest, debe marcarse e investigarse. Si tu organización no usa ScreenConnect, considera bloquearlo por completo.

Monitoreo de carga de controladores de kernel: Genera alertas ante la creación de servicios de controladores de kernel (type= kernel) desde rutas no estándar, en especial %TEMP%. El controlador Havoc se cargó desde el directorio temporal del usuario, lo cual nunca es una ubicación legítima para un controlador de kernel. El ID de evento 6 de Sysmon (controlador cargado) y el ID de evento 7045 (servicio instalado) son fuentes de datos clave en este caso.

Monitorea los directorios de trabajo de ScreenConnect: Los ejecutables colocados y ejecutados desde los directorios de trabajo de ScreenConnect (C:\Windows\SystemTemp\ScreenConnect\) merecen un escrutinio adicional. Si bien los administradores legítimos pueden implementar scripts o herramientas a través de sesiones de ScreenConnect, los binarios no firmados o desconocidos ejecutados desde estas rutas, en particular los que generan procesos secundarios, cargan controladores de kernel o modifican la configuración de seguridad, deben investigarse.

Indicadores de compromiso (IoC)