Volver al blog
Análisis de incidentes

La herramienta que lo arregla todo puede romperlo todo: el RMM como vía de ataque

Equipo de Plaza Cyber Security15 de abril de 20266 min readIncidente: 6 feb – 15 abr 2026
Una sala de control industrial vacía, rodeada de paneles de instrumentos

Vendemos servicios administrados. Operamos herramientas de gestión remota en los entornos de nuestros clientes. Así que escribir esto resulta incómodo, y justamente por eso debería salir de nosotros y no solo de quienes no tienen nada en juego.

Qué pasó

El 6 de febrero de 2026, BeyondTrust reveló la CVE-2026-1731, una falla crítica en su producto de soporte remoto Bomgar que permitía ejecución remota de código sin autenticación. La explotación empezó en menos de una semana. Huntress observó una primera oleada desde el 12 de febrero y un repunte marcado a partir del 3 de abril.

Dos incidentes de esa segunda oleada merecen decirse con claridad.

El 14 de abril, una instancia comprometida de Bomgar en una empresa de software dental sirvió para desplegar ransomware. Tres empresas aguas abajo resultaron afectadas: clientes de ese proveedor, atacados a través de él.

El 15 de abril, los atacantes tomaron una cuenta de Bomgar con altos privilegios perteneciente a un MSP. Desde ahí llegaron a un controlador de dominio, crearon credenciales de administrador para mantener persistencia y escalaron a Domain Admin. La respuesta exigió aislar de forma masiva a 78 empresas, con explotación confirmada en cuatro clientes aguas abajo.

UNA CUENTA MSP COMPROMETIDAconsola RMM78 EMPRESAS AISLADAS4 clientes finales explotados confirmados
El radio de impacto no lo define a cuántos clientes se atacó, sino a cuántos podía llegar una sola consola comprometida.

El patrón no se limitó a un producto. Sophos documentó a operadores del ransomware DragonForce explotando una cadena de vulnerabilidades de SimpleHelp —CVE-2024-57727, CVE-2024-57728 y CVE-2024-57726— para alcanzar la plataforma de gestión remota de un MSP y empujar instaladores maliciosos a los equipos de sus clientes, exfiltrando datos en el camino para una doble extorsión.

Y los atacantes no siempre necesitan una vulnerabilidad. En julio, Microsoft rastreó campañas de phishing que convencían a sus objetivos de instalar un agente legítimo de MSP360, y después usaban ese punto de apoyo para instalar un cliente de ConnectWise ScreenConnect como segundo canal redundante. Sin exploit: solo software de gestión remota legítimo, instalado por la víctima, sirviendo al atacante.

Por qué estas herramientas son un objetivo tan bueno

Una plataforma de monitoreo y gestión remota existe para hacer tres cosas en muchas máquinas a la vez: verlas, cambiarlas y ejecutar cosas en ellas. Ese es el valor. Y también es, dicho sin el lenguaje comercial, una capacidad de ejecución remota de código con una consola administrativa adelante.

Tres propiedades la vuelven especialmente atractiva:

Alcance. Una consola puede tocar todos los equipos bajo gestión, muchas veces de varias empresas sin relación entre sí. Comprometer una cuenta de un MSP equivale a comprometer decenas de compañías por separado.

Confianza. El agente está firmado, es esperado y está en la lista de permitidos. La protección de endpoints está configurada para no interferir con él. Las acciones que ejecuta parecen administración porque son administración.

Acceso permanente. A diferencia de una credencial de usuario robada, que da los permisos de una persona, el acceso RMM está diseñado para ser privilegiado y persistente.

Es el mismo problema estructural que el borrado de Stryker a través de Intune y que la propagación de ChainDrop por npm: aquello construido para aplicar un cambio en todas partes es lo que más quiere un atacante, y funciona correctamente cuando lo usa.

Qué significa esto si contratas servicios administrados

Si alguien administra tu TI, su seguridad es parte de la tuya, aparezca o no en el contrato. Eso no es un argumento contra tercerizar: un equipo interno con las mismas herramientas tiene la misma exposición y normalmente menos práctica. Es un argumento para hacer preguntas concretas.

Pregúntale a tu proveedor, por escrito:

  • ¿El MFA es obligatorio en la consola RMM para cada técnico, y es resistente al phishing? Las notificaciones push y los códigos por SMS son la respuesta aceptable más débil; las llaves de hardware o las passkeys son la correcta.
  • ¿Cuál es su SLA de parcheo para la propia herramienta de gestión? La falla de Bomgar se reveló el 6 de febrero y se explotó en días. Pregunta con qué rapidez parchan la plataforma que controla tus máquinas, no con qué rapidez parchan las tuyas.
  • ¿El acceso a la consola está restringido por IP de origen o por red? Una interfaz administrativa alcanzable desde todo internet es alcanzable por todo internet.
  • ¿Hay separación de inquilinos o de credenciales por cliente? Cuando se compromete una cuenta de un MSP, lo que define tu radio de impacto es si desde ahí se alcanzaban los entornos de sus otros clientes.
  • ¿Qué requiere la aprobación de una segunda persona? La ejecución masiva de scripts, el despliegue masivo de software y los comandos sobre todo el parque no deberían estar a un técnico cansado de distancia.
  • ¿Qué muestran sus registros, y me avisarían? Pregunta quién revisa los registros de auditoría del RMM, cómo se detecta una acción masiva anómala y a qué se comprometen en cuanto a avisarte cuando algo involucre tu entorno.
  • ¿Los han comprometido alguna vez, y qué pasó? Un "no, nunca" de alguien que lleva años operando a escala merece más escepticismo que un relato directo de un incidente y de lo que cambió después.

Si a un proveedor le incomoda responder esto, esa incomodidad ya es información. Preferimos que nos hagas estas preguntas a que no nos las hagas; y si eres cliente y quieres nuestras respuestas por escrito, pídelas y las ponemos por escrito.

Qué significa si operas la herramienta tú mismo

Aplica la misma lista, con un agregado: el RMM entra en tu propia gestión de vulnerabilidades, y entra arriba. Es habitual que una organización parche sus endpoints con disciplina a través de una plataforma que ella misma no actualiza desde hace meses. Revisa en qué versión está tu consola antes de seguir leyendo.

El resumen

Durante la primavera de 2026, los atacantes tomaron repetidamente el camino más corto disponible: comprometer la herramienta que ya tiene permiso para cambiarlo todo y dejar que haga el trabajo. A veces hizo falta un CVE crítico; a veces, un correo de phishing convincente y un instalador legítimo.

No existe una versión de la TI administrada que elimine este riesgo, porque la capacidad que se abusa es la capacidad que se vende. Lo que sí puede cambiar es qué tan difícil es alcanzar esa consola, con qué rapidez se parcha, cuánto del mundo puede tocar una sola cuenta comprometida y si alguien la está mirando. Esas preguntas tienen respuesta, y un proveedor que valga la pena las responde sin que haya que insistir.

Fuentes

#rmm#msp#supply chain#ransomware#incident analysis