Incidente de ConnectWise Cloud Backup: qué deben aprender los MSP sobre permisos y riesgos en cadena

Cuando una integración de copias de seguridad se convierte en un riesgo de identidad

Los proveedores de servicios gestionados (MSP) dependen de las integraciones para ofrecer copias de seguridad, seguridad y administración de manera uniforme a numerosos clientes. Estas integraciones ahorran tiempo, pero también imponen una responsabilidad: saber a qué puede acceder cada aplicación del proveedor y qué ocurre si su identidad se ve comprometida.

El incidente de ConnectWise Cloud Backup, anteriormente SkyKick, es un ejemplo reciente. El 21 de octubre, ConnectWise informó de un acceso no autorizado a credenciales de aplicaciones asociadas al servicio y comunicó que había comenzado a restablecer los servicios por fases controladas después de aplicar medidas de contención y validación de seguridad. La empresa indicó que los archivos de las copias de seguridad almacenadas permanecían cifrados, aislados y conservados, sin indicios de que dichos archivos se hubieran visto comprometidos. Esa afirmación no determina si los entornos Microsoft 365 activos de clientes individuales resultaron afectados.

La diferencia es fundamental. La integridad de las copias almacenadas, la seguridad del tenant de Microsoft 365 y la capacidad para ejecutar una restauración son tres cuestiones distintas. Una plataforma puede conservar los datos mientras se interrumpe temporalmente el acceso al servicio y mientras cada tenant todavía necesita una investigación.

Qué observaron los investigadores

El 15 de octubre, investigadores de Huntress y Todyl observaron autenticaciones no autorizadas en Microsoft 365 que utilizaban la identidad legítima de la aplicación ConnectWise Cloud Backup. La aplicación ya contaba con permisos concedidos previamente en los entornos de clientes; el atacante no necesitaba iniciar sesión como un empleado para aprovechar ese acceso de aplicación.

Huntress había confirmado inicios de sesión no autorizados de la aplicación en 162 tenants hasta el 16 de octubre a las 19:00 UTC. Se trataba de una cifra puntual de su investigación, no del número definitivo de clientes afectados. Huntress también documentó cambios posteriores al acceso relacionados con otra identidad de ConnectWise Cloud Management en un número reducido de entornos, incluida la incorporación de credenciales a otras aplicaciones. Por su parte, Todyl indicó que no había observado esos cambios de directorio en los tenants que analizó. Se trata de muestras distintas y sus resultados no deben generalizarse.

La lección principal no está en una cifra concreta de tenants. Cuando numerosos clientes confían en una aplicación multiinquilino con permisos elevados, un problema con la credencial del proveedor puede crear exposición en varias organizaciones.

Por qué importan más los permisos que el nombre conocido del proveedor

Las herramientas de copia de seguridad necesitan a menudo un acceso amplio a buzones de correo, OneDrive, SharePoint y otras cargas de trabajo para proteger la información. En Microsoft Entra ID, una entidad de servicio o service principal representa esa integración en el tenant del cliente. Los permisos de aplicación pueden permitir el acceso sin una sesión interactiva de usuario.

Por ello, las recomendaciones tradicionales, como «restablezca las contraseñas» o «active MFA para los empleados», siguen siendo importantes, pero no son suficientes ante incidentes relacionados con identidades de aplicaciones. Una carga de trabajo puede autenticarse con su propia credencial, y el alcance real depende de los permisos que concedieron anteriormente los administradores.

Para los MSP, una revisión debe responder a estas preguntas:

• ¿Qué aplicaciones de terceros y aplicaciones internas existen en cada tenant?
• ¿Quién es responsable de cada integración y a qué recursos necesita acceder?
• ¿Qué permisos de aplicación y delegados se concedieron, y quién los aprobó?
• ¿Se revisan los roles privilegiados, secretos, certificados, propietarios y consentimientos?
• ¿Cómo detectará el MSP un inicio de sesión inusual de un service principal o un cambio de credenciales?
• ¿Qué sucede con la protección del cliente si hay que deshabilitar una conexión del proveedor?

El problema del riesgo en cadena para MSP y MSSP

Un MSP puede gestionar decenas o cientos de tenants independientes, pero su modelo operativo puede seguir dependiendo de unas pocas plataformas comunes, aplicaciones de proveedores o identidades de administración. Esto concentra riesgo operativo y de seguridad.

Si un atacante accede mediante una integración compartida, el alcance potencial puede ir más allá de un único cliente. Una organización también puede verse afectada por la suspensión preventiva de un servicio decidida por el proveedor, incluso cuando no existan evidencias de compromiso en su propio tenant.

Conviene distinguir entre aislamiento de tenants y dependencias de un plano de control compartido. Separar los entornos de clientes establece barreras valiosas, pero no elimina los riesgos de una identidad común del proveedor, una cuenta administrativa excesivamente privilegiada o un servicio central que deja de estar disponible.

Para los MSSP, este caso añade otra exigencia: la monitorización de seguridad debe incluir service principals, modificaciones de permisos e identidades de aplicaciones en la nube, y no limitarse a los endpoints o a los inicios de sesión de personas.

Lista práctica de respuesta para proveedores de servicios gestionados

Los MSP que utilicen servicios afectados de ConnectWise o integraciones antiguas de SkyKick deben seguir la guía técnica oficial y actualizada del proveedor, coordinarse con el administrador autorizado de cada cliente y con su equipo de respuesta ante incidentes y preservar las pruebas antes de realizar cambios amplios, siempre que ello no retrase una contención urgente. Esta lista editorial no sustituye las instrucciones específicas del incidente.

