Instalaciones fraudulentas de ScreenConnect en endpoints no relacionados sugieren actividad tipo gusano

Agradecimientos: un agradecimiento especial a Jamie Levy, Susannah Matt, Aaron Deal, Marc Lean y Ben Nahorney por sus contribuciones a esta investigación y redacción.

ACTUALIZACIÓN 8/9/26 a las 9 p. m. hora del Este

Tras el aviso del 3 de septiembre, ConnectWise lanzó una actualización de seguridad para resolver una vulnerabilidad en ScreenConnect. La vulnerabilidad (CVE-2026-84869) tiene una puntuación de 9,9 en la escala CVSS. Según ConnectWise, las versiones anteriores de las sesiones de Client Support y Access de ScreenConnect tenían una falla del lado del cliente en el manejo de la transferencia de archivos: las acciones de transferencia de archivos podían ejecutarse durante una sesión de acceso remoto activa sin la autorización o confirmación adecuadas del sistema anfitrión. En ciertas circunstancias, esto podía permitir que se transfirieran y ejecutaran archivos en el sistema cliente anfitrión, incluso mediante acciones de ejecución con privilegios elevados.

Las organizaciones deben actualizar a la versión 26.6.5 de ScreenConnect; ConnectWise indicó que las versiones anteriores a la 26.6.5 están afectadas. Los servidores de ScreenConnect no están afectados. Huntress continúa monitoreando esta vulnerabilidad y mantendrá este blog actualizado con más información.

ACTUALIZACIÓN 3/9/26 a las 5:45 hora del Este

El 3 de septiembre, ConnectWise publicó un aviso aquí: https://www.connectwise.com/company/trust/advisories

Indicaron que identificaron un problema que afecta el "comportamiento de transferencia de archivos" en las sesiones de Support y Access de acceso remoto de ScreenConnect (tanto en implementaciones en la nube como locales). ConnectWise dijo que se publicarán un CVE y una solución oficial dentro de esa semana; mientras tanto, indicaron que los partners pueden tomar varias medidas.

ConnectWise sugirió que las organizaciones potencialmente afectadas revisen los permisos de TransferFiles, o TransferFilesInSession en versiones anteriores, y deshabiliten esta opción si está habilitada. Los pasos detallados están disponibles en el aviso.

Por nuestra parte, Huntress ha visto varios incidentes más con anomalías de comportamiento descritas en nuestro blog inicial. Continuaremos monitoreando esta situación; ConnectWise dijo que publicará una guía actualizada en la página del aviso una vez que haya una solución disponible.  

PUBLICACIÓN ORIGINAL

Recientemente, Huntress observó un patrón extraño en endpoints sin relación aparente dentro de varias organizaciones que protegemos. A fines de agosto, nuestro Centro de operaciones de seguridad (SOC) envió tres informes de incidentes críticos por lo que parecía ser una instalación maliciosa de ScreenConnect y una ejecución inesperada de procesos. Aunque estos incidentes ocurrieron en organizaciones distintas, había otras similitudes: todos parecían incluir soluciones RMM adicionales.

La actividad anómala

Todos los incidentes comenzaron con algún nivel de ingeniería social, lo que finalmente llevó a que se implementaran instancias fraudulentas de ScreenConnect en las máquinas de las víctimas. Esto es bastante típico, ya que el abuso de RMM es un vector de ataque importante que Huntress ha visto durante el último año. 

Sin embargo, después de que se implementaran estas instancias fraudulentas de ScreenConnect, Huntress observó una ejecución inesperada de procesos: como se ve en la Figura 1, los clientes generaban procesos secundarios repetidos de Windows Script Host (wscript.exe), lo cual fue marcado como un comportamiento anómalo. 

En todos los incidentes, se usó wscript.exe para implementar cuatro archivos VBScript distintos (1.vbs, 2.vbs, 3.vbs y 4.vbs). 

Figura 1: Huntress detectó que ScreenConnect.WindowsClient.exe generaba el proceso secundario wscript.exe

Huntress observó varias otras similitudes en los incidentes, incluido que el atacante creaba una clave de ejecución de usuario (User Run Key) (WindowsServiceHost) que apuntaba a un archivo VBScript (WindowsServiceHost.vbs) en los directorios AppData de los usuarios afectados. 

