Agradecimientos: Un agradecimiento especial a Tanner Filip, Tyler Marzen, Austin Worline, Ethan Williams, Sharon Martin, Ben Bernstein, Andrew Brandt, Jamie Levy, Max Rogers y Aaron Deal por sus contribuciones a esta investigación y redacción.
Actualización: 11/11/26 a las 11:34 p. m. hora del Este
Huntress supo que la actividad parece estar relacionada con una de las extensiones específicas que ConnectWise ya había deshabilitado, RMM+. ConnectWise deshabilitó esta extensión (y varios otros complementos relacionados) en todos los entornos alojados, e instó a los socios on-premises a hacer lo mismo en su aviso público.
RMM+ es una extensión de terceros para ScreenConnect que permite que otra herramienta administre sesiones de ScreenConnect sin que un técnico trabaje a través de la consola. Nuestro análisis sugiere que la mayoría de las instalaciones de RMM+ que encontramos eran legítimas, por lo general agregadas para un proyecto y dejadas en su lugar. Pero las versiones 1.0.31 y 1.0.32 contenían una falla grave de autenticación: si un administrador nunca había configurado la clave de acceso de la extensión, RMM+ aceptaba una en blanco.
RMM+ omite las cuentas de usuario, los roles y la MFA de ScreenConnect, y autentica las solicitudes con una clave de acceso compartida almacenada en la configuración de la extensión. En las versiones 1.0.31 y 1.0.32, esa clave tenía como valor predeterminado un campo en blanco, lo que significaba que la verificación de autenticación no rechazaba un valor vacío y un llamador podía pasar la verificación cuando no se había configurado ninguna clave.
La parte importante es la configuración de la clave de acceso:
<Setting Name="RMMPlus.AccessKey" IsServerOnly="true">
<Description>This is like a password. This is required to be sent in the POST request to access the functions. Set to a strong key..</Description>
<DefaultValue></DefaultValue>
</Setting>
La descripción le indica al administrador que configure una clave segura, pero si está vacía, introducirá la vulnerabilidad.
Esto coincidió con nuestras observaciones en este incidente. Los comandos llegaron a endpoints en varias instancias de ScreenConnect en cuestión de minutos. No hubo actividad de inicio de sesión correspondiente y los comandos aparecieron en los registros revisados vinculados a RMM+.
Un agradecimiento especial a Mendy Green por ayudarnos a validar estos hallazgos.
PUBLICACIÓN ORIGINAL
Contexto
El 11 de noviembre de 2026, Huntress observó a un operador que usaba acceso a múltiples paneles de ScreenConnect alojados en la nube para enviar comandos a grupos de endpoints administrados. Los comandos instalaron clientes de ScreenConnect controlados por el atacante y un kit de herramientas adicional llamado SCKit. Se han visto afectados al menos 288 endpoints en 48 organizaciones que usan Huntress.
En un aviso publicado a las 22:45 UTC del 11 de noviembre, ConnectWise informó que habían identificado cinco extensiones de terceros independientes que podrían estar asociadas con esta actividad; dijeron que aún no habían identificado un vector de acceso inicial ni el alcance completo del ataque. Deshabilitaron las siguientes extensiones en 400 entornos de socios como precaución:
Labtech Plus
RMM Plus
RMM+
RMM Plus Password Link
RMM+ Password Link
En septiembre de 2026, Huntress organizó una Respuesta Rápida ante una actividad similar de tipo gusano que generó clientes de ScreenConnect no autorizados en varios entornos de clientes. ConnectWise luego lanzó una actualización de seguridad para abordar una vulnerabilidad crítica de transferencia de archivos (CVE-2026-84869) que obtuvo una calificación de 9,9 en la escala CVSS.
Al analizar esta amenaza, hemos revisado la actividad desde dos frentes. Primero, examinamos lo que se observó en los incidentes que hemos visto, donde los actores de amenazas usaron la función Run command del panel de ScreenConnect para implementar SCKit en múltiples endpoints.
Luego, analizamos el código del kit para entender cómo fue construido para propagarse desde un endpoint infectado hasta la estación de trabajo de un técnico, y luego a otros endpoints accesibles a través de la sesión de ScreenConnect del técnico. No hemos observado que ese método de propagación funcione con éxito. El intento de toma de control de la consola falló en todos los registros de endpoints recuperados que hemos revisado hasta ahora.
Huntress continúa respondiendo y dando seguimiento a este incidente del 11 de noviembre; publicamos a continuación más información sobre las tácticas del atacante, un desglose de SCKit e indicadores de compromiso (IoC), con el fin de ayudar a los defensores que responden a este ataque.
Detalles técnicos
Aproximadamente a las 17:47 UTC del 11 de noviembre de 2026, Huntress observó actividad sospechosa en endpoints asociados con múltiples entornos de ScreenConnect. En total, vimos los 288 endpoints afectados en el transcurso de 90 minutos; alrededor de un tercio de ellos en los primeros 10 minutos.
La ruta de infección funciona en dos etapas: desde un endpoint infectado hasta un técnico que se conecta a él, y desde la estación de trabajo de un técnico hasta todos los endpoints a los que su panel puede conectarse. Sin embargo, no se ha observado toda la funcionalidad durante los incidentes observados; parte de la funcionalidad se descubrió al analizar los payloads.
Figura 1: Cronología del ataque en múltiples organizaciones
SCKit en detalle
SCKit es el nombre del kit de herramientas usado para llevar a cabo este ataque. Este kit de herramientas es un paquete de 16 archivos (scripts de PowerShell, scripts por lotes, archivos .cmd de línea de comandos de Windows y otros datos de configuración) diseñado para propagar la infección lateralmente, mediante un proceso de múltiples etapas.
Figura 2: El contenido del archivo SCKit descifrado
El kit se entrega como un payload cifrado, pero la máquina infectada proporciona la clave de descifrado real para extraer los archivos del paquete SCKit; cuando el gusano envía la solicitud para recuperar el kit desde su infraestructura, pasa el UUID del sistema Windows en el que se está ejecutando como parte de la cadena de consulta de la URL. El servidor devuelve datos de encabezado que incluyen una clave de cifrado, un vector de inicialización y un valor de sal, que el script usa para descifrar el paquete en la carpeta %temp% del objetivo.
Figura 3: Solicitud GET y respuesta del servidor
Como se ve en la figura 3 anterior, la cadena de consulta para recuperar el payload de SCKit incluye el GUID del equipo Windows en el que se ejecuta (texto resaltado superior). El servidor devuelve valores de descifrado que el script usará para extraer el payload en la carpeta %temp% del mismo equipo.
Actividad observada
Inicialmente observamos que la implementación del kit de herramientas llegaba a través de paneles de ScreenConnect, en lugar del comportamiento autorreplicante del kit. Parece que un operador usó la función Run command de las consolas para enviar comandos a varios endpoints a la vez, ejecutándose como SYSTEM.
Figura 4: Descripción general de la cadena de ataque
El comando primero verificó si existía un cliente de ScreenConnect, luego descargó un instalador de ScreenConnect controlado por el atacante a C:\Windows\TEMP\sc.msi y lo instaló en silencio. Luego escribió un dropper codificado en base64 en C:\Windows\Temp\sckit-run.bat.
El dropper luego se conecta a infraestructura controlada por el atacante y descarga C:\Windows\Temp\sckit-decoder.ps1, y luego obtiene una versión con clave del kit de herramientas SCKit para el sistema específico. Varios de los componentes del kit de herramientas realizan actividad adicional:
Panel-Lateral.ps1intenta tomar el control de la consola (sin éxito)sckit-loader.ps1descifra y lanza el script específico del equipok<32 Hex>.ps1
k[32 Hex].ps1luego extrae el kit de herramientas aC:\ProgramData\RelayTraplab-trap-cleanup-embedded.ps1limpia la instalación en la carpeta Temp
Figura 5: Secuencia de instalación en un endpoint
La trampa, junto con las políticas de bloqueo, se instalan luego mediante C:\ProgramData\RelayTrap\install.ps1 mientras CWInstall_<8 hex>-c1\
Installer.ps1 agrega exclusiones a Defender e instala un segundo cliente de ScreenConnect controlado por el atacante.
Finalmente, TrapWatch.ps1 se lanza como SYSTEM, y compila RelayTrap.cs en una copia específica del endpoint de C:\ProgramData\RelayTrap\trapbins\<client id>\RelayTrap.exe y crea una tarea programada llamada TrapWatch. Luego se detiene la instalación legítima de ScreenConnect, se configura para inicio manual, y la copia de ScreenConnect controlada por el atacante se coloca para reemplazarla.
Figura 6: El código fuente en C# del ejecutable RelayTrap parece haber sido generado por un LLM, según las referencias y comentarios detallados en el código fuente que explican exactamente qué está diseñado para hacer
Más funcionalidad en el código
Más allá de lo que hemos observado, reconstruimos una funcionalidad adicional diseñada para propagarse desde la estación de trabajo de un técnico hasta el panel de ScreenConnect. Esto se descubrió a partir del análisis de sus scripts, configuración y herramientas. Hasta la fecha no hemos observado un salto exitoso de un endpoint infectado a una estación de trabajo de un técnico, ni de esa estación de trabajo a otros endpoints.
Figura 7: Funcionalidad adicional, diseñada para propagarse desde las estaciones de trabajo de los técnicos.
Parece que esto se diseñó para esperar a que un técnico se conecte al relé y al endpoint comprometido. Una transferencia de archivo ocurre 2,5 segundos después de establecerse la conexión, y recupera una copia del dropper Run-Lateral-Full.bat desde el endpoint comprometido con la acción configurada en Run.
Este dropper está construido para conectarse a hxxps://ns.mo7sen[.]dev/EadF.php y descargar un loader en la estación de trabajo comprometida. El loader recopila el ID único de la estación de trabajo, lo envía de vuelta a la infraestructura del atacante, la cual devuelve un kit único y encriptado para esa estación de trabajo específica.
Panel-Lateral.ps1, con el apoyo de LabConfig.ps1, luego roba la cookie de sesión .aspxauth de la estación de trabajo e intenta reproducir la cookie contra el panel para obtener los tokens necesarios para enumerar cualquier otra sesión a la que el técnico tenga acceso.
A continuación, ToolboxRelayUploader.exe está diseñado para usar el acceso obtenido a cualquier otra sesión para subir un payload, WithUninstall.ps1, al Shared Toolbox del panel. Una solicitud del panel le indica a cada sesión alcanzable que ejecute el elemento del toolbox. Este payload está diseñado para ejecutarse como SYSTEM en esos endpoints, instalando la trampa y extendiendo el ciclo. Aproximadamente 60 segundos después de la transmisión, ToolboxRelayUploader.exe elimina el elemento del Shared Toolbox.
Guía de mitigación
Si usas ScreenConnect, revisa tu entorno ahora, incluso si no has recibido una alerta. Busca actividad masiva inesperada en el historial de Run Command y Toolbox de ScreenConnect, incluyendo comandos o herramientas que no hayas iniciado, y verifica si hay un segundo cliente de ScreenConnect no autorizado en los endpoints administrados.
Si sospechas que un endpoint está afectado:
No te conectes a él a través de ScreenConnect. Una sesión interactiva puede provocar que el malware se propague a la estación de trabajo del técnico y luego a otros paneles de ScreenConnect disponibles para ese técnico. Usa la respuesta en vivo de EDR, WinRM u otra herramienta CLI fuera de banda. Si un técnico ya se conectó a un endpoint sospechoso, trata esa estación de trabajo como potencialmente expuesta e investígala desde un dispositivo limpio.
Aísla el endpoint y mantenlo aislado hasta que la limpieza esté completa. El aislamiento por sí solo no elimina la persistencia, y se ha observado que los sistemas afectados se reinfectan poco después de que se levanta el aislamiento.
Elimina el cliente no autorizado de ScreenConnect y el mecanismo de persistencia. Busca y elimina el servicio de cliente falso, la tarea programada
TrapWatch,C:\ProgramData\RelayTrap\, y los archivos del kit de herramientas en%TEMP%(incluyendosckit-*,Panel-Lateral.ps1,runnew.cmd,ToolboxRelayUploader.exe, ysqlite3.exe). Verifica y elimina el valorRelayTrapLiteAlertenHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Verifica el cliente legítimo de ScreenConnect por separado antes de eliminar nada.Revoca el acceso que pudo haberse expuesto. Desde un dispositivo limpio, cierra las sesiones web activas de ScreenConnect y rota las credenciales afectadas de ScreenConnect. Como el kit de herramientas puede robar tokens de sesión del navegador, revoca también las sesiones potencialmente expuestas del navegador y del proveedor de identidad.
Revisa e investiga la actividad del panel. Audita el historial de Run Command y Toolbox de ScreenConnect en busca de ejecuciones no reconocidas, y usa los registros de auditoría de la instancia para investigar el acceso al panel y determinar qué sistemas y estaciones de trabajo de técnicos pueden estar afectados.
Usa SIEM para la búsqueda de amenazas. Si usas Huntress SIEM, asegúrate de que ScreenConnect esté conectado como fuente de datos para ayudar a Huntress a buscar actividad sospechosa de administrador en todo tu entorno a gran escala.
No pongas un endpoint de nuevo en servicio hasta que se haya eliminado el cliente falso y su mecanismo de persistencia, y se haya verificado el sistema en busca de reinfección. Continúa monitoreando los paneles de ScreenConnect y los endpoints en busca de actividad sospechosa.
Indicadores de compromiso (IOC)
Ten en cuenta que los hashes de archivo son indicadores débiles para esta actividad, ya que los scripts se reconstruyen con diferentes valores incorporados, y el ejecutable de la trampa se compila por separado en cada endpoint.
Elemento | Descripción |
|---|---|
| Servidor de ScreenConnect del atacante; sirve el instalador del cliente |
| Relay del atacante, resuelve a la IP anterior |
| Panel de ScreenConnect controlado por el atacante. Está en la lista de exclusión del malware, en |
| Relay del atacante que resuelve a 185.99.255[.]28 y también está en la lista de exclusión. |
| Dominio C2, originalmente marcado por BlackPoint |
| Stager |
| Entrega una copia de la herramienta de línea de comandos SQLite, que el malware usa para leer las bases de datos de cookies del navegador y robar las cookies de sesión de ScreenConnect. |
| IDs de clientes falsos |
| Nombre de participante del atacante |
| Patrón de instalador |
SHA256: | El script instalador principal del gusano, pero sin un archivo de configuración. |
SHA256:
| El script instalador principal del gusano. Roba la cookie de inicio de sesión de SC de un técnico, y luego envía una carga a cada sesión a la que el técnico tenga permiso de acceder |
SHA256:
| Una biblioteca auxiliar que descifra cookies, sondea los paneles de SC y genera URL de instalador de clientes falsos |
SHA256:
| Código fuente de la trampa. Reutiliza las bibliotecas de código propias del cliente real de ScreenConnect del equipo y sus detalles de conexión para tomar el lugar de ese cliente en el relay legítimo de SC, de modo que el endpoint siga pareciendo normal. |
SHA256:
| Se ejecuta como SYSTEM cada 10 segundos; detiene los clientes legítimos de ScreenConnect y toma el control de su slot de conexión. |
SHA256:
| Configura la trampa en |
SHA256:
| Un archivo PE .NET de 32 bits que carga las propias bibliotecas de ScreenConnect del cliente y se conecta a una sesión como técnico (el rol de Host), usando un token de acceso robado. Luego sube el payload al Shared Toolbox del panel ( |
SHA256:
| Se ejecuta al iniciar sesión el usuario y registra los eventos "file run" de ScreenConnect (ID de evento 201) y los nuevos servicios de cliente de ScreenConnect instalados, con las alertas en pantalla desactivadas a propósito. |
SHA256:
| Obtiene un payload desde |
SHA256:
| Elimina la trampa usando solo herramientas integradas de Windows: borra la tarea |
SHA256:
| Elimina solamente las reglas de SRP/AppLocker y detiene el servicio AppLocker, para cuando esas reglas han bloqueado el propio |
SHA256:
| Archivo de configuración que viaja con el kit. Apunta al gusano hacia el panel del atacante y contiene la clave RSA y los valores de ID de cliente falsos. |
SHA256:
| Agrega una línea a |
SHA256:
| Hace lo mismo que el dropper, pero ejecuta el decodificador en |
SHA256:
| Es el dropper: establece |
SHA256:
| Descarga |
| Nombres de equipos excluidos como objetivo cuando el gusano envía su payload a cada sesión en un panel, probablemente para evitar que el atacante infecte sus propios dispositivos |
