Los equipos de Symantec y Carbon Black Threat Hunter Team detectaron una instancia activa del rootkit Daxin en un host comprometido perteneciente a la filial taiwanesa de un fabricante multinacional de alta tecnología. En el mismo host se identificó un backdoor previamente desconocido, Stupig, que utiliza un mecanismo de persistencia no trivial mediante la sustitución de la DLL de distribución de teclado de Windows. Ambas muestras llevan marcas de tiempo de compilación fechadas a principios de 2013, mientras que la telemetría desde la máquina infectada comenzó a recibirse solo el 12 de mayo de 2026, lo que plantea la cuestión de una presencia potencialmente prolongada y no detectada del atacante en la red. Las organizaciones que utilicen versiones obsoletas de software y JDK en entornos de producción deberían realizar una auditoría en busca de indicadores de compromiso similares.
Características técnicas de Daxin
Daxin (srt64.sys) es un controlador de nivel kernel de Windows, documentado públicamente por primera vez por Symantec en marzo de 2022. Según los investigadores, existen indicios de su uso en ataques dirigidos contra organismos gubernamentales y entidades de infraestructuras críticas desde 2013.
La característica arquitectónica clave de Daxin es la ausencia de conexiones salientes directas hacia la infraestructura de mando y control. En su lugar, el rootkit intercepta el tráfico TCP entrante, lo analiza en busca de determinados patrones e inserta las comunicaciones cifradas con el operador dentro de conexiones legítimas ya existentes. Este enfoque dificulta enormemente su detección mediante herramientas de monitorización de red.
Además, según Broadcom, Daxin admite comunicación multi-nodo a través de cadenas de hosts infectados, lo que permite a los operadores alcanzar sistemas en segmentos de red aislados, físicamente desconectados de internet.
Backdoor Stupig: ejecución de comandos desde la pantalla de inicio de sesión de Windows
Stupig es un backdoor en forma de DLL detectado con los nombres a.dll y kbdus1.dll. El nombre de archivo kbdus1.dll imita a la biblioteca legítima de Microsoft kbdus.dll, responsable del diseño de teclado US English.
El mecanismo de persistencia de Stupig se basa en su registro como proveedor de distribución de teclado. Durante el arranque del sistema, el controlador win32k.sys carga la DLL maliciosa en el proceso winlogon.exe. La biblioteca devuelve un puntero KBDTABLES válido, por lo que el diseño de teclado sigue funcionando con normalidad y el propio módulo parece legítimo al inspeccionar los procesos.
Una vez iniciado dentro de winlogon.exe, Stupig supervisa el campo de introducción del nombre de usuario en la pantalla de inicio de sesión de Windows. Cuando se introduce un nombre que comienza con el prefijo «stupig», la cadena que lo sigue se interpreta como un comando y se ejecuta con privilegios de SYSTEM. Si no se especifica ningún comando después del prefijo, el backdoor genera una consola de línea de comandos con permisos de SYSTEM directamente en la pantalla de inicio de sesión, antes de la autenticación del usuario y sin generar un evento de auditoría de inicio de sesión.
Tal como señalan Symantec y Carbon Black: «Al ocultarse dentro del proceso de inicio de sesión de Windows y registrarse como proveedor de distribución de teclado, Stupig ofrece a los operadores la ejecución de comandos con privilegios de SYSTEM y la posibilidad de robar credenciales antes de que el usuario inicie sesión: un método de acceso que la mayoría de los defensores desconocen y no monitorizan».
Relación entre Daxin y Stupig
Según los investigadores, no se han identificado solapamientos directos a nivel de código entre Daxin y Stupig. Sin embargo, su despliegue conjunto en un mismo host, la funcionalidad complementaria, las prácticas de desarrollo similares y las marcas de tiempo de compilación idénticas de 2013 permiten suponer que ambas herramientas podrían haber sido creadas por el mismo grupo. Anteriormente, Daxin había sido atribuido por investigadores a un actor de habla china, pero dicha atribución sigue sin confirmarse.
Debe tenerse en cuenta que la afirmación sobre una presencia no detectada durante 13 años es una evaluación analítica basada en las marcas de tiempo de compilación y en la discreción observada de la amenaza, y no un hecho cronológico confirmado. Las marcas de tiempo de compilación pueden ser modificadas deliberadamente por los atacantes.
Vector presunto de compromiso inicial
El modo exacto y el momento de la intrusión en el host siguen siendo desconocidos. Los investigadores consideran que el vector de entrada podría haber sido un portal de inicio de sesión único (SSO) Digiwin obsoleto, que utilizaba las versiones Java Development Kit (JDK) 1.5 y 1.6, ya fuera de soporte y fechadas entre 2009 y 2011. Esta hipótesis no está respaldada por vulnerabilidades concretas que se sepa que hayan sido explotadas.
Actividad paralela: modelos de IA en operaciones ofensivas
En un estudio aparte, la empresa Hunt.io informó de la observación de un presunto actor de habla china que utiliza los modelos Anthropic Claude Code y DeepSeek para automatizar intrusiones en sistemas gubernamentales y financieros de Afganistán, Tailandia, Taiwán y Estados Unidos. La conclusión se basa en el hallazgo de un directorio abierto en la dirección 112.213.124[.]132, cuyos encabezados HTTP coinciden con la infraestructura de mando y control conocida de TencShell.
Según Hunt.io, Claude Code actuaba como motor de ejecución para la gestión basada en agentes de herramientas, la ejecución de comandos bash y la paralelización de tareas, mientras que DeepSeek-v4-pro se utilizaba como modelo de razonamiento para generar la lógica de los ataques, los scripts y la toma de decisiones.
Evaluación del impacto
La detección de Daxin en 2026 demuestra que la operación de ciberespionaje no se ha detenido por completo, sino que ha pasado a un modo de mantenimiento encubierto de la presencia. Están especialmente expuestos a riesgo:
- Las plantas de producción en Taiwán y el Sudeste Asiático, en especial las filiales de corporaciones multinacionales
- Las organizaciones que utilizan versiones obsoletas de JDK y portales SSO sin actualizaciones de seguridad
- Las redes con segmentos aislados, donde la comunicación multi-nodo de Daxin puede proporcionar acceso a sistemas críticos
Recomendaciones prácticas
- Auditoría de proveedores de distribución de teclado: revise el registro de Windows en busca de DLL no estándar registradas como proveedores de distribución. Compare los módulos cargados en winlogon.exe con una lista de referencia de bibliotecas legítimas de Microsoft.
- Búsqueda de indicadores: compruebe si existen en el sistema los archivos srt64.sys, kbdus1.dll y a.dll. Preste atención a las DLL cuyos nombres se parezcan a kbdus.dll, pero difieran del original.
- Monitorización del tráfico de red: implemente un análisis profundo del tráfico TCP para detectar patrones anómalos dentro de conexiones legítimas; la monitorización estándar de conexiones salientes no revelará Daxin.
- Actualización de software obsoleto: retire de producción de inmediato JDK 1.5 y 1.6, así como cualquier portal SSO que no reciba actualizaciones de seguridad.
- Auditoría de eventos en la pantalla de inicio de sesión: configure la monitorización de intentos de inicio con nombres de usuario inusuales, especialmente aquellos que contengan la cadena «stupig».
- Verificación de segmentos aislados: dada la capacidad de Daxin para la comunicación multi-nodo, audite los hosts en segmentos que se consideren aislados de internet.
El caso de Daxin y Stupig demuestra que herramientas compiladas hace más de una década pueden seguir siendo eficaces cuando la ocultación se implementa correctamente. La acción prioritaria para los equipos de seguridad es realizar una auditoría específica de los proveedores de distribución de teclado de Windows y de los módulos cargados en winlogon.exe, así como asegurarse de que no existan componentes JDK obsoletos ni portales SSO en el entorno de producción.
