SCKit explota ScreenConnect: parchea ya o expón tu soporte remoto

El detalle que cambia el diagnóstico: no hay vulnerabilidad nueva

Cuando se detecta una campaña activa contra una herramienta de acceso remoto, la reacción instintiva es pensar en un fallo de día cero. En este caso, la información apunta en otra dirección: el conjunto de herramientas del atacante, bautizado como SCKit, no aprovecha una vulnerabilidad desconocida, sino una brecha crítica ya corregida en ConnectWise ScreenConnect. Según los datos compartidos con The Hacker News por el Adversary Pursuit Group de Blackpoint Cyber, el kit recuperado explota CVE-2026-84869, con una puntuación CVSS de 9,9.

Ese matiz es importante. No estamos ante un problema que exija esperar a que el fabricante publique una solución: la solución existe. El riesgo real se concentra en las instalaciones que no han aplicado la actualización, en las que la han aplicado tarde o en aquellas donde el software de soporte remoto vive en una esquina de la infraestructura que nadie revisa con la frecuencia debida.

Por qué ScreenConnect es un objetivo apetitoso

Las herramientas de acceso remoto son, por definición, puertas legítimas. Están diseñadas para que alguien de fuera entre en un equipo y tome el control. Esa funcionalidad es exactamente lo que necesita un proveedor de servicios gestionados para atender a sus clientes, pero también es lo que busca un atacante que quiere moverse sin levantar demasiadas alarmas.

El enfoque de SCKit encaja con una tendencia que venimos observando: en lugar de romper la autenticación desde cero, se aprovecha una sesión de soporte para colarse en el entorno. Si la herramienta está mal parcheada, el atacante puede convertir lo que debería ser una vía de asistencia en un camino de entrada. Y si esa herramienta la usan varios clientes a través de un mismo proveedor, el impacto potencial se multiplica.

Para una pyme, la lectura es directa: el software que instaló para que su informático o su proveedor le ayudara en remoto no es un elemento neutro. Es una superficie de ataque más, y merece el mismo rigor que el correo, la VPN o el firewall.

Qué significa para un equipo de IT con recursos limitados

En una pyme no suele haber un equipo de seguridad dedicado las 24 horas. La gestión de parches compite con el día a día, y las herramientas de soporte remoto tienden a quedar fuera del radar porque "las usa el proveedor" o "las instalamos hace años y funcionan". Precisamente por eso conviene tratarlas como infraestructura crítica.

Hay tres escenarios que conviene revisar sin dramatismo, pero sin demora:

• Instalaciones propias: si tu empresa aloja ScreenConnect o cualquier otra solución de acceso remoto, comprueba la versión y aplica las actualizaciones pendientes. No basta con saber que existe un parche: hay que verificar que está instalado.
• Acceso delegado a un proveedor: si es un tercero quien gestiona la herramienta, pídele confirmación por escrito de la versión desplegada y de la fecha del último parche. La confianza sin verificación es un riesgo heredado.
• Equipos con el cliente instalado: revisa qué endpoints tienen agentes de acceso remoto y si todos siguen siendo necesarios. Cada instalación olvidada es una puerta que nadie vigila.

Recomendaciones concretas para esta semana

Más allá de aplicar el parche, que es la acción prioritaria, proponemos una lista de comprobaciones que una pyme puede abordar con su proveedor de IT o con su equipo interno:

1. Inventario de herramientas de acceso remoto: saber qué hay instalado, en qué versiones y quién tiene permiso para usarlo. Sin inventario no hay control.
2. Revisión de accesos y privilegios: limitar quién puede iniciar sesiones y desde dónde. El acceso remoto no debería estar abierto a cualquier cuenta ni a cualquier red.
3. Autenticación reforzada: activar segundo factor en las consolas de administración de la herramienta, no solo en el correo.
4. Registro y monitorización: conservar logs de sesiones y revisar accesos fuera de horario o desde ubicaciones inesperadas. Una sesión de soporte legítima tiene un contexto; una intrusión, no.
5. Plan de respuesta: si se detecta una sesión sospechosa, saber a quién avisar, qué aislar y cómo revocar credenciales sin improvisar.

Este caso recuerda a otros avisos recientes que hemos publicado, como el de N-central y los exploits que saltan el parche o el de Apache HTTP/2: la ventana entre la publicación de un parche y su aplicación masiva sigue siendo el terreno favorito de los atacantes. La diferencia, en el caso de las herramientas de soporte remoto, es que el atacante no necesita buscar un fallo nuevo: le basta con encontrar una puerta que debería haberse cerrado.

La lección de fondo

SCKit no es una historia sobre un fabricante descuidado, sino sobre la brecha entre disponibilidad de parche y despliegue real. Para una pyme, la conclusión práctica es sencilla: trata el software de acceso remoto como tratarías el correo corporativo o la VPN. Verifica versiones, limita permisos, activa segundo factor y revisa logs. Y si dependes de un proveedor, exige confirmación documentada. La comodidad del soporte remoto no debería convertirse en la comodidad del atacante.

Fuente: The Hacker News. Análisis y adaptación: ForgeNEX.