ConnectWise Cloud Backup (SkyKick): una credencial comprometida accedió a más de 300 inquilinos de Microsoft 365

El 15 de octubre de 2026, entre las 06:13 y las 08:34 UTC, alguien que usaba la identidad de ConnectWise Cloud Backup (la antigua SkyKick Backup) pidió tokens de Microsoft Graph para un cliente tras otro desde 144.172.64[.]128, una dirección de un proveedor de alojamiento. Según Huntress, las peticiones saltaban de un inquilino al siguiente con segundos de diferencia y en orden de identificador, el ritmo de un script que recorre una lista de objetivos.

Ningún usuario escribió una contraseña ni aprobó una notificación de MFA. La credencial de la aplicación era suficiente, porque en cada uno de esos inquilinos (tenants, en la terminología de Microsoft) tenía consentimiento para leer buzones, OneDrive, SharePoint, Teams y el directorio.

Las cifras han crecido con cada actualización de Huntress. A las 19:00 UTC del 16 de octubre había confirmado inicios de sesión no autorizados en 162 inquilinos. En su actualización de la tarde del 17 contaba casi mil inquilinos con actividad de inicio de sesión desde esa IP, y más de 300 con acceso conseguido.

ConnectWise suspendió Cloud Backup el 17 de octubre revocando certificados y desactivando siete identidades de aplicación, y el 18 desconectó también SaaS Security y Cloud Management. Según su página de estado, los archivos de copia se conservan, aunque mientras dure el corte no se pueden consultar ni restaurar, y todavía no hay fecha de vuelta.

¿Qué se sabe del ataque a ConnectWise Cloud Backup (antes SkyKick)?

ConnectWise confirmó a iTnews el 18 de octubre de 2026 que había detectado acceso no autorizado a identidades de aplicación de su entorno de Cloud Backup y que había anulado la credencial. También reconoció que no tiene visibilidad dentro de los inquilinos de sus clientes, así que no puede saber si un entorno determinado fue consultado. No ha explicado cómo se obtuvo la credencial.

El servicio, vendido sobre todo a través de proveedores de servicios gestionados (MSP), se instala en el inquilino del cliente como aplicación multiinquilino con permisos de aplicación. Actúa sin usuario detrás y alcanza todos los buzones, sitios y equipos del entorno. Huntress identificó la credencial como una aserción de cliente, lo que significa que reside en el inquilino del fabricante y no en el de cada cliente.

Microsoft calificó lo ocurrido de ataque activo a la cadena de suministro en un mensaje en X que recoge The Hacker News. Su equipo de inteligencia de amenazas, citado por BleepingComputer, cree que el atacante abusó de permisos ya concedidos, como Directory.ReadWrite.All, para reconocer el directorio por Graph e intentar añadir credenciales. A 19 de octubre ningún grupo ha sido señalado públicamente.

¿Qué otras actividades vincula Huntress a la misma IP?

Huntress relaciona con la misma IP o con las mismas aplicaciones de ConnectWise otras actividades del 13 al 15 de octubre de 2026, aunque advierte de que no ha podido atribuirlas a un único operador.

¿Cuándo empezó la difusión de contraseñas contra despachos de abogados?

Los días 13 y 14 de octubre, desde 144.172.64[.]128 se probaron unas pocas contraseñas contra muchas cuentas de cuatro despachos de abogados, una técnica conocida como difusión de contraseñas (password spraying), con la herramienta curl/7.88.1. El bloqueo inteligente de Entra ID cerró dos cuentas y Huntress no registró accesos de usuario con éxito desde esa IP.

¿Cuántos inquilinos alcanzó la aplicación de copias?

La aplicación de copias apareció el 15 de octubre de 2026. En su primera revisión, Huntress la encontró autenticándose desde la IP del proveedor de alojamiento en 17 de los cerca de 290 inquilinos revisados, cada uno de un socio distinto. Las actualizaciones posteriores elevaron el recuento hasta los más de 300 inquilinos ya citados.

En el inquilino que examinó a fondo, el registro de auditoría no muestra lectura de correo ni de ficheros. Huntress advierte de que las lecturas del directorio a través de Graph no aparecen en ese registro, de modo que consta la emisión de tokens pero no su uso.

