SprySOCKS llega a Windows: un backdoor que eleva el sigilo con drivers de kernel, DLL side-loading y un posible bootkit de firmware

La reciente detección por parte de investigadores de una variante para Windows de SprySOCKS —un backdoor que hasta hace poco se consideraba exclusivo de Linux— marca un salto significativo en la capacidad operativa de actores de ciberespionaje que ya mostraban ambición transplataforma. El hallazgo de las versiones internas WIN_DRV y WIN_PLUS revela no solo portabilidad del código sino una evolución: integración de controladores de kernel y técnicas de carga lateral (DLL side‑loading) para ocultar presencia y comunicaciones.

En lo técnico, las muestras Windows mantienen el mismo protocolo de comando y control, cifrado y conjunto de comandos que la versión Linux, pero lo hacen aprovechando mecanismos nativos de Windows. WIN_DRV carga un driver de kernel (identificado en los análisis como RawWNPF y desplegado mediante un driver de carga cifrado) que le permite camuflar conexiones de red, procesos y entradas de registro, y además desplegar una técnica de desvío de tráfico TCP para ocultar su puerto de escucha real. WIN_PLUS, por su parte, abusa del servicio Print Spooler para ejecutar un primer cargador que actúa como procesador de impresión y finalmente inyecta el backdoor en svchost.exe.

Estos detalles no son anecdóticos: la combinación de drivers kernel, side‑loading y abuso de servicios legítimos complica la detección tradicional y exige controles de seguridad a múltiples niveles. El uso de drivers permite a los operadores elevar significativamente su sigilo frente a herramientas de monitoreo de usuario, y la dependencia de tareas programadas y cadenas de carga legítimas ataca las zonas ciegas de muchas arquitecturas corporativas.

El contexto operativo también es relevante. SprySOCKS ha sido relacionado con un clúster vinculado a grupos con nexos chinos, y muestra genealogía con familias como Trochilus y RedLeaves, lo que indica reutilización de código y tradecraft compartido entre campañas. Históricamente estos actores han explotado vulnerabilidades N‑day en servicios expuestos (Fortinet, Microsoft Exchange, GitLab, Telerik, Zimbra), por lo que la presencia de una variante Windows aumenta el riesgo para infraestructuras críticas y organismos públicos en múltiples geografías.

Adicionalmente, hay indicios limitados de uso de un UEFI bootkit probablemente aprovechando la vulnerabilidad conocida como CVE‑2023‑24932, lo que eleva la gravedad: un compromiso a nivel de firmware puede sobrevivir reinicios y muchas mitigaciones a nivel de sistema operativo. Para detalles técnicos sobre esa vulnerabilidad consulte la guía oficial de Microsoft: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-24932. Para un seguimiento general de la investigación y el contexto histórico de SprySOCKS y campañas relacionadas, los lectores pueden revisar recursos de firmas y análisis de la industria en los sitios de inteligencia de proveedores como ESET: https://www.welivesecurity.com/.

¿Qué deben hacer los equipos de seguridad ahora mismo? En primer lugar, priorizar parches y mitigaciones para vectores de acceso público conocidos; muchas intrusiones previas explotaron vulnerabilidades corregidas tiempo atrás. Si su organización expone servicios como Fortinet, Exchange, GitLab, Telerik o Zimbra, verifique parches, registros de acceso y alertas de explotación N‑day. En segundo lugar, endurecer controles en endpoints: deshabilitar Print Spooler en servidores que no lo requieran, aplicar políticas de bloqueo de side‑loading (por ejemplo mediante AppLocker o Windows Defender Application Control), y exigir código firmado y verificaciones de integridad para drivers de kernel.

La detección debe combinar telemetría de red y endpoint. Busque conexiones inusuales sobre TCP/UDP y WebSocket, picos de tráfico redirigido a puertos aleatorios, cargas y ejecuciones de DLL desde rutas atípicas, presencia de tareas programadas que lancen cadenas de carga, y la aparición de drivers con nombres o hashes sospechosos. Las soluciones EDR con capacidad de instrumentación de kernel son especialmente útiles para identificar drivers ocultos y hooks en espacio de kernel. En entornos donde exista sospecha de compromiso persistente, considere la validación del firmware y el estado de Secure Boot, y la reconstrucción de hosts si se confirma un bootkit.

En respuesta a incidentes, aísle los sistemas afectados, capture memoria y volcado de disco para análisis forense y busque indicadores de lateralidad: creación de cuentas, movimientos por RDP/SMB, credenciales exfiltradas y herramientas de administración remota si aparecen. Notifique a equipos internos de respuesta y a las autoridades o CERTs correspondientes, y coordine intercambio de IoC con la comunidad para bloquear dominios y hashes conocidos.

Finalmente, esto refuerza una lección persistente: la reutilización de código entre plataformas y la adaptación de técnicas avanzadas (drivers, UEFI, side‑loading) transforman problemas que parecían limitados a un ecosistema en riesgos de amplia superficie. La defensa moderna requiere visión cross‑stack, con parcheo oportuno, políticas de ejecución restrictivas, telemetría centralizada y pruebas regulares de integridad de firmware y drivers.