ConnectWise desactiva siete identidades y suspende Cloud Backup

ConnectWise desactivó a las 07:00 UTC del 17 de octubre las siete identidades de aplicación que Cloud Backup y Cloud Management usan en Microsoft 365, revocó los certificados de esas conexiones y, según su aviso de las 01:24 UTC del 18 de octubre, ha dejado también fuera de línea SaaS Security y Cloud Management. Huntress amplía mientras tanto el alcance del ataque a casi 1.000 tenants de Entra con intentos de inicio de sesión desde la IP del atacante, más de 300 de ellos con éxito, y describe una segunda oleada contra 16 organizaciones de los sectores de política, seguridad nacional, comercio y minerales críticos.

Qué ha pasado

Esta noticia continúa la del 17 de octubre sobre la credencial robada de ConnectWise Cloud Backup, que ya recogía cómo un actor desconocido usó la credencial de la aplicación del antiguo SkyKick para obtener tokens de Microsoft Graph en tenants de clientes de MSP (proveedores de servicios gestionados). Lo nuevo está en las dos últimas actualizaciones de la página de estado de ConnectWise y en las que Huntress ha añadido a su informe durante el 17 de octubre.

A las 17:04 UTC del 17 de octubre, ConnectWise informó de que había suspendido Cloud Backup revocando los certificados de las conexiones afectadas en todos los usuarios, de que las credenciales compartidas del servicio ya no son válidas y de que ha contratado a una firma externa de respuesta a incidentes. El fabricante también reconoce que, por diseño, no tiene visibilidad de los entornos de Microsoft 365 de sus partners, así que no puede decirle a ningún cliente si su tenant sufrió actividad no autorizada. Desde que aplicó las mitigaciones, afirma, «we have not observed successful threat activity in the environments we monitor» (no hemos observado actividad de amenaza con éxito en los entornos que vigilamos).

La actualización de las 01:24 UTC del 18 de octubre precisa la hora y el alcance del corte. Las siete identidades de aplicación publicadas en el Trust Center quedaron desactivadas a las 07:00 UTC del 17 de octubre, dos horas después del aviso que anunciaba el apagado. ConnectWise advierte de que esa medida impide nuevas autenticaciones, pero «it does not reverse changes previously made inside a tenant» (no revierte los cambios hechos previamente dentro de un tenant), y de que los tokens ya emitidos pueden seguir siendo válidos hasta que caduquen. Como precaución añadida ha retirado del servicio SaaS Security y Cloud Management, de modo que la monitorización y las alertas del primero y la gestión de usuarios y licencias del segundo no están disponibles. No hay fecha de restauración.

El diagrama resume la cronología con las horas que dan ConnectWise y Huntress. Hay un dato que no estaba en la pieza anterior: según recoge The Hacker News del aviso del Trust Center, ConnectWise identificó el problema el 14 de octubre a través de su monitorización, un día antes de los primeros tokens de Graph que vio Huntress y en pleno password spraying desde la misma IP. El fabricante añade que todavía no sabe si una vulnerabilidad de producto contribuyó al compromiso de las identidades y que el mecanismo por el que se expuso la credencial sigue en análisis. La página del Trust Center está detrás de una comprobación de navegador y no hemos podido leerla directamente.

Detalles técnicos

La lista oficial de identidades desactivadas coincide con las siete que Huntress pedía revisar el 16 de octubre. En tenants antiguos aparecen con el nombre SkyKick Cloud Manager, y Guardz añade a la vigilancia el SkyKick Partner Portal, con ID c921256f-04a7-44e8-9b2a-69c33929ba19, que no figura en la lista de ConnectWise.

Huntress amplió su informe dos veces el 17 de octubre. A las 14:30 UTC dijo tener confianza alta en que el actor también abusó de las aplicaciones Cloud Management de Exchange Online, MS Teams y SharePoint Online, y que en ese momento no parecían desactivadas por ConnectWise. Esa observación choca con la hora oficial de las 07:00 UTC que el fabricante dio después, y ninguna de las dos partes ha aclarado la diferencia. En la misma actualización, Huntress menciona una posible afinidad por el orden alfabético en la selección de víctimas y pide a las organizaciones afectadas que se lo comuniquen.

