ConnectWise parchea un fallo 9,9 de ScreenConnect usado en ataques con propagación de gusano

ConnectWise ha publicado una actualización de emergencia para ScreenConnect, su software de soporte y acceso remoto, con la que cierra un fallo crítico del lado del cliente que permitía a un atacante mover y ejecutar archivos dentro de una sesión activa sin la aprobación del equipo anfitrión. La corrección, ScreenConnect 26.6.5, llegó el 8 de septiembre según el boletín de seguridad del fabricante. La vulnerabilidad, registrada como CVE-2026-84869, tiene una puntuación CVSS de 9,9 sobre 10, y los investigadores ya la habían visto usarse en el mundo real durante unas dos semanas antes de que existiera un parche.

Lectura relacionada: Los atacantes usaron la identidad de aplicación de ConnectWise Cloud Backup para entrar en inquilinos de Microsoft 365 · El FBI detiene a un empleado de OpenAI acusado de colocar un dispositivo de grabación oculto.

El fallo está en el cliente de ScreenConnect, no en el servidor. ConnectWise describe una condición por la que las acciones de transferencia de archivos pueden seguir adelante «a través de una sesión remota activa sin autorización ni confirmación del host en determinadas circunstancias», y afirma que los servidores de ScreenConnect no están afectados. En la práctica, un atacante que ya está dentro de una sesión puede enviar un archivo al endpoint conectado y ejecutarlo, incluso mediante acciones de ejecución con privilegios elevados.

Lo que vio Huntress

La firma de seguridad Huntress documentó la actividad. La detectó por primera vez a finales de agosto y publicó sus conclusiones el 9 de septiembre en un informe detallado. En tres incidentes no relacionados, sus analistas encontraron instalaciones fraudulentas de ScreenConnect en máquinas víctimas que después lanzaban una y otra vez wscript.exe para ejecutar cuatro scripts llamados 1.vbs a 4.vbs.

Las instalaciones fraudulentas llegaron por ingeniería social. Una empezó con una estafa de soporte técnico basada en Windows Quick Assist. Otra siguió a la búsqueda de un formulario de reembolso de Geek Squad que llevó a la víctima a ejecutar un archivo de instalación del cliente descargado. Una tercera arrancó con un resultado de búsqueda envenenado que empujó un ScreenConnect.Client.exe fraudulento. Son tácticas conocidas: las herramientas de supervisión y gestión remotas (RMM) resultan atractivas para los delincuentes precisamente porque son software de confianza que llega muy adentro de una red.

Lo que hizo diferente a esta campaña fue lo que hicieron después los clientes modificados. Según Huntress, el cliente fraudulento vigilaba la lista de conexiones de ScreenConnect y, cada vez que aparecía una nueva sesión de host, registraba los cuatro archivos VBScript en el propio sistema de transferencia de archivos del software y los enviaba a la máquina recién conectada. La cadena se repetía entonces en ese endpoint. Huntress calificó el comportamiento de similar a un gusano porque la carga útil se propaga sola de sesión en sesión, en lugar de esperar a que un operador repita el trabajo a mano.

En cada host, las intrusiones dejaban además una clave Run de usuario de Windows llamada WindowsServiceHost que apuntaba a WindowsServiceHost.vbs en la carpeta AppData del usuario, y en al menos un incidente instalaron una segunda herramienta de acceso remoto, UltraViewer. Huntress enumeró direcciones de mando y control vistas durante los incidentes, entre ellas 45.13.237[.]190, 131.123.40[.]98 y 15.204.185[.]204.

El cargador de cuatro etapas

Los scripts estaban escalonados para perfilar cada máquina antes de elegir una carga útil. El primero, 1.vbs, escribía un valor de tres bits en un archivo temporal que describía si ScreenConnect ya estaba instalado, qué productos de seguridad se estaban ejecutando y cuánta memoria tenía el host. La comprobación de memoria, observó Huntress, es una forma habitual de evitar que una carga útil se ejecute dentro de una máquina virtual de análisis pequeña.

Un segundo script esperaba ese valor, descargaba un archivo de Dropbox, lo decodificaba con una clave XOR de un solo byte y producía un catálogo de cargas útiles posteriores indexado por el valor de tres bits. Un tercer script leía el catálogo y descargaba la entrada correspondiente, que se almacenaba cifrada como out.enc. El cuarto la descifraba con una clave AES tomada del catálogo, lanzaba un ejecutor de PowerShell, descifraba un segundo archivo en un directorio de plantillas de Windows, borraba los archivos de preparación y mataba cualquier host de script que quedara.

Entre los resultados que observó Huntress había un bypass de UAC construido sobre el controlador de protocolo ms-settings, un intento de desactivar la interfaz de análisis antimalware, una exclusión de Microsoft Defender para todo el árbol C:\Users y un cliente de ScreenConnect oculto al que se le habían eliminado la entrada de desinstalación y el descriptor de servicio para que no apareciera en los sitios habituales. Una variante de la carga útil también entregaba un minero de criptomonedas, señal de una operativa con motivación económica.

Un detalle llama la atención de los defensores. Un comentario dentro de 3.vbs detallaba el formato esperado del catálogo de cargas útiles, el tipo de nota explicativa que deja atrás un desarrollador humano. Huntress escribió que el script fue «probablemente» generado por un modelo de lenguaje grande. El malware de consumo ensamblado con los mismos asistentes que escriben código corriente es ya una parte rutinaria de la respuesta a incidentes, y hace que los scripts se lean con más limpieza de la que su intención merece.

Cargas útiles ramificadas

