Según los hallazgos de Netskope informados por SecurityWeek, los operadores de XWorm ya pueden usar 46 plugins capaces de convertir los sistemas Windows infectados en dispositivos de vigilancia en tiempo real. El número de plugins pasó de 35 en julio de 2025 a 46 en octubre de 2026.
Las novedades amplían un troyano de acceso remoto (RAT) que ya era muy capaz. Las funciones base de XWorm incluyen el registro de pulsaciones de teclado, la captura de pantallas, el acceso a las webcams y la ejecución de cargas útiles adicionales. En conjunto, estas funciones pueden dar al operador un control amplio sobre un equipo comprometido.
Netskope también informó de más de 1200 incidentes relacionados con XWorm en 100 organizaciones durante el tercer trimestre. Estas cifras describen incidentes de seguridad y organizaciones afectadas, no un recuento de personas únicas ni de víctimas individuales confirmadas.
Los plugins exponen la ubicación, el audio y las sesiones de navegador autenticadas
Las funciones de vigilancia descritas por Netskope afectan a varias fuentes de información sensible:
- Plugin Maps: obtiene la ubicación GPS del dispositivo sin mostrar ninguna solicitud al usuario.
- Plugin de micrófono: transmite audio en directo desde el dispositivo comprometido. Según Netskope, no requiere escalar privilegios ni muestra ninguna advertencia al usuario.
- Plugin HBrowser: ofrece una vista en tiempo real del navegador y reenvía al navegador las entradas del operador.
- Captura de webcam: permite al operador solicitar imágenes de la cámara.
HBrowser supone un riesgo particular para las cuentas protegidas con autenticación multifactor (MFA). Netskope afirma que el plugin toma el control de una sesión de navegador ya autenticada, en lugar de robar y reproducir las credenciales del usuario. El operador recibe una secuencia continua de capturas de pantalla, puede interactuar con el navegador y puede acceder a las pestañas autenticadas.
En ese escenario, la MFA pudo funcionar correctamente durante el inicio de sesión, pero por sí sola no puede impedir que un atacante controle de forma remota el endpoint de confianza ya autenticado. La capacidad descrita es, por tanto, una técnica de secuestro de sesión y no un compromiso directo del factor de autenticación.
Las instrucciones del operador llegan como mensajes de comando y control a través del canal estándar de XWorm, que Netskope describe como cifrado con AES. Después, el sistema infectado ejecuta localmente las acciones solicitadas.
Los recursos de desarrollo filtrados redujeron las barreras de acceso a XWorm
Netskope indica que XWorm se observó por primera vez en 2022. Después, el acceso a sus recursos de desarrollo se amplió: en junio de 2025 apareció públicamente una copia pirateada del builder del malware y, en agosto de 2025, se filtró el código fuente de la versión 6.4.
Los investigadores asocian el aumento de la actividad de XWorm con esas publicaciones. El acceso público a un builder y al código fuente puede permitir que más operadores creen variantes o modifiquen funciones, lo que hace menos probable que la actividad bajo la etiqueta XWorm responda a una única operación controlada de forma centralizada.
Qué deben priorizar los defensores
Las organizaciones que detecten XWorm deben tratar el equipo Windows afectado como un compromiso interactivo, no solo como un sistema que ejecutó un archivo malicioso estático. Las funciones descritas significan que un operador podría haber observado la actividad del usuario, controlado pestañas de navegador autenticadas, activado sensores o lanzado cargas útiles adicionales.
La respuesta a incidentes debe priorizar el aislamiento del dispositivo, la investigación de los procesos y la actividad de red asociados a la infección, y la revisión de las acciones realizadas a través de sesiones de navegador activas. Las sesiones autenticadas expuestas en el sistema deben cerrarse y, cuando proceda, las credenciales deben restablecerse desde un dispositivo de confianza.
Como el relato de Netskope describe el control de sesiones existentes, activar la MFA sigue siendo útil, pero no es una respuesta completa ante un endpoint infectado. Prevenir y detectar el compromiso inicial, e invalidar las sesiones tras la contención, son clave para limitar el impacto práctico de las capacidades de vigilancia ampliadas de XWorm.