Ese mismo día hubo una segunda ola, con tokens de la misma aplicación, contra 16 inquilinos de organizaciones dedicadas a política, seguridad nacional, comercio y minerales críticos. No tuvo éxito, porque la mayoría no usaba productos de ConnectWise y en sus entornos no existía la entidad de servicio (service principal) que el atacante necesitaba.

¿Cómo se convirtió una aplicación de gestión en Administrador global?

Según Huntress, en un inquilino la aplicación Cloud Management - MS Teams, también de ConnectWise, se añadió a sí misma al rol de Administrador global a las 03:44 UTC del 15 de octubre. Después, un script con agente de usuario Python-urllib/3.12 intentó nueve cambios sobre otras dos aplicaciones del mismo entorno, una herramienta de gestión del MSP y la plataforma de Huntress. Seis salieron adelante, entre ellos secretos de cliente nuevos con caducidad en 2028, unas dos horas y media antes de los primeros accesos de la aplicación de copias.

Estos cambios no salieron de 144.172.64[.]128 sino de direcciones IPv6 privadas de Azure, de modo que un filtro por esa IP no los encuentra. La credencial añadida a la aplicación de Huntress se usó en siete inicios de sesión antes de que la empresa la retirara el 16 de octubre y activara el bloqueo de propiedades de instancia de aplicación (App Instance Property Lock).

El 17 de octubre Huntress añadió que, con confianza alta, el atacante también abusó de las aplicaciones de Cloud Management para Exchange Online, Teams y SharePoint Online. Desde las 01:58 UTC del 15 había visto además a entidades de servicio de Cloud Management asignarse roles de directorio en unos 50 inquilinos, sobre todo Administrador de Exchange, con el agente kiota-dotnet. Huntress cree que puede tratarse de automatización del fabricante, sin confirmación de ConnectWise.

Un secreto añadido a otra aplicación sobrevive a la rotación de la credencial original. Si esa aplicación es una herramienta del MSP o un producto de seguridad, conserva permisos que pueden alcanzar a varios clientes, y la persistencia se consigue con funciones normales de Entra ID, sin malware.

¿Por qué el MFA y el acceso condicional no frenaron los accesos?

Nicholas Koken, responsable de ingeniería de detección en Todyl, explicó a The Hacker News el 17 de octubre de 2026 que revocar las sesiones de los usuarios no corta este acceso. La aplicación se autentica con un secreto o un certificado mediante el flujo de credenciales de cliente de OAuth, y sin usuario de por medio no hay segundo factor que exigir.

El acceso condicional tiene directivas para identidades de carga de trabajo, pero la documentación de Microsoft las limita a las entidades de servicio de un solo inquilino registradas en el inquilino que las aplica. Las aplicaciones SaaS de terceros, incluidas las multiinquilino, quedan fuera. Las directivas exigen además la licencia Workload Identities Premium y solo permiten bloquear. Para Cloud Backup, registrada en el inquilino de ConnectWise, ese control no existe.

La detección sí llega a las aplicaciones multiinquilino. Microsoft Entra ID Protection evalúa el riesgo de entidades de servicio de un solo inquilino, de SaaS de terceros y multiinquilino. Entre sus detecciones figuran los inicios de sesión sospechosos (cambios de IP, de ASN, de agente de usuario o de tipo de credencial) y las credenciales filtradas. Sin la licencia Premium también se generan, con menos detalle. Se calculan sin conexión y la de inicios sospechosos necesita entre 2 y 60 días de aprendizaje, así que no funcionan como alarma inmediata.

Desactivar la aplicación impide que se emitan tokens nuevos, pero los ya emitidos pueden seguir siendo válidos hasta 90 minutos, como advierten SpecterOps y ConnectWise en su comunicado.

¿Dónde queda el rastro en Entra ID y Microsoft Sentinel?

Huntress recomienda empezar por la pestaña de inicios de sesión de entidades de servicio de Entra ID, distinta de la de usuarios que se abre por defecto. La ventana que propone va de las 01:00 UTC del 15 de octubre de 2026 a las 02:00 UTC del 16. El filtro de partida es el identificador de Cloud Backup, 506e08f9-6e9a-4da4-942b-a099a03644ae, junto con la dirección del atacante.