1. Inventaríe todos los tenants. Incluya el entorno Microsoft 365 del propio MSP, cada cliente gestionado y las integraciones antiguas inactivas. Identifique las aplicaciones por su Application ID, no solo por el nombre visible.
2. Confirme la contención. Verifique que las aplicaciones empresariales afectadas estén deshabilitadas según las instrucciones oficiales, registre su estado local y no las vuelva a habilitar hasta recibir instrucciones formales de reconexión de ConnectWise.
3. Conserve las pruebas. Exporte los registros disponibles de inicios de sesión y auditoría de Entra, los registros de Microsoft 365 y las alertas relevantes. Anote las horas de recogida y las lagunas de retención.
4. Investigue las identidades de aplicación. Revise los inicios de sesión de service principals, secretos, certificados, permisos nuevos, propietarios, roles privilegiados y cambios de consentimiento. Deshabilitar la aplicación original no elimina automáticamente accesos añadidos a otras identidades.
5. Compruebe la actividad posterior. Investigue reenvíos de correo, reglas de bandeja de entrada, delegaciones y actividad relevante en SharePoint, OneDrive y Teams, según los registros disponibles.
6. Calcule la brecha de protección. Determine la fecha de la última copia correcta y qué restauraciones están disponibles. Documente el impacto operativo y analice medidas alternativas autorizadas con el cliente.
7. Comunique los resultados por tenant. Distinga entre hechos confirmados, indicadores que requieren investigación y áreas con registros insuficientes. Asigne un responsable y realice seguimiento para cada cliente.

La guía oficial de ConnectWise identifica la aplicación Cloud Backup con el ID 506e08f9-6e9a-4da4-942b-a099a03644ae e incluye otros identificadores de Cloud Management y pasos de investigación. Un inicio de sesión sospechoso o una coincidencia con una IP publicada exige análisis, pero no demuestra por sí solo una filtración de datos ni el compromiso del tenant.

La disponibilidad de las copias también es una cuestión de continuidad

Durante las medidas de contención, ConnectWise suspendió servicios afectados, interrumpiendo tareas programadas, acceso a archivos de backup y restauraciones. El 21 de octubre, el proveedor anunció una recuperación gradual, sin afirmar que todas las funciones estuvieran ya disponibles.

Para los clientes de un MSP, esto plantea preguntas que van más allá de la ciberseguridad: ¿de qué fecha es el último punto de recuperación? ¿Qué RTO y RPO figuran en el contrato? ¿Existe otra vía de recuperación autorizada si el plano de control principal no está disponible? ¿Quién comunica estas limitaciones al cliente?

No es realista suponer que todas las empresas necesiten dos proveedores completos de copias de seguridad. Sin embargo, cada MSP debería documentar las dependencias críticas y evaluar redundancia, opciones de recuperación e impacto operativo según el riesgo del cliente y sus compromisos contractuales.

Siete medidas preventivas que merece la pena revisar ahora

• Mínimo privilegio: conceder solo los permisos necesarios y revisarlos cuando cambien las integraciones.
• Gobierno de aplicaciones: mantener un inventario de aplicaciones empresariales, service principals, responsables, credenciales y consentimientos.
• Segmentación de clientes: limitar los privilegios entre tenants y evitar accesos administrativos compartidos innecesarios.
• Monitorización y detección: recoger inicios de sesión de aplicaciones y alertas sobre ubicaciones, credenciales, permisos y cambios de roles anómalos.
• Registros preparados para incidentes: conocer los plazos de retención y conservar cuanto antes las pruebas críticas.
• Validación de recuperación: probar restauraciones y documentar qué opciones quedan disponibles si falla una plataforma de gestión en la nube.
• Gestión de riesgos de proveedores: revisar accesos de terceros, canales de comunicación de incidentes, procesos de restablecimiento y responsabilidades contractuales.

Estos controles no eliminan el riesgo de la cadena de suministro. Ayudan a identificarlo antes, reducir el alcance potencial y responder con pruebas en lugar de suposiciones.

Qué implica para el modelo de negocio de los MSP

El incidente recuerda que las copias de seguridad gestionadas no son solo almacenamiento. Los clientes dependen de su MSP para saber si las tareas finalizan correctamente, si el acceso está protegido, si la recuperación sigue siendo posible y cómo se gestionarán los incidentes.

Para MSP y MSSP, una oferta más sólida combina operación de copias de seguridad, gobierno de identidades, monitorización, procedimientos de recuperación probados, SLA claros y comunicación transparente. Un panel que muestre todo «en verde» no sustituye una capacidad de recuperación demostrable.

Desde la perspectiva de SafetyOnCloud, una estrategia de copias de seguridad debe valorarse por su capacidad para apoyar la recuperación, no únicamente por la existencia de datos almacenados. Cada proveedor debe comprobar su configuración, sus dependencias tecnológicas y las necesidades del cliente antes de prometer controles o tiempos determinados.

Conclusión: confíe en la integración, pero compruebe sus límites

El incidente de ConnectWise Cloud Backup no demuestra que todos los proveedores de backup ni todos los tenants de clientes se hayan visto comprometidos. Sí demuestra la importancia de prestar a las identidades de aplicación, los permisos de terceros y las dependencias compartidas la misma atención que a los endpoints, las contraseñas y las políticas de retención.

Para cualquier MSP, el siguiente paso útil es una revisión tenant por tenant: inventariar integraciones, comprobar permisos, conservar los registros adecuados, confirmar puntos de recuperación y ensayar la respuesta ante la indisponibilidad de un servicio del proveedor.

Para un MSP, la seguridad de las copias de seguridad no consiste solo en proteger los datos del cliente. También consiste en controlar quién puede acceder a ellos y demostrar cómo se pueden recuperar.