STOCKSTAY: Turla desata un backdoor .NET modular con WebSocket cifrado y evasión por IPC que eleva sus campañas de alto valor

La amenaza conocida como Turla, vinculada a intereses estatales rusos, ha mostrado una evolución técnica y operativa con la aparición de un nuevo backdoor en .NET bautizado por los investigadores como STOCKSTAY. Más que un simple sustituto, STOCKSTAY parece haber sido diseñado desde cero con una arquitectura modular y con claras reminiscencias del ecosistema KAZUAR, la plataforma que este actor ha utilizado y refinado desde hace años.

STOCKSTAY destaca por tres rasgos técnicos que lo hacen especialmente peligroso para objetivos de alto valor: su desarrollo en .NET usando Windows Forms, la comunicación cifrada vía WebSocket (implementada con la librería websocket-sharp) y la división en varios módulos que se comunican entre sí mediante IPC usando mensajes WM_COPYDATA. Esa separación de roles —descargador, túnel proxy con WebSocket, controlador y backdoor principal— facilita su sigilo, su persistencia y el reemplazo o actualización de componentes individuales sin afectar al conjunto.

Los vectores de entrega observados no son novedosos pero sí eficaces: campañas de spear-phishing con lures diplomáticos o académicos, archivos RAR que explotan vulnerabilidades de WinRAR (mencionada como CVE-2025-8088 en informes), adjuntos RDP maliciosos que establecen conexiones a infraestructura controlada por el atacante, instaladores MSI y HTA alojados en repositorios públicos o en sitios comprometidos. Además, la campaña ha servido tanto para obtener acceso inicial en entornos no previos como para moverse lateralmente y ejecutar el backdoor en máquinas concretas ya identificadas por los atacantes.

Desde una perspectiva estratégica, la reutilización de ideas y componentes entre STOCKSTAY y KAZUAR sugiere dos posibilidades que implican riesgos distintos: por un lado, que la misma o una solapada cadena de desarrollo mantenga ambos toolkits; por otro, que Turla esté empleando un enfoque de laboratorio en producción, probando nuevas capacidades en operaciones reales. En ambos casos, la modularidad y la táctica de usar sitios WordPress comprometidos o repositorios públicos para alojar etapas del ataque aumentan la dificultad de detección y atribución.

Las implicaciones para gobiernos, ministerios y empresas con exposición a política exterior son claras: la superficie de ataque se centra en ingeniería social dirigida y en cadenas de entrega que combinan vulnerabilidades y contenido legítimo alojado en terceros. Eso exige controles que no se limitan a firmas estáticas sino a detección de comportamiento, telemetría de red y correlación de eventos entre correo, endpoint y tráfico saliente.

Para reducir exposición y tiempo de respuesta es imprescindible aplicar medidas prácticas y priorizadas. Primero, parchear inmediatamente componentes de terceros críticos y eliminar versiones vulnerables de programas como WinRAR; segundo, endurecer las políticas de correo bloqueando o inspeccionando con sandbox adjuntos .htm, .hta, .rdp, .msi y .rar procedentes de remitentes no verificados; tercero, desplegar EDR/telemetría que registre creación de procesos .NET con UI de Windows Forms que establezcan conexiones externas y actividad de WM_COPYDATA entre procesos, ya que ese canal IPC es distintivo de esta familia de malware.

En red, conviene controlar y analizar tráfico WebSocket saliente inusual, especialmente conexiones cifradas hacia servidores que no estén catalogados como parte de la actividad normal. La naturaleza cifrada del canal puede impedir inspección profunda, por lo que hay que añadir detección basada en patrones de comportamiento (p. ej. procesos internos que activen túneles proxy o establezcan múltiples conexiones WebSocket desde hosts internos) y bloqueo por reputación de dominios y direcciones IP conocidas.

Operativamente, es recomendable segmentar entornos sensibles, revocar credenciales que puedan haber sido comprometidas tras una campaña de phishing y realizar búsquedas proactivas de indicadores en endpoints y servidores. Además, auditar instalaciones WordPress internas y sitios públicos que la organización gestiona puede evitar que repositorios legítimos se conviertan en vectores para entregar cargas útiles.

Para equipos de respuesta y analistas, la investigación de Google destaca la existencia de un repositorio público que implementa el control de servidor WebSocket del lado víctima, lo que plantea riesgos de reutilización por parte de otros actores y dificulta la atribución técnica al cifrar mensajes entrantes. Es aconsejable compartir telemetría y IOC con las unidades de inteligencia y los CERT nacionales y apoyarse en análisis de terceros y de la comunidad para identificar campañas en curso; recursos generales sobre el actor y su historial pueden consultarse en la documentación pública de grupos de amenazas como la de MITRE (https://attack.mitre.org/groups/G0010/) y en los reportes de los equipos de respuesta como los de Google TAG (https://blog.google/threat-analysis-group/).

En resumen, STOCKSTAY no es solo una nueva pieza de malware: es la expresión de una política operativa madura que combina modularidad, evasión y campañas de ingeniería social dirigidas. La defensa requiere combinar parcheo, endurecimiento del correo, telemetría avanzada y coordinación entre equipos. Para organizaciones en sectores sensibles, la acción inmediata es priorizar parches y controles de correo, activar detección basada en comportamiento en endpoints y redes, y preparar procesos de respuesta que contemplen la posibilidad de compromisos encubiertos y multi-etapa.