No todos los hosts recibieron el mismo paquete. Huntress descubrió que el catálogo asignaba el perfil de tres bits a una de tres cargas útiles cifradas: una puerta trasera de ScreenConnect a nivel de usuario, un paquete de acceso que llevaba herramientas de persistencia y escalada de privilegios, o un paquete combinado que, según dijo, incluía utilidades de tunelización y un minero de criptomonedas. Construir un perfil del objetivo y luego elegir una carga útil es una operativa ordinaria para un cargador de este tipo, pero muestra que los operadores estaban clasificando máquinas en lugar de rociar una sola etapa sobre todo lo que tocaban.

Cómo se desarrolló la respuesta

La divulgación siguió un calendario comprimido. ConnectWise publicó el 3 de septiembre un aviso que advertía de un problema en el comportamiento de transferencia de archivos en las sesiones de soporte y acceso de ScreenConnect, tanto en despliegues en la nube como locales, y dijo que un CVE y una corrección oficial llegarían dentro de la semana, mientras recomendaba a los socios revisar y desactivar el permiso TransferFiles entretanto. Huntress, que seguía las anomalías desde finales de agosto, actualizó su informe el 8 de septiembre cuando llegó el parche 26.6.5, y de nuevo a medida que se completaba el cuadro de explotación. La entrada de CISA en su catálogo el 11 de septiembre convirtió una remediación del fabricante en un plazo federal del 14 de septiembre para las agencias civiles. La secuencia, primero el aviso, días después el parche y luego la inclusión entre las explotadas conocidas, se ha convertido en el ritmo estándar de un fallo empresarial grave, pero aun así dejó unas dos semanas entre las primeras intrusiones observadas y una corrección.

Por qué el acceso remoto sigue siendo el objetivo

ScreenConnect lo usan ampliamente los proveedores de servicios gestionados y los servicios de asistencia informática. Eso es justo lo que lo hace valioso para un atacante: es software legítimo con un alcance amplio dentro de las redes de los clientes y se ejecuta con los privilegios que se espera que tenga un técnico de asistencia. El abuso de RMM ha sido uno de los principales vectores de ataque durante años, y ScreenConnect ya ha pasado por esto. Un bypass de autenticación de 2024 en el producto se explotó de forma masiva, y el patrón de usar una sesión de soporte remoto para dejar herramientas se ha vuelto tan común que los defensores tratan ahora las instalaciones de RMM como una superficie de detección por derecho propio.

Para un proveedor de servicios gestionados lo que está en juego es mayor que para una sola empresa. Un MSP suele administrar a muchos clientes desde un único despliegue de ScreenConnect, así que un cliente contaminado que envía cargas útiles a nuevas sesiones puede amenazar tanto a los clientes posteriores como a las propias máquinas del proveedor. Es un problema de cadena de suministro en miniatura, y por eso el consejo del fabricante de auditar los permisos de transferencia de archivos de las sesiones se aplica con más urgencia a los proveedores de servicios.

El modelo de propagación es lo nuevo. El abuso de RMM normalmente depende de que un operador envíe una herramienta a una máquina cada vez, lo que limita la velocidad con que se extiende una intrusión y da a los defensores más ocasiones de detectarla. Un cliente que envía la siguiente etapa a cualquier máquina a la que se conecte después elimina ese cuello de botella. También complica la atribución, porque todas las máquinas del mismo despliegue de ScreenConnect se convierten en un posible punto de entrega.

El plazo del parche

CISA añadió CVE-2026-84869 a su catálogo de vulnerabilidades explotadas conocidas el 11 de septiembre y dio a las agencias civiles federales hasta el 14 de septiembre para remediarlo, en virtud de la Directiva Operativa Vinculante 26-04. Fue una de las tres entradas de ese día y formó parte de un grupo más amplio que la agencia catalogó durante la semana, junto con dos fallos de MikroTik RouterOS y dos de JFrog Artifactory que The Hacker News informó que se encadenaron en ataques contra servidores autoalojados. SecurityWeek fue uno de los medios que confirmó la explotación de ScreenConnect.

Conviene retener dos matices. La descripción de similar a un gusano procede de la investigación de Huntress y no de ConnectWise, y describe una propagación de sesión a sesión entre máquinas que comparten un despliegue de ScreenConnect, no la propagación autosostenida y de alcance mundial que suele implicar la palabra gusano. Por separado, ninguna de las dos compañías ha atribuido la campaña a un grupo con nombre. El componente de minero común y los señuelos de soporte al consumidor apuntan a un operador con motivación económica, pero eso es una inferencia a partir de la operativa, no una identificación confirmada.

Qué hay que vigilar

La pregunta inmediata para cualquier organización que use ScreenConnect es si los clientes modificados llegaron a máquinas fuera del parque que conocen sus propios administradores, ya que todo el sentido de la propagación es aterrizar en endpoints que el operador no tocó directamente. Los registros de auditoría que muestren un proceso Guest ejecutando archivos en un host son el punto por el que empezar.

La pregunta de más largo plazo es si la misma técnica aparece en otros productos de soporte remoto. La condición de fondo, un cliente que actúa según las instrucciones de una sesión sin una comprobación clara de autorización, no es probable que sea exclusiva de un fabricante. ConnectWise ya ha lanzado la corrección; el resto del mercado de RMM tiene ahora motivo para mirar cómo sus propios clientes deciden qué transferencias de archivos aceptar.

Imagen: logotipo de ScreenConnect, de ScreenConnect, vía Wikimedia Commons, con licencia CC BY-SA 4.0. La imagen se ha recortado y colocado sobre un fondo.