A las 21:15 UTC llegó la actualización con más sustancia. Huntress identificó una segunda oleada desde 144.172.64.128, también el 15 de octubre, contra 16 tenants que protege y que pertenecen a los sectores de política, seguridad nacional, comercio y minerales críticos. La mayoría no usa productos de ConnectWise. El primer barrido buscó tokens de Graph de la aplicación de SkyKick entre las 09:25:04 y las 12:35:50 UTC. El segundo, entre las 13:54:39 y las 14:20:24 UTC, parecía manual y probó contra Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra y las API de gestión de Office 365. En los tenants que no tenían la entidad de servicio de ConnectWise, «the attempts failed because the application was not present» (los intentos fallaron porque la aplicación no estaba presente). Ese detalle fija el límite del ataque: sin consentimiento previo de la aplicación no hay token.

El recuento también cambia de escala. Huntress ha identificado casi 1.000 tenants de Entra con actividad de inicio de sesión desde esa IP y más de 300 inicios con éxito. Dice haber recibido avisos externos sobre actividad parecida en otros tenants, incluida lo que parece actividad manual, y aclara: «We have not independently verified these reports.» (no hemos verificado estos informes de forma independiente). Sobre la credencial que el actor añadió el 15 de octubre a la aplicación de la propia Huntress en el tenant de un cliente, la empresa indica que se usó para iniciar sesión siete veces seguidas, que la retiró el 16 de octubre y que ha activado App Instance Property Lock en todas sus aplicaciones para que un tenant cliente no pueda añadir credenciales a sus entidades de servicio.

Todyl aporta el detalle forense de los tokens. En los tenants que vigila, los inicios de sesión de la aplicación ocurrieron entre las 07:11 y las 08:47 UTC del 15 de octubre, en orden ascendente de GUID y con entre uno y seis minutos de separación. El tipo de credencial era clientAssertion con key_id y huella vacíos, el token era de evaluación continua de acceso (CAE) y todos los identificadores de sesión empiezan por 009ae85a-. En nueve tenants sin suscripción activa de copia, el actor obtuvo el token pero no hay registros de lectura de buzones ni de archivos después. En los que sí tenían copia activa, las lecturas existen pero no se pueden atribuir, porque el servicio legítimo y el atacante usan la misma identidad y los registros de auditoría muestran las IP de Microsoft y no la del actor. Hay una pequeña discrepancia de horas entre fuentes: la ventana de Huntress para la primera oleada termina a las 08:34 UTC, mientras que The Hacker News cita a Huntress con un último inicio de sesión malicioso a las 08:45 UTC.

Para buscar estos inicios de sesión en Microsoft Sentinel o en la caza avanzada de Defender, esta consulta KQL devuelve toda autenticación de las siete identidades desde el 13 de octubre que no proceda de los rangos de Microsoft y marca la IP del atacante:

let apps = dynamic(["506e08f9-6e9a-4da4-942b-a099a03644ae","2399d300-6fca-4e6a-a686-399fefe75b83",
  "24205314-2b89-4e07-a2a4-579e898a5640","b78f6a77-d4e5-46fb-87e5-d1648bd02519",
  "0de14c77-b9b0-4137-9360-34878a929827","412dcf96-176d-4b3a-a1b0-4981ad66971e",
  "b2b55f5b-7758-4719-8d8f-88ae172e6bdb"]);
AADServicePrincipalSignInLogs
| where TimeGenerated >= datetime(2026-10-13)
| where AppId in (apps)
| where not(ipv6_is_in_any_range(IPAddress, dynamic(["2603::/16","2a01:111::/32"])))
| extend IpAtacante = IPAddress == "144.172.64.128"
| project TimeGenerated, ServicePrincipalName, AppId, IPAddress, IpAtacante, ResultType, ResourceDisplayName
| order by TimeGenerated asc

Quien tenga BloodHound puede ir un paso más allá. SpecterOps publicó el 17 de octubre dos consultas Cypher que parten del tenant editor de ConnectWise (3f9cd7a0-127a-4ed4-bf06-2f830d5616b7) para dibujar todo lo que sus entidades de servicio controlan en el tenant y los caminos hacia los activos de nivel cero. La primera es esta:

MATCH p=(sp:AZServicePrincipal)-[r]->(target)
WHERE toLower(sp.appownerorganizationid) = '3f9cd7a0-127a-4ed4-bf06-2f830d5616b7'
RETURN p