Un análisis de las cargas útiles usadas en el ataque reveló un ataque por etapas diseñado para perfilar hosts y ocultar la actividad. Quizás la parte más interesante de la cadena de ataque fue que usaba clientes modificados de ScreenConnect para propagar la cadena de VBScript (específicamente, ejecutando los cuatro archivos (1.vbs a 4.vbs) hacia los endpoints conectados de ScreenConnect, creando una propagación tipo gusano en los sistemas recién conectados.   

A continuación, detallamos la cadena de ataque de estos incidentes, además de los indicadores de compromiso (IOC), para que los defensores puedan buscar proactivamente esta actividad en sus entornos. También estamos en comunicación con ConnectWise y seguimos de cerca esta actividad.

Primer incidente del 20 de agosto 

En un incidente del 20 de agosto, Huntress detectó un ataque de ingeniería social que comenzó cuando un usuario ejecutó Quick Assist, una herramienta integrada de soporte remoto de Windows que suele ser aprovechada por actores de amenazas en estafas de soporte técnico bien documentadas. Este tipo de estafa implica que los actores de amenazas se hacen pasar por soporte técnico (por teléfono o mediante una alerta falsa) y convencen a la víctima de que su equipo fue hackeado, antes de guiarla para que abra Quick Assist y comparta el código de acceso que les otorga el control remoto.

Figura 2: El usuario ejecutó Quick Assist

Poco después de la ejecución de Quick Assist, el actor de amenazas implementó un cliente fraudulento de acceso remoto ScreenConnect, configurado para comunicarse con un servidor de comando y control (C2) en 45.13.237[.]190. Según VirusTotal, esta dirección IP estuvo asociada con el dominio 

tele-sync.opik[.]net durante el mes de agosto.

Figura 3: Según la inteligencia de VirusTotal, la dirección IP está vinculada a un dominio conocido controlado por un actor de amenazas. El archivo EXE referenciado en la Figura 3 es en realidad un archivo RAR que contiene los cuatro archivos .vbs mencionados en la introducción. Como parte del ataque, el atacante recuperaría este archivo desde el servidor C2, y luego ejecutaría secuencialmente cada uno de los scripts usando wscript.exe para implementar las cargas útiles, recopilar telemetría sobre el sistema infectado y establecer persistencia.

Como se ve en la Figura 4, Microsoft Defender detectó y puso en cuarentena uno de estos scripts (4.vbs). Sin embargo, el atacante creó una clave de ejecución de usuario (User Run Key) (WindowsServiceHost) para persistencia que apuntaba a un archivo VBScript en el directorio AppData del usuario (WindowsServiceHost.vbs) y también ejecutó un archivo por lotes (WindowsServiceHost.bat), que no se pudo recuperar. 

Figura 4: Microsoft bloqueó y puso en cuarentena 4.vbs

En este punto, el SOC de Huntress detuvo el ataque antes de que pudiera avanzar más.

Segundo incidente del 20 de agosto 

Vimos estos mismos archivos VBScript en otro entorno el 20 de agosto. Durante este incidente, el endpoint afectado de nuevo contenía una instancia no autorizada de ScreenConnect que lanzó wscript.exe cuatro veces para ejecutar cuatro archivos VBScript diferentes (1.vbs, 2.vbs, 3.vbs y 4.vbs). 

Este ataque probablemente comenzó con phishing, lo que llevó a la víctima a ejecutar ScreenConnect.ClientSetup.msi desde un directorio de descargas de Microsoft Edge. Ese archivo MSI implementó un cliente de ScreenConnect, que estaba configurado para comunicarse con 131.123.40[.]98 en el puerto 8041. En ese momento, el cliente no autorizado de ScreenConnect casi de inmediato lanzó los cuatro archivos VBScript desde el directorio temporal de ScreenConnect. Durante el curso de la investigación, la telemetría de red también identificó conexiones activas desde ScreenConnect hacia múltiples direcciones IP remotas, incluyendo 131.123.40[.]98, 45.13.237[.]190, y 15.204.185[.]204.

Aquí, el actor de amenazas también estableció persistencia mediante una clave de ejecución de usuario (User Run Key) del registro de Windows llamada WindowsServiceHost (que apunta al archivo VBScript WindowsServiceHost.vbs en el directorio AppData del usuario).

Esta cadena de ataque también incluyó la instalación del software de escritorio remoto UltraViewer, que hizo conexiones en 146.59.55[.]107 y 45.32.192[.]150. UltraViewer es otra utilidad RMM más que se sabe que es usada para el control remoto por estafadores y otros actores de amenazas. 

Incidente del 24 de agosto

Investigadores de Huntress encontraron el mismo comportamiento anómalo durante un incidente ocurrido el 24 de agosto. Este incidente comenzó con un ataque de ingeniería social: la víctima estaba buscando un formulario de reembolso de Geek Squad, y en su lugar fue convencida de descargar y ejecutar un cliente no autorizado de ScreenConnect (ScreenConnect.Client.exe). El cliente en este incidente se conectó a un dominio controlado por el atacante (borertors92.anondns[.]net). Si bien la cadena de ataque aquí también involucró la sesión de ScreenConnect usando wscript.exe para ejecutar los cuatro scripts VBS desde la carpeta Temp, el SOC de Huntress detuvo el ataque poco después de que se ejecutaran estos scripts, y no se detectó más actividad. 

Las cargas útiles

Pudimos descubrir el contenido de los archivos VBScript de preparación.

Figura 5: Infografía que describe el cargador VBS de cuatro etapas

El primer script sospechoso, 1.vbs, comienza con la sintaxis habitual para preparar variables locales. Crea una variable de "estado" de tres bits mediante el perfilado de varios aspectos del sistema en el que se ejecuta, y escribe ese valor en %TEMP%\value.txt

El primer bit se fija en 0 si no existe una instalación previa de ScreenConnect en el sistema. Si sí encuentra ScreenConnect, escribe "abort" en el archivo %TEMP%\value.txt .

Para determinar el valor del segundo bit, el script enumera productos de seguridad, incluyendo Huntress, Cisco AMP, CrowdStrike, SentinelOne, Sophos, Malwarebytes, entre otros. Si existe algún servicio de Windows con un nombre de proceso correspondiente a estos productos de seguridad, el script fija el valor del bit en 0. Si Microsoft Defender parece ser la única utilidad de protección de endpoints, fija el valor del segundo bit en 1.

Figura 6: La lista de reconocimiento de nombres del eliminador de EDR dentro de 1.vbs

Si la amenaza continúa su ejecución, entonces enumera la RAM (verificando si supera los 5 GB), y (de nuevo) verifica si hay algún cliente de ScreenConnect instalado dentro de la carpeta Program Files. Si no hay un cliente de ScreenConnect presente, fija el tercer byte de la variable state en 1.  La verificación de RAM probablemente es una forma de asegurarse de que se está ejecutando en una máquina real y no en una máquina virtual con una cantidad mínima de memoria usada para fines de investigación.

2.vbs espera la presencia de este archivo value.txt, y si no contiene la palabra abort, descarga un archivo desde Dropbox. Luego decodifica el contenido del archivo desde la codificación base64 y realiza un XOR sobre los datos, que escribe en %TEMP%\map.txt. (Al 2 de septiembre, observamos que la URL de Dropbox ya no está en línea.)

Figura 7: El archivo map.txt define una URL de destino para una de cuatro combinaciones de valores posibles para la variable de tres bits. Se agrega una clave de descifrado AES a la cadena URI en cada línea. 

Si el script logra descargar map.txt, decodifica el contenido en base64 y lo desenreda con una clave XOR de un solo byte de 90 (valor decimal). Ese contenido decodificado se coloca en %TEMP%\map.txt, pero no se ejecuta: se usa como un catálogo de payloads escalonados adicionales para el resto de la cadena de ataque.

Figura 8: El script que descarga y decodifica map.txt usa una cadena User-Agent codificada para que parezca que un usuario normal está descargando el archivo desde Dropbox.

El payload 3.vbs funciona de forma similar a 2.vbs. Espera la presencia de %TEMP%\map.txt, que debería haberse preparado en la etapa anterior. Un comentario útil en el código fuente del VBScript señala el formato de map.txt:

' Format: 011=http://url.com/combo.enc|AES_KEY

Figura 9: El LLM que (probablemente) generó el script 3.vbs incluyó útilmente un comentario que desglosa el paradigma para entender cómo analizar la clave AES a partir del formato de URL en el archivo map.txt usando el carácter de barra vertical como delimitador.

El script vuelve a leer value.txt y localiza la línea que coincide con los valores de estado definidos en 1.vbs. El script descarga el archivo correspondiente desde el enlace de Dropbox en el archivo map.txt, según el valor de tres bits, lo guarda en el sistema de archivos como out.tmp y luego lo renombra a out.enc usando la siguiente lógica:

• 000 y 001 → user.enc (user.zip contiene una puerta trasera de ScreenConnect a nivel de usuario)

• 010 → acc.enc (acc.zip incluye herramientas para persistencia y escalada de privilegios)

• 011 → combo.enc (combo.zip incluye utilidades de tunneling y un minero de criptomoneda)

El script 4.vbs espera la presencia del archivo descargado %TEMP%\out.enc, obtiene la clave AES específica de la cadena URI dentro de map.txt (y elimina value.txt y map.txt para limpiar), y luego crea y ejecuta un script de PowerShell.

Figura 10: Una parte del script 4.vbs identifica el IV de AES como los primeros 16 bytes del archivo out.enc, que el script llamó $headerBlock

Este script de PowerShell se construye en línea dentro del payload de VBScript, se guarda en %TEMP%\runner.ps1 y luego se invoca con una omisión de la política de ejecución. Ese payload de PowerShell descifra out.enc usando los primeros 16 bytes del archivo de datos cifrado como el IV de AES, la cadena de 32 bytes en map.txt como clave, y AES-CBC/PKCS#7 como algoritmo predeterminado.

El script de PowerShell descifra el archivo out.enc en %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip y luego ejecuta un segundo script de PowerShell, al que llama PyTorchFix.ps1. Luego runner.ps1 termina todo proceso wscript.exe o cscript.exe, y elimina el directorio de preparación.

Figura 11: El script 4.vbs escribe los cuatro archivos .vbs en C:\Users\Public\Libraries\Default\Lib\Lib1 si value.txt está configurado en 010 o 011, lo que desencadena una ronda de entregas de payloads y convierte el equipo infectado en un mecanismo de distribución de contenido para los scripts maliciosos.

Descubrimos una variante de "acceso" 010 de PyTorchFix.ps1, que incluía la elevación y el envoltorio de instalación de ScreenConnect. Construye un Password.exe a partir de código C# en línea, que se usa junto con un controlador de protocolo ms-settings: secuestrado para aprovechar la aplicación integrada ComputerDefaults.exe y lograr una omisión de UAC. Eso ejecuta código de PowerShell con privilegios elevados para:

• Establecer AmsiUtils.amsiInitFailed = true para intentar una omisión de AMSI

• Agregar todo C:\Users como ruta de exclusión de Microsoft Defender

• Activar el plan de energía de alto rendimiento y desactivar la suspensión con corriente alterna, el tiempo de espera del monitor y la hibernación

• Instalar y ocultar un cliente de ScreenConnect, con ID 7a4d7d66502d4260, y luego eliminar su entrada de desinstalación en el registro de Windows y aplicar un descriptor de seguridad de servicio restrictivo para ocultar su servicio de Windows.

Junto con PyTorchFix.ps1, el paquete de acceso contiene dos colecciones cifradas de clientes de ScreenConnect modificados que abarcan nueve versiones. El cliente recuperado inspecciona continuamente la colección EndPointStatusMessage.Connections de ScreenConnect y filtra las sesiones de equipos recién detectadas:

Figura 12: El cliente modificado identifica las sesiones de Host de ScreenConnect recién establecidas usando su valor de Connection ID.

Anteriormente explicamos que runner.ps1 copiaba desde 1.vbs hasta 4.vbs a C:\Users\Public\Libraries\Default\Lib\Lib1. En este cliente con puerta trasera, cada vez que detectaba una nueva conexión de Host, leía esos archivos, los registraba en el sistema de transferencia de archivos virtual de ScreenConnect y creaba el siguiente mensaje:

Figura 13: El cliente empaqueta los stagers de VBScript en un mensaje de transferencia de archivos de ScreenConnect, configura su acción como Run y lo pone en cola para el Host conectado.

Esto crea un comportamiento tipo gusano: propaga infecciones a través de nuevas conexiones de ScreenConnect. Conectarse a un cliente de ScreenConnect infectado puede hacer que el sistema Host del lado del servidor reciba y ejecute la misma cadena de VBScript de cuatro etapas. Más tarde, el cliente registra cada ConnectionID para evitar apuntar repetidamente a la misma sesión activa, pero luego elimina ese identificador después de que se desconecta, lo que permite que una reconexión posterior desencadene la infección nuevamente.

La rama de estado 011 también incluye payloads para desactivar los informes y notificaciones de Windows Defender, y la integridad de código protegida por hipervisor (HVCI). Incluye wstunnel, disfrazado como Themes.exe, que crea un túnel hacia homehub.opik[.]net:443, y ejecuta un minero de criptomoneda XMRig renombrado como SearchIndex.exe. El paquete también incluye el driver vulnerable WinRing0 como svcdrv64.sys.

Qué hacer

Dada la magnitud y complejidad de estas cadenas de ataque, el SOC de Huntress recomendó encarecidamente reformatear los hosts afectados con una imagen conocida como segura, o reinstalar el sistema operativo desde cero. 

A partir de nuestras conversaciones con ConnectWise y nuestro entendimiento actual del riesgo, sugerimos que los administradores apliquen una revisión extra a cualquier instalación on-premises de ScreenConnect que puedan tener en su entorno.

Dentro de los registros de auditoría del servidor de ScreenConnect, cualquier evidencia de RunFiles o RanFiles, incluidos los archivos sospechosos 1.vbs hasta 4.vbs ejecutados desde Process: Guest, debería levantar sospechas inmediatas y justificar el reformateo de ese dispositivo. (Para cuando se publique este artículo, los nombres de archivo podrían cambiar, así que cualquier indicio de ejecución de scripts de Windows Script Host o PowerShell debería encender las alarmas.)

Indicadores de compromiso (IOC)

Figura 14: VirusTotal Graph