Clientes ScreenConnect fraudulentos propagan una cadena de VBScript de cuatro etapas hacia hosts recién conectados

Investigadores de ciberseguridad han revelado detalles de una actividad similar a un gusano que abusa de ConnectWise ScreenConnect para distribuir una carga maliciosa de Visual Basic Script (VBScript) a sistemas recién conectados.

Según Huntress, tres incidentes no relacionados utilizaron diversos métodos de acceso inicial, como una estafa de soporte técnico de Quick Assist, un instalador MSI entregado por phishing y un señuelo de formulario de reembolso falso de Geek Squad, para activar una cadena de VBScript de cuatro etapas que conduce a instalaciones fraudulentas de ScreenConnect. Una vez instalados los clientes fraudulentos, la empresa de ciberseguridad observó que los clientes generaban repetidamente 'wscript.exe' para ejecutar los VBScripts llamados 1.vbs, 2.vbs, 3.vbs y 4.vbs. Los incidentes se observaron en agosto de 2026.

Detalles de los tres ataques

Un ataque de ingeniería social que persuadió a un usuario a ejecutar Quick Assist como parte de una estafa de soporte técnico, después de lo cual se desplegó un cliente de acceso remoto ScreenConnect fraudulento que se comunicaba con un servidor de comando y control (C2) ubicado en '45.13.237[.]190' ('tele-sync.opik[.]net'). En esa dirección IP se aloja un archivo RAR que contiene los cuatro archivos VBS.
Un instalador MSI ('ScreenConnect.ClientSetup.msi') probablemente entregado mediante un ataque de phishing que desplegó un cliente ScreenConnect configurado para comunicarse con '131.123.40[.]98' en el puerto 8041. El ScreenConnect fraudulento lanzó casi de inmediato los cuatro archivos VBScript desde el directorio temporal de ScreenConnect.
Una búsqueda de un formulario de reembolso de Geek Squad condujo al despliegue de un cliente ScreenConnect fraudulento ('ScreenConnect.Client.exe'), que luego se conectó a 'borertors92.anondns[.]net'. La sesión utiliza 'wscript.exe' para ejecutar los cuatro scripts VBS desde la carpeta Temp.

Proceso de cuatro etapas

En estos incidentes, la secuencia del ataque siguió un proceso de cuatro pasos, donde cada VBScript lanza al siguiente y permite que avance:

1.vbs: perfila el host, verifica los recursos del sistema (ej. si la RAM supera los 5 GB), comprueba si ScreenConnect está instalado, enumera los productos de seguridad (Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos y Symantec Endpoint Protection) y escribe los resultados en '%TEMP%value.txt' como una variable de estado de tres bits. Por ejemplo, el valor '000' indica que no hay instalación de ScreenConnect existente, presencia de procesos de seguridad de terceros y que no hay clientes ScreenConnect instalados en la carpeta Program Files.
2.vbs: espera el archivo '%TEMP%value.txt' y busca la palabra 'abort'. Si la palabra no existe, descarga un archivo de Dropbox, decodifica su contenido y lo escribe en '%TEMP%map.txt'. Aunque el contenido del archivo de texto no se ejecuta, la naturaleza exacta de la carga recuperada no está clara, ya que la URL de Dropbox ya no está en línea desde el 2 de septiembre de 2026.
3.vbs: funciona de manera similar a 2.vbs, esperando '%TEMP%map.txt' y luego procede a descargar el archivo correspondiente desde el enlace de Dropbox especificado en el archivo de texto según los valores de estado establecidos por 1.vbs en '%TEMP%value.txt' y lo escribe en '%TEMP%out.enc'.
4.vbs: espera la presencia de la carga descargada '%TEMP%out.enc' y lanza un script de PowerShell ('%TEMP%runner.ps1') para descifrar el contenido de '%TEMP%out.enc', escribirlo en '%APPDATA%MicrosoftWindowsTemplatesClassicsys_cache.zip' y ejecutar un script de PowerShell de segunda etapa ('PyTorchFix.ps1').

Cargas útiles y comportamiento similar a gusano

Se han detectado al menos tres cargas útiles diferentes según el valor de estado:

000 y 001: conducen a una puerta trasera de ScreenConnect a nivel de usuario.
010: conduce a herramientas para escalada de privilegios mediante un bypass de Control de Cuentas de Usuario (UAC) y persistencia.
011: conduce a utilidades de tunelización y un minero de criptomonedas.

Además, '%TEMP%runner.ps1' toma medidas para terminar todos los procesos 'wscript.exe' o 'cscript.exe' y elimina el directorio de ensayo después de que se ejecuta la etapa final. El script 4.vbs también escribe los cuatro archivos VBScript en 'C:UsersPublicLibrariesDefaultLibLib1' si el valor en '%TEMP%value.txt' está configurado en 010 o 011.

Esto, a su vez, desencadena una ronda de entregas de carga útil, convirtiendo efectivamente al host comprometido en un mecanismo de distribución de contenido para los scripts maliciosos cada vez que el cliente con puerta trasera observa una nueva conexión de Host.

Esto crea un comportamiento similar a un gusano: propagar infecciones a través de nuevas conexiones de ScreenConnect. Conectarse a un cliente 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 atacar repetidamente la misma sesión activa, pero luego elimina ese identificador después de que se desconecta, lo que permite que una reconexión posterior active la infección nuevamente.

Los incidentes comparten indicadores adicionales, incluida una clave de ejecución de WindowsServiceHost en el usuario que apunta a WindowsServiceHost.vbs en el directorio AppData del usuario. Huntress también observó otras herramientas de monitoreo y gestión remota (RMM), incluida UltraViewer, en algunos hosts afectados.

Por otro lado, la rama de valor de estado '011', que se traduce en: (1) sin instalación existente de ScreenConnect en el sistema, (2) Microsoft Defender es el único programa de protección de endpoints instalado en la máquina y (3) no hay clientes ScreenConnect presentes, incluye cargas útiles para deshabilitar los informes de Microsoft Defender, apagar la integridad de memoria de Windows y ejecutar un minero de criptomonedas XMRig.

Considerando la extensión y complejidad de estas cadenas de ataque, el SOC de Huntress hizo fuertes recomendaciones de que estos hosts afectados se re-imagen desde medios conocidos, o se realice una instalación limpia del sistema operativo.

Recomendación de ConnectWise

En respuesta a los hallazgos, ConnectWise ha emitido un aviso indicando que ha identificado un problema que afecta el comportamiento de transferencia de archivos en las sesiones de Acceso Remoto y Soporte de ScreenConnect. El problema afecta tanto a implementaciones en la nube como locales. Hasta que se implemente una solución, se recomienda a los clientes mitigar el riesgo deshabilitando la capacidad de los técnicos para transferir archivos:

Inicie sesión en la página de Administración de la instancia o instalación de ScreenConnect.
Navegue a Administración > Seguridad > Roles.
Edite un rol asignado a los usuarios.
Revise cada grupo de sesiones que tenga permisos asignados.
Para cada grupo de sesiones, en la ventana de Permisos con Alcance, verifique si el permiso TransferFiles (o TransferFilesInSession para versiones heredadas) está seleccionado. Si lo está, deseléccione.
Guarde los cambios en el rol.
Repita para cada rol definido en la instancia o instalación.