Si el grafo muestra una arista de una aplicación de ConnectWise hacia un rol de directorio o hacia otra aplicación, es el mismo patrón de escalada que Huntress documentó con la aplicación de Teams. La idea de fondo, que tratamos al hablar de identidad y control de accesos en la nube, es que cada entidad de servicio es un principal con sus propios derechos y hay que auditarla como a un administrador.

A quién afecta

A cualquier tenant de Microsoft 365 donde alguna de las siete aplicaciones esté consentida, incluidos los que conservan conexiones de SkyKick sin uso desde antes de la compra por ConnectWise en septiembre de 2024. ConnectWise pide revisar tanto el tenant propio del MSP como cada tenant de cliente gestionado. La segunda oleada de Huntress demuestra que la IP también sondeó organizaciones sin ningún producto de ConnectWise, aunque en ellas no consiguió nada.

El gráfico pone en escala las cifras de Huntress: las dos primeras barras corresponden a lo que la empresa describe como casi 1.000 tenants con intentos y más de 300 inicios de sesión con éxito, la tercera son los 162 tenants con acceso confirmado a las 19:00 UTC del 16 de octubre y la última, los 16 tenants de la segunda oleada. Son datos de la flota que Huntress protege, no del total de clientes de ConnectWise, de modo que la cifra real solo puede ser mayor. En el momento de escribir esta noticia no hay desglose por países y ni INCIBE-CERT ni CCN-CERT han publicado aviso propio. En España el impacto recae en el canal MSP que gestiona Microsoft 365 para pymes y administraciones con estas herramientas, y en sus clientes, que llevan desde el 17 de octubre sin copias nuevas ni posibilidad de restaurar. Esa pérdida de continuidad es la que medimos cuando hablamos de resiliencia digital y conviene documentarla desde ya.

Qué hacer

1. Mantén desactivadas las siete entidades de servicio en todos los tenants que gestiones, incluidas las que aparezcan como SkyKick Cloud Manager o SkyKick Partner Portal, y no las reactives hasta recibir las instrucciones de reconexión o reautorización que ConnectWise promete publicar en el Trust Center. Si las desactivaste ayer con el bucle de PowerShell de nuestra noticia anterior, comprueba que las siete figuran con Account Enabled en false.
2. Exporta hoy los registros de inicio de sesión de entidades de servicio y la auditoría de Entra, junto con el registro unificado de Purview, antes de que la retención los borre. Todyl recomienda cazar desde el 1 de octubre o hasta donde llegue la retención, y ConnectWise, desde el 13 de octubre.
3. Pasa la lista de comprobación que ConnectWise ha añadido en su última actualización: autenticaciones de aplicaciones y usuarios, credenciales de aplicación y relaciones de federación, roles de directorio, propietarios, concesiones de consentimiento y cambios recientes de políticas. Revisa en Exchange Online el reenvío de buzones, las reglas de bandeja de entrada y de transporte y los accesos delegados a buzones.
4. Cuenta con la ventana de tokens. Blumira y Todyl sitúan la vida de un token de solo aplicación entre 60 y 90 minutos, y el token que vio Todyl era CAE, de modo que trata cualquier actividad de la aplicación en los 90 minutos posteriores a su desactivación como exposición activa.
5. Activa los registros de actividad de Microsoft Graph si tienes Entra ID P1 o P2. No son retroactivos, pero a partir de ahora dirán qué leyó cada token. Todyl recuerda que el acceso condicional no se aplica a aplicaciones multitenant de terceros, así que la visibilidad es el control que te queda.
6. Si publicas aplicaciones multitenant propias, activa App Instance Property Lock como ha hecho Huntress, para que un tenant comprometido no pueda plantar credenciales en tu entidad de servicio. Limita quién tiene los roles Application Administrator y Cloud Application Administrator y usa políticas de gestión de aplicaciones que bloqueen los secretos de cliente, en línea con un enfoque Zero Trust aplicado a identidades de carga de trabajo.
7. Para los cambios que normalmente harías desde SaaS Security o Cloud Management, contacta con Partner Care. Reporta cualquier actividad sospechosa a SecurityPartnerSupport@ConnectWise.com y, en España, a INCIBE-CERT si eres empresa y al CCN-CERT si eres administración pública. Si hay datos personales afectados, prepara la notificación a la AEPD en 72 horas.

El gráfico recoge los plazos de retención que cita Blumira y explica la urgencia del segundo paso: con Entra ID Free, los registros del 13 de octubre desaparecen el 20. Una estrategia de SIEM que ingiera los registros de entidades de servicio evita depender de esos plazos.

Para el tercer paso, este script de PowerShell lista en todos los buzones de Exchange Online las reglas de bandeja de entrada que reenvían o redirigen correo fuera, que es la persistencia más habitual tras un acceso a Graph con permisos de correo:

Connect-ExchangeOnline
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-InboxRule -Mailbox $_.PrimarySmtpAddress |
    Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage } |
    Select-Object MailboxOwnerId, Name, Enabled, ForwardTo, RedirectTo, DeleteMessage, WhenChanged
} | Export-Csv reglas-sospechosas.csv -NoTypeInformation

Cualquier regla creada a partir del 13 de octubre que no reconozca el usuario debe eliminarse y anotarse en la investigación.

Análisis

Para quien gestiona tenants de terceros, la actualización de ConnectWise confirma lo que la pieza anterior apuntaba: apagar la aplicación en el lado del fabricante no cierra el incidente en el lado del cliente. El propio aviso lo dice al admitir que la desactivación no revierte cambios previos y que los tokens emitidos siguen vivos. Lo que el aviso sigue sin contar es cómo salió la credencial, si hubo una vulnerabilidad de producto por medio y cuándo volverán las copias. Mientras tanto, los clientes acumulan días sin punto de recuperación y sin la monitorización de SaaS Security, y esa combinación es la que más nos preocupa, porque deja ciego justo al servicio que debería avisar de un uso anómalo.

La segunda oleada contra tenants de política, seguridad nacional y minerales críticos es, para nosotros, el dato más llamativo del día. Huntress solo dice que la mayoría no usa ConnectWise y que los intentos fracasaron, y no atribuye la campaña a nadie, así que nosotros tampoco. Lo que sí se puede leer es que el operador tenía una lista de objetivos que no salía del catálogo de clientes del MSP y que probó la misma llave contra ella por si alguno la tenía consentida. Esa es la economía de un ataque a una aplicación multitenant: una credencial, miles de puertas, y solo hace falta que algunas estén abiertas.

El contexto de la semana refuerza el patrón que ya señalamos. El backdoor servido por las actualizaciones de AOMEI Backupper llegó también a través de un software de copia de seguridad, el producto que por definición tiene acceso a todo. Cabe esperar que ConnectWise publique instrucciones de reconsentimiento con credenciales nuevas, que Huntress y Microsoft eleven las cifras a medida que revisen más registros y que aparezcan más aplicaciones con secretos plantados en tenants concretos. Entender por qué una identidad de aplicación merece el mismo trato que una cuenta privilegiada es el punto de partida de cualquier gestión de identidad y acceso en la nube que quiera sobrevivir a este tipo de incidente.

Preguntas frecuentes

¿Cuándo volverá a funcionar ConnectWise Cloud Backup?

ConnectWise no ha dado fecha. En su actualización del 18 de octubre dice que sigue en la fase de investigación, validando hallazgos y vías de mitigación, y que avisará cuando la supere con instrucciones de reconexión o reautorización. Como ha revocado los certificados y anulado las credenciales compartidas, lo previsible es que la vuelta exija volver a consentir la aplicación con credenciales nuevas en cada tenant. Hasta entonces no hay copias nuevas ni restauraciones.

Ya desactivé la aplicación ayer. ¿Tengo que hacer algo más?

Sí. Comprueba que están desactivadas las siete identidades de la lista oficial y no únicamente la de Cloud Backup, porque Huntress confirmó el abuso de las de Exchange Online, Teams y SharePoint Online. Después aplica la lista de comprobación nueva de ConnectWise, que incluye relaciones de federación, propietarios de aplicaciones y reglas de reenvío de correo, y exporta los registros antes de que caduquen. Si eres un MSP con aplicaciones multitenant propias, revisa también sus credenciales.

¿Me afecta si no uso ningún producto de ConnectWise?

Lo más probable es que no, pero conviene mirar. Huntress vio intentos desde 144.172.64.128 contra 16 tenants que en su mayoría no usan ConnectWise, y todos fallaron porque la aplicación no estaba consentida. Busca esa IP en los inicios de sesión de entidades de servicio de tu tenant desde el 13 de octubre. Si aparece con resultado correcto, tienes alguna aplicación de SkyKick o ConnectWise consentida que no conocías, quizá heredada de un proveedor anterior.