SCKit toma 288 equipos por una extensión de ScreenConnect sin clave

Nadie inició sesión en los paneles y, aun así, el 11 de noviembre de 2026 a las 17:47 UTC los comandos empezaron a llegar a los equipos gestionados por ScreenConnect, porque entraron por RMM+, una extensión de terceros que en sus versiones 1.0.31 y 1.0.32 acepta una clave de acceso vacía. En 90 minutos un cliente falso y el kit SCKit estaban instalados en 288 equipos de 48 organizaciones, según Huntress, y ConnectWise ha desactivado cinco extensiones en unos 400 entornos de partners mientras mantiene que no hay ninguna vulnerabilidad en ScreenConnect.

• Hecho: desde el 11 de noviembre a las 17:47 UTC un operador usó Run Command en paneles de ScreenConnect alojados para instalar clientes falsos y el kit SCKit.
• Afectados: 288 equipos de 48 organizaciones y al menos seis MSP en la telemetría de Huntress, con etiquetas que apuntan a víctimas anteriores.
• Vía de entrada más probable: la extensión RMM+ 1.0.31 y 1.0.32 acepta una clave de acceso vacía y se salta cuentas, roles y MFA.
• Estado: ConnectWise desactivó cinco extensiones en unos 400 entornos alojados el 11 de noviembre y sigue investigando el acceso inicial.
• Acción urgente: desactivar esas extensiones en los servidores on-premise, revisar el historial de Run Command y buscar la tarea TrapWatch en los endpoints.

El diagrama con el que Huntress resume la cadena separa con una línea discontinua lo que vio en los registros (un Run Command como SYSTEM desde la consola del MSP, el instalador sc.msi, el dropper sckit-run.bat y el cliente sustituido en 11 a 21 segundos) de lo que solo ha reconstruido del código, que es todo el tramo que apunta a la estación del técnico. Esa distinción recorre toda la noticia.

Noventa minutos, 48 organizaciones y ningún inicio de sesión en los paneles

La cronología la fija el informe de Huntress, firmado por Ben Nahorney y Susannah Matt. Hacia las 17:47 UTC del 11 de noviembre su SOC vio actividad sospechosa en endpoints vinculados a varios entornos de ScreenConnect alojados en la nube de ConnectWise. Un operador usaba la función Run Command de los paneles, que ejecuta como SYSTEM, para lanzar órdenes a grupos de equipos gestionados. Los 288 hosts cayeron en unos 90 minutos y un tercio de ellos en los diez primeros. SecurityWeek, citando a Huntress, cifra en al menos seis los MSP comprometidos.

El fabricante publicó su aviso a las 22:45 UTC en su centro de confianza. ConnectWise identificó unos 400 entornos de partners con al menos una de cinco extensiones de terceros instalada (Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link y RMM+ Password Link), las desactivó en los entornos alojados y pidió a los clientes on-premise que hicieran lo mismo. Sostiene que no hay pruebas de un compromiso de su infraestructura ni de un fallo en ScreenConnect, y reconoce que «The initial access method and full scope remain under investigation» (el método de acceso inicial y el alcance completo siguen bajo investigación). Sobre las extensiones, advierte de que «Their presence alone does not establish compromise» (su sola presencia no establece un compromiso), porque la API de ejecución remota que exponen va protegida por una contraseña que configura el partner.

Sophos X-Ops investiga la misma campaña en una alerta paralela y aporta tres identificadores de instancias de ScreenConnect que considera comprometidas y usadas para desplegar los clientes maliciosos: d905b2b1b165d0a9, 4b8f4089ddaac6a9 y df1f7ef0cfacd0d8. Los dos identificadores de los clientes del atacante, 2588ef5c15954b10 y ed630cc2c873b091, coinciden con los que publica Huntress.