Si esos registros llegan a Microsoft Sentinel u otro SIEM, estas consultas KQL sirven de punto de partida.

• Inicios de sesión de las siete aplicaciones de ConnectWise, filtradas por su inquilino propietario, o desde la IP del atacante: AADServicePrincipalSignInLogs | where TimeGenerated > datetime(2026-10-13) | where AppOwnerTenantId == "3f9cd7a0-127a-4ed4-bf06-2f830d5616b7" or IPAddress == "144.172.64.128" | summarize Inicios = count(), Recursos = make_set(ResourceDisplayName) by AppId, ServicePrincipalName, IPAddress, ResultType
• Altas en roles, cambios en aplicaciones y credenciales añadidas cuando quien las inicia es una aplicación: AuditLogs | where TimeGenerated > datetime(2026-10-13) | where OperationName has_any ("Add member to role", "Add service principal", "Certificates and secrets management", "Update application") | where isnotempty(tostring(InitiatedBy.app.servicePrincipalId)) | project TimeGenerated, OperationName, AppIniciadora = tostring(InitiatedBy.app.displayName), TargetResources

Huntress insiste en leer juntos actor, operación y agente de usuario, porque cada campo por separado es una señal débil. La segunda consulta filtra por servicePrincipalId porque en los eventos que inicia una aplicación el campo appId a menudo viene vacío.

Los registros de actividad de Microsoft Graph, que muestran las lecturas del directorio que la auditoría no recoge, no vienen activados de serie. Se activan con una configuración de diagnóstico, requieren Entra ID P1 o P2 y llegan a la tabla MicrosoftGraphActivityLogs. Activados hoy no servirán para reconstruir el 15 de octubre, pero sí para el siguiente incidente, y es buen momento para decidir qué registros enviar al SIEM y cuánto retenerlos.

SpecterOps ha publicado además consultas para BloodHound que, sobre los datos recogidos con AzureHound, muestran qué controla cada entidad de servicio del fabricante y qué caminos llevan desde ellas a los activos de nivel 0 del inquilino. Con ese resultado se puede explicar a un comité de riesgos hasta dónde llegaría quien tomara el control de la aplicación.

Los indicadores de compromiso publicados son la IP 144.172.64[.]128 (AS14956, RouterHosting), los siete identificadores de aplicación de ConnectWise que lista Huntress y los agentes de usuario Python-urllib/3.12, python-requests/2.31, python-requests/2.34.2 y curl/7.88.1. Los agentes de usuario, por sí solos, son una señal débil.

¿Cómo se contiene la aplicación de ConnectWise en un inquilino de Microsoft 365?

Huntress recomienda desde el 16 de octubre de 2026 desactivar la aplicación aunque los registros parezcan limpios, porque un registro limpio no descarta el acceso.

• La aplicación se desactiva sin borrarla, en Aplicaciones empresariales, poniendo "¿Habilitado para que los usuarios inicien sesión?" en No. Borrarla elimina el consentimiento, que habría que conceder otra vez para recuperar el servicio. Las aplicaciones de Cloud Management que no se puedan verificar reciben el mismo trato hasta que ConnectWise confirme que ha renovado todas las credenciales.
• Los roles de directorio que tenga una aplicación de ConnectWise o SkyKick sin una concesión expresa se retiran, empezando por Administrador global y Administrador de autenticación con privilegios.
• Los secretos y certificados de las aplicaciones registradas y empresariales se revisan con prioridad para las herramientas de gestión y de seguridad. Los añadidos desde el 13 de octubre que nadie reconozca se eliminan, porque siguen activos aunque la aplicación de ConnectWise esté desactivada.
• Las directivas de acceso condicional para usuarios se revisan por si excluyen estas aplicaciones como recurso de destino, por ejemplo de un bloqueo por ubicación.
• Las copias están detenidas desde que ConnectWise cortó el servicio y, mientras dure el corte, tampoco se pueden restaurar. La empresa ha asegurado a iTnews que los archivos existentes no están afectados. Aun así, la retención debe confirmarse con el proveedor, igual que la protección de los datos nuevos durante el corte.

Si aparece una asignación de rol o un secreto que nadie del equipo reconoce, el caso pasa a ser de respuesta a incidentes. Habrá que revisar el resto de aplicaciones del inquilino y, si interviene un MSP, los demás clientes a los que alcancen sus herramientas.

¿Qué medidas de gobierno reducen el riesgo de las aplicaciones de terceros?

El robo de datos de Salesforce a través de aplicaciones conectadas ya mostró que una integración con permisos de aplicación es una identidad no humana con privilegios altos cuya credencial custodia otra empresa. Tratarla como una cuenta de administración afecta a varias decisiones.

• El inventario de consentimientos debe separar permisos delegados y permisos de aplicación, y recoger quién concedió cada uno, para qué y si sigue en uso. SpecterOps recomienda retirar los consentimientos de SkyKick o Cloud Backup que no estén en uso, y la segunda ola lo ilustra, porque donde la aplicación no estaba no hubo por dónde entrar.
• El mínimo privilegio se aplica también a lo que pide el proveedor. Una herramienta de gestión quizá no necesite asignar roles, y un permiso como Directory.ReadWrite.All sin justificación operativa se negocia antes de conceder el consentimiento.
• Las directivas de administración de aplicaciones pueden restringir o prohibir los secretos de cliente y limitar su vigencia, y los roles de Administrador de aplicaciones y Administrador de aplicaciones en la nube deberían estar en muy pocas manos. Huntress cita ambos controles frente a secretos de larga duración. Una revisión de seguridad de Microsoft 365 debería incluir expresamente las entidades de servicio de terceros.
• La gestión del riesgo de terceros debe preguntar cómo protege el fabricante las credenciales de sus aplicaciones multiinquilino, si activa el bloqueo de propiedades de instancia, con qué rapidez puede revocarlas y por qué canal avisará. Para las entidades sujetas a NIS2, el artículo 21.2.d obliga a gestionar la seguridad de la cadena de suministro, incluida la relación con los proveedores directos, y un servicio de copias con acceso a todo el correo entra en esa obligación.
• Un proveedor que custodia las copias y a la vez tiene permisos amplios en el entorno productivo concentra dos riesgos en un mismo punto. Por esa razón recomendamos copias fuera del alcance del proveedor de nube tras el ataque a IDCF Cloud. Las aplicaciones de este tipo encajan como activos de nivel 0 en un modelo de niveles de acceso privilegiado, con nombre y responsable en el programa de seguridad de identidades no humanas.

¿Hasta dónde llega el control del cliente sobre una aplicación multiinquilino?

Un servicio de copias de Microsoft 365 necesita leer todo el correo y todos los ficheros, y el cliente no puede recortar ese permiso sin romper el servicio. Todo fabricante con una aplicación multiinquilino custodia una credencial que funciona en todos sus clientes. La reacción de ConnectWise (anular credenciales, cortar el servicio e informar a sus socios) es la que cabe esperar de un proveedor.

Cada organización sí decide si sabe que esa aplicación existe en su inquilino, si ve cuándo se conecta desde un lugar extraño y si puede cortarla en minutos. En muchas organizaciones con años de integraciones a cuestas, las entidades de servicio de terceros no tienen responsable interno ni alertas, y sus registros no llegan al SOC.

Hasta que ConnectWise explique cómo salió la credencial, no hay forma de saber si la que la sustituya está mejor protegida. Mientras tanto, la aplicación debería seguir desactivada y cada secreto añadido desde el 13 de octubre, considerarse sospechoso hasta que alguien lo justifique.

Fuentes y atribución: este análisis se basa en las divulgaciones públicas de ConnectWise, Huntress, SpecterOps y Microsoft, y en la cobertura de The Hacker News, iTnews y BleepingComputer, con la información disponible a 19 de octubre de 2026. La investigación sigue abierta y las cifras han cambiado más de una vez. Ninguna mención implica un fallo de seguridad en Microsoft 365 o Entra ID, porque el vector descrito es el abuso de la credencial de una aplicación legítima. Una atribución futura a un grupo podría cambiar la lectura del caso.

Las consultas KQL y los pasos de contención son orientativos. Las tablas, los identificadores y las ventanas temporales deben adaptarse a cada entorno y probarse antes de usarlos en producción. Desactivar una aplicación de terceros interrumpe su servicio, así que la medida debe coordinarse con el proveedor y con el responsable interno.