Esta noticia se suma al hilo que el blog sigue sobre ConnectWise desde la credencial robada de Cloud Backup en octubre, aunque son incidentes distintos. Aquel afectaba a identidades de aplicación en Microsoft 365 y acabó atribuido por Microsoft a Storm-0940, con una tercera entrega sobre Storm-3358 el 7 de noviembre. Este toca el producto de acceso remoto y llega en la misma semana en que N-able tuvo que apagar N-central por 33 zero-days. Nadie ha atribuido la campaña de SCKit a ningún grupo y ninguna fuente menciona ransomware ni robo de datos en los equipos afectados.

RMM+ 1.0.31 y 1.0.32, una clave vacía que salta usuarios, roles y MFA

La actualización que Huntress añadió a su informe a las 23:34 de la costa este del 11 de noviembre (04:34 UTC del 12) explica por qué los paneles no registraron ningún inicio de sesión. RMM+ permite que otra herramienta gestione sesiones de ScreenConnect sin que un técnico toque la consola, y para ello se salta las cuentas de usuario, los roles y el MFA del producto y autentica las peticiones con una clave compartida guardada en la configuración de la extensión. En las versiones 1.0.31 y 1.0.32 el ajuste RMMPlus.AccessKey tiene un valor por defecto vacío. Si el administrador nunca configuró una clave, la comprobación acepta una en blanco y cualquiera que conozca la API puede ejecutar comandos.

La mayoría de las instalaciones que Huntress encontró eran legítimas, «usually added for a project and left in place» (añadidas normalmente para un proyecto y dejadas ahí). Los comandos aparecían en los registros vinculados a RMM+ y no a ninguna cuenta, lo que encaja con un acceso que nunca pasó por la pantalla de login. ConnectWise, por su parte, sigue sin confirmar que esa sea la vía de entrada y la trata como hipótesis principal. Hasta la noche del 11 su telemetría apuntaba a credenciales robadas o a sesiones de operador secuestradas, y es la versión que recogió The Hacker News antes de que Huntress publicara el hallazgo sobre la extensión.

Las versiones de ScreenConnect que Huntress cita como afectadas, 26.6.6.9747 y 26.7.6.9783, son las más recientes. Dicho de otro modo, estar al día en el servidor no protege de esta campaña, porque el fallo está en un complemento de terceros y no en el producto.

De sckit-run.bat al cliente oculto en 52 segundos

Antes de que SCKit entre en escena, la consola del operador manda tres órdenes: un listado de directorio para comprobar si hay cliente de ScreenConnect, una descarga con curl.exe del instalador del atacante desde 185.99.255.28 a C:\Windows\TEMP\sc.msi, y un msiexec silencioso que lo instala. Sophos describe la misma secuencia en sus clientes y añade que los scripts generados por ScreenConnect lanzaban PowerShell con la política de ejecución desactivada para traer la segunda etapa desde ns.mo7sen.dev.

La secuencia de instalación que reconstruye Huntress a partir de los registros dura menos de un minuto. En el segundo 0 PowerShell decodifica un blob en base64 y escribe C:\Windows\Temp\sckit-run.bat. A los 6 segundos descarga el decodificador desde EadF.php?p=4 y a los 8 el decodificador pide al servidor un paquete cifrado con clave propia para ese equipo. A los 11 segundos Panel-Lateral.ps1 intenta tomar la consola y falla, a los 14 el script k<32 hex>.ps1 extrae el kit a C:\ProgramData\RelayTrap, a los 18 install.ps1 monta la trampa y las políticas de bloqueo, y a los 21 Installer.ps1 añade exclusiones en Microsoft Defender e instala un segundo cliente de ScreenConnect controlado por el atacante mientras TrapWatch.ps1 arranca y sustituye al cliente legítimo. A los 52 segundos el cliente del atacante desaparece de la lista de programas instalados con SystemComponent a 1. Dos equipos más de la misma organización siguieron el mismo guion con tres segundos de diferencia.

La captura de la petición al servidor muestra cómo se personaliza el kit. El cliente infectado llama a EadF.php con el parámetro m, que lleva el UUID de Windows del equipo, y la respuesta devuelve en las cabeceras X-Lab-Half, X-Lab-IV y X-Lab-Salt el material para descifrar el paquete en %TEMP%. La fecha de la respuesta, las 21:48:19 GMT del 11 de noviembre, sitúa la captura en plena oleada, y el servidor responde detrás de Cloudflare con PHP 8.2.12, lo que complica bloquearlo por IP.

El contenido del archivo descifrado son 16 ficheros entre scripts de PowerShell, batch, cmd y configuración. Las fechas de modificación del listado cuentan la preparación: ToolboxRelayUploader.exe es del 29 de octubre, los scripts de movimiento lateral del 6 y el 7 de noviembre, y Panel-Lateral-free.ps1, Run-Lateral-Full.bat y Stop-LabTrap.bat se tocaron la mañana del 11, el día del ataque. Huntress señala que al menos uno de los componentes, el código C# de RelayTrap, parece generado por un modelo de lenguaje por sus referencias y comentarios, en la línea de lo que ya contamos sobre los agentes de IA en las intrusiones de Aur0ra.

La persistencia tiene tres patas. Una tarea programada llamada TrapWatch corre como SYSTEM cada diez segundos, compila RelayTrap.cs en trapbins\<client id>\RelayTrap.exe, detiene el servicio legítimo de ScreenConnect, lo pone en manual y lo sustituye por la copia del atacante, que reutiliza las bibliotecas y los datos de conexión reales del equipo para ocupar su hueco en el relay sin que el panel note nada raro. Un valor RelayTrapLiteAlert en la clave Run de HKLM relanza Lite-Alert.ps1 en cada inicio de sesión para registrar los eventos 201 de ejecución de ficheros y los servicios de cliente nuevos. Y install.ps1 añade reglas de SRP y AppLocker que bloquean los ficheros que lleguen por las carpetas temporales de ScreenConnect, de modo que el MSP legítimo no pueda empujar una herramienta de limpieza por el mismo canal.

La trampa para el técnico que Huntress todavía no ha visto funcionar

El nombre de la carpeta, RelayTrap, describe la segunda fase. El cliente falso espera a que un técnico del MSP se conecte al equipo infectado y, 2,5 segundos después de que entre en la sesión, le envía por transferencia de ficheros el dropper Run-Lateral-Full.bat con la acción Run. Ese comportamiento coincide con el que ConnectWise corrigió en septiembre bajo CVE-2026-84869, el fallo del cliente que permitía transferir y ejecutar ficheros sin confirmación del host, aunque Huntress no ha comprobado si un cliente parcheado lo bloquea. NVD le asigna un CVSS 3.1 de 9,9 (vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) y CISA lo incluyó en su catálogo KEV el 11 de septiembre con plazo hasta el 14. Es la misma idea que vimos en el fallo de TeamViewer que dejaba al equipo asistido atacar al técnico, llevada aquí a un producto distinto y con un kit completo detrás.

El diagrama de los once pasos enumera lo que el código pretende hacer desde la estación del técnico: descargar un loader desde ns.mo7sen.dev, pedir un kit cifrado para esa máquina, robar con sqlite3.exe la cookie de sesión .aspxauth del navegador, reproducirla contra el panel para obtener el token antifalsificación y el token de acceso de host, listar todas las sesiones, subir con ToolboxRelayUploader.exe el payload WithUninstall.ps1 a la Shared Toolbox, ordenar con una sola petición que cada sesión lo ejecute como SYSTEM (los equipos apagados quedan en cola) y borrar el elemento 60 segundos después. Con eso la trampa se instalaría en todos los endpoints que alcance ese panel y el ciclo volvería a empezar con el siguiente técnico.

Huntress subraya lo que no ha pasado y lo escribe sin ambigüedad: «To date we have not observed a successful jump» (hasta la fecha no hemos observado un salto con éxito) ni del endpoint a la estación del técnico ni de esa estación a otros equipos, y el intento de tomar la consola falló en todos los registros de hosts recuperados que ha revisado. La capacidad de gusano existe en el código y está diseñada con cuidado, pero por ahora la propagación observada ha dependido de que el operador lanzara Run Command desde paneles a los que ya tenía acceso.

Hay un detalle que amplía el alcance más allá de lo medido. El instalador que descarga cada equipo lleva en la URL una etiqueta Exploited seguida de un número correlativo por MSP, con el nombre de participante Addmin, y las etiquetas que Huntress ha visto empiezan a mitad de la secuencia. La lectura es que hubo MSP comprometidos antes de las 17:47 UTC que no están entre sus clientes, y por eso pide revisar el historial de Run Command aunque no haya saltado ninguna alerta. El kit también trae una lista de equipos que no debe infectar (desktop-vmc0ifs, send y sc-observation-lab), que parecen ser las máquinas del propio atacante.

Desactivar las extensiones no limpia el endpoint, qué hacer en cada panel

ConnectWise y Huntress coinciden en que apagar RMM+ corta la vía de entrada, pero no toca nada de lo que ya se instaló. La frase de Huntress sobre el aislamiento vale para todo el proceso: «Isolation alone does not remove the persistence» (el aislamiento por sí solo no elimina la persistencia), y ha visto equipos reinfectarse al levantarlo. Este fragmento de PowerShell comprueba en un equipo Windows, desde una sesión que no sea de ScreenConnect, las cuatro huellas que deja SCKit y lista los servicios de cliente instalados para detectar el segundo.

Get-ScheduledTask -TaskName 'TrapWatch' -ErrorAction SilentlyContinue |
  Select-Object TaskName, State
Test-Path 'C:\ProgramData\RelayTrap'
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run' |
  Select-Object -ExpandProperty RelayTrapLiteAlert -ErrorAction SilentlyContinue
Get-ChildItem "$env:TEMP", 'C:\Windows\Temp' -Include 'sckit-*','Panel-Lateral*.ps1','runnew.cmd','ToolboxRelayUploader.exe' -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, LastWriteTime
Get-Service | Where-Object { $_.Name -like 'ScreenConnect Client*' } |
  Select-Object Name, Status, StartType

Si aparece la tarea, la carpeta, el valor de registro o un segundo servicio de cliente cuyo identificador no sea el de tu instancia, el equipo está comprometido. A partir de ahí, las acciones van por orden de urgencia.

1. Si tu ScreenConnect es on-premise, desactiva hoy Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link y RMM+ Password Link desde la administración de extensiones. En los entornos alojados ConnectWise ya lo hizo el 11 de noviembre. Si vas a reactivar RMM+, hazlo solo con una clave de acceso larga configurada y en una versión que rechace la clave vacía.
2. Revisa el historial de Run Command y de la Toolbox de cada panel desde las 17:47 UTC del 11 de noviembre y busca ejecuciones en bloque que no lanzaste, instalaciones de extensiones inesperadas y descargas de sc.msi. Los comandos que entraron por RMM+ no tienen inicio de sesión asociado, así que mira los registros de la extensión y no te quedes en los de autenticación.
3. Busca en todos los endpoints gestionados un segundo cliente de ScreenConnect con los identificadores 2588ef5c15954b10 o ed630cc2c873b091, la tarea TrapWatch, la carpeta C:\ProgramData\RelayTrap, el valor RelayTrapLiteAlert y los ficheros sckit-* en las carpetas temporales. Verifica antes cuál es el cliente legítimo para no borrarlo.
4. No entres por ScreenConnect en ningún equipo sospechoso. Usa la respuesta en vivo del EDR, WinRM u otra herramienta fuera de banda. Si un técnico ya se conectó a un equipo infectado, trata su estación como expuesta e investígala desde un dispositivo limpio.
5. Aísla cada host afectado y mantenlo aislado hasta haber retirado el cliente falso, la tarea, la carpeta, el valor de registro y las reglas de SRP y AppLocker que dejó install.ps1. Comprueba que no se reinfecta antes de devolverlo al servicio.
6. Desde un equipo limpio, cierra todas las sesiones web activas de ScreenConnect, rota las credenciales del panel y revoca las sesiones de navegador y del proveedor de identidad de los técnicos, porque el kit está diseñado para robar la cookie .aspxauth.
7. Confirma que los clientes de ScreenConnect están en la versión 26.6.5 o superior, que cierra CVE-2026-84869, y bloquea en el perímetro las IP y los dominios de la tabla de indicadores que sigue.
8. Notifica la actividad a ConnectWise en SecurityPartnerSupport@ConnectWise.com y, en España, a INCIBE-CERT (empresas y MSP) o al CCN-CERT (administraciones públicas). Si en los equipos había datos personales, prepara la notificación a la AEPD en 72 horas.

Estos son los indicadores que publican ConnectWise, Huntress y Sophos. Huntress avisa de que los hashes son indicadores débiles, porque los scripts se reconstruyen para cada equipo, y la lista completa con los 16 ficheros está en su informe.

Al cierre de esta noticia, a las 13:00 UTC de hoy, 12 de noviembre, ni INCIBE-CERT ni CCN-CERT han publicado aviso sobre la campaña y no hay recuento público de paneles de ScreenConnect expuestos en España. El producto es habitual en el canal MSP que da soporte a pymes y ayuntamientos, y cada panel comprometido abre de golpe todos los equipos que gestiona, como ya mostró el uso de ScreenConnect por los afiliados de SafePay que describieron el FBI y CISA.

La campaña plantea un problema incómodo a quien administra un panel. ScreenConnect estaba parcheado, el MFA estaba activo y nada de eso contó, porque una extensión instalada para un proyecto hace meses tenía su propia puerta y nadie le había puesto cerradura. Nuestra lectura es que el inventario de extensiones de un RMM merece el mismo trato que el de las aplicaciones OAuth en un tenant: cada una es una identidad con permisos de ejecución remota, y si no se revisa se convierte en el eslabón que el atacante prefiere. Lo cuenta con más detalle, aplicado a Windows, nuestra guía para blindar un PC, donde AppLocker y las exclusiones de Defender aparecen como herramientas del defensor y aquí las vemos usadas al revés.

El fragmento de RelayTrap.cs que publica Huntress tiene más comentario que código. Describe el programa como una trampa inversa contra el operador de ScreenConnect, con un payload de prueba que abre el Bloc de notas en la máquina del atacante y una explicación de por qué usa reflexión para seguir funcionando cuando el cliente 26.6 movió sus clases internas de ScreenConnect.Core.dll a ScreenConnect.Client.dll. Ese nivel de documentación es lo que lleva a Huntress a atribuir el código a un modelo de lenguaje, y la etiqueta de herramienta defensiva con la que está escrito encaja con la forma en que un atacante le pediría a un asistente de IA que escribiera algo que de otro modo rechazaría.

Falta por saber cuántos MSP cayeron antes de que Huntress empezara a contar, si ConnectWise acabará confirmando RMM+ como vía de entrada y si alguien verá funcionar el salto al técnico fuera del laboratorio. Entre el 20 de agosto, cuando Huntress vio los primeros clientes de ScreenConnect propagándose solos, y el 11 de noviembre han pasado menos de tres meses, y el kit de noviembre es una versión mucho más elaborada de aquella cadena de cuatro VBScript.

Dudas de los usuarios sobre el cliente de ScreenConnect

¿Qué es ScreenConnect y para qué sirve?

ScreenConnect es el software de acceso y soporte remoto de ConnectWise, muy usado por proveedores de servicios gestionados para administrar los equipos de sus clientes desde un panel central. El servidor puede estar alojado por ConnectWise o instalado en la empresa, y el panel admite extensiones de terceros, como RMM+, que añaden funciones de automatización. En esta campaña el fallo estaba en una de esas extensiones y no en el producto.

¿Qué es ScreenConnect.ClientSetup.exe y es seguro?

Es el instalador del cliente que el panel genera para cada equipo que va a gestionar, y en los sistemas administrados por un MSP es normal encontrarlo. Lo que no es normal es que haya dos clientes instalados a la vez, que uno de ellos no aparezca en la lista de programas o que el servicio lleve un identificador de instancia que tu proveedor no reconoce. En esos casos pide al MSP que lo compruebe desde fuera de ScreenConnect antes de volver a conectarse.