Blog

¿Quién tiene acceso a tu Microsoft 365? Lo que revela el incidente de ConnectWise/SkyKick

11 min read

Author: Stackfire Team

Oct 23, 2026

Una credencial comprometida de ConnectWise Cloud Backup (antes SkyKick) se usó para entrar a miles de tenants de Microsoft 365 sin contraseñas ni MFA. Qué pasó, quién debe revisar, qué está documentado y qué hacer hoy con las integraciones autorizadas en tu tenant.

Imagen del artículo ¿Quién tiene acceso a tu Microsoft 365? Lo que revela el incidente de ConnectWise/SkyKick

Actualizado el 23 de octubre de 2026. El incidente sigue en evolución y ConnectWise publica novedades en su página de estado; este artículo se irá ajustando conforme el proveedor y Microsoft liberen más información.

Resumen ejecutivo

Entre el 14 y el 17 de octubre de 2026, ConnectWise detectó y contuvo un acceso no autorizado a las identidades de aplicación de ConnectWise Cloud Backup (el producto que antes se conocía como SkyKick). Esas identidades son las que el servicio usaba para conectarse a los tenants de Microsoft 365 de sus clientes y hacer respaldos. Con una credencial de ese tipo, un atacante no necesita la contraseña ni el segundo factor de ningún usuario: entra con el acceso que la organización ya le había otorgado a la aplicación.

Según el análisis que Microsoft publicó el 21 de octubre, el actor que atribuye al incidente (Storm-0940, alineado con intereses estatales de China) intentó iniciar sesión en más de 2,250 tenants usando las aplicaciones comprometidas. En una parte de ellos avanzó más: consultó el directorio, agregó credenciales a otras aplicaciones, modificó identidades, grupos y roles privilegiados, y leyó secretos de Azure Key Vault. ConnectWise indica que no hay indicios de que los archivos de respaldo hayan sido accedidos, y que no observa actividad del atacante desde el 17 de octubre a las 05:00 UTC.

Esto no es una vulnerabilidad de Microsoft 365. Es un incidente en la cadena de suministro: una credencial de un proveedor de confianza se usó de forma indebida. La lección aplica a cualquier integración autorizada en tu tenant, no solo a ConnectWise. Si tu organización usa o usó SkyKick o ConnectWise Cloud Backup, Cloud Management o SaaS Security, toca revisar. Si no, igual vale la pena saber quién tiene acceso a tu Microsoft 365 hoy.

Qué pasó y cuándo

Conviene distinguir tres fechas distintas: cuándo ocurrió el incidente, cuándo se publicaron los análisis y cuál es la última actualización del proveedor. Esta es la línea de tiempo con las fuentes disponibles al cierre de este artículo:

  • 10 al 14 de octubre. Microsoft documenta una campaña de rocío de contraseñas (password spraying) desde una dirección IP que después se usó en la intrusión. En esa campaña no reporta inicios de sesión exitosos.
  • 14 de octubre. ConnectWise identifica el problema, según la comunicación recogida por The Hacker News.
  • 15 de octubre, 01:58 UTC. Huntress observa que los service principals de ConnectWise Cloud Management se asignan a sí mismos roles en decenas de tenants (en su mayoría Exchange Administrator). En algunos casos la aplicación de Teams se otorgó Global Administrator y agregó secretos de cliente a otras aplicaciones, con vigencia hasta 2028.
  • 16 de octubre. ConnectWise abre el incidente en su página de estado y señala que no hay indicios de que los datos de respaldo de sus partners hayan sido accedidos. Huntress publica su primer análisis.
  • 17 de octubre, 05:11 UTC. ConnectWise confirma acceso no autorizado a las identidades de aplicación de Cloud Backup y corta el acceso de la aplicación. A las 07:00 UTC reporta siete identidades deshabilitadas, certificados revocados y el servicio suspendido.
  • 19 de octubre. ConnectWise reporta el restablecimiento completo de todas las cuentas y credenciales del servicio, y que los archivos de respaldo están cifrados, aislados y preservados.
  • 21 de octubre. Microsoft publica su análisis y atribuye la actividad a Storm-0940. Ese mismo día ConnectWise inicia una restauración por fases, todavía sin todas las capacidades.
  • 23 de octubre, 01:11 UTC (última actualización verificada). ConnectWise informa que las pruebas y la validación de seguridad siguen en curso; estima que terminen el fin de semana y que el acceso a restauraciones de respaldo sea la primera capacidad en regresar, con la reinscripción de partners en fases posteriores. Cloud Backup, SaaS Security y Cloud Management siguen suspendidos.

Un detalle importante: los plazos de recuperación que publica ConnectWise son estimaciones, no confirmaciones. Al momento de escribir, el servicio no está restablecido y las instrucciones vigentes del proveedor y de Microsoft son mantener las conexiones deshabilitadas hasta recibir instrucciones formales de restauración.

Qué son las aplicaciones autorizadas y por qué conservan acceso sin iniciar sesión

Cuando un administrador conecta un servicio externo a Microsoft 365 (un respaldo, una herramienta de migración, un CRM, un sistema de firma, un asistente de IA), lo que hace en realidad es dar consentimiento a una aplicación empresarial en Microsoft Entra ID. Ese consentimiento crea un service principal en tu tenant con permisos concretos: leer correo, leer archivos de SharePoint, administrar usuarios, etcétera.

La aplicación se autentica con su propia credencial (un secreto o un certificado) que vive en la infraestructura del proveedor, no con la cuenta de ninguna persona. Por eso:

  • No pasa por MFA. La autenticación multifactor protege a las personas. Una aplicación con permisos de aplicación entra sin usuario, sin contraseña y sin segundo factor. MFA sigue siendo indispensable para tus cuentas; simplemente no cubre este camino.
  • El acceso persiste. Mientras el consentimiento exista y la credencial sea válida, la aplicación puede entrar en cualquier momento, aunque nadie la use. Una integración que dejaste de usar hace dos años sigue teniendo las llaves si nadie la retiró.
  • Los tokens ya emitidos siguen vivos un tiempo. Deshabilitar una aplicación evita nuevos inicios de sesión, pero un token emitido antes puede seguir siendo válido hasta que expire. ConnectWise lo advirtió expresamente.
  • Deshabilitar no deshace. Si la aplicación ya creó un secreto en otra aplicación, asignó un rol o cambió una regla de reenvío, esos cambios siguen ahí después de apagarla.

Este modelo es correcto y necesario: así funcionan todas las integraciones modernas. El riesgo no está en el modelo, sino en no saber qué aplicaciones tienen acceso, con qué permisos, y en que la seguridad de tu tenant depende de la seguridad de cada uno de esos proveedores.

Quién debería revisar

  • Clientes actuales de ConnectWise Cloud Backup, Cloud Management o SaaS Security, directamente o a través de un proveedor de servicios administrados (MSP).
  • Ex clientes de SkyKick. Si en algún momento usaste SkyKick Cloud Backup o SkyKick Cloud Manager (por ejemplo, para una migración a Microsoft 365 hace años) y nadie retiró el consentimiento, las aplicaciones pueden seguir instaladas en tu tenant. Microsoft pide revisar los tenants donde las aplicaciones están o estuvieron instaladas o autorizadas. En tenants antiguos pueden aparecer con el nombre «SkyKick Cloud Manager».
  • Organizaciones atendidas por un MSP que use herramientas de ConnectWise. Pregunta a tu proveedor qué conexiones existen con tu tenant y qué revisión hizo.
  • Cualquier organización con integraciones de terceros en Microsoft 365. Aunque no te alcance este incidente, el ejercicio de inventario y revisión es el mismo y es la forma de estar preparado para el siguiente.

Los identificadores de aplicación que Huntress y Microsoft señalan como involucrados son, entre otros: 506e08f9-6e9a-4da4-942b-a099a03644ae (ConnectWise Cloud Backup), 2399d300-6fca-4e6a-a686-399fefe75b83 (Cloud Management), 24205314-2b89-4e07-a2a4-579e898a5640 (aplicación de Microsoft Teams), 0de14c77-b9b0-4137-9360-34878a929827 (Microsoft Graph), b78f6a77-d4e5-46fb-87e5-d1648bd02519 (Exchange Online), 412dcf96-176d-4b3a-a1b0-4981ad66971e (Partner Center) y b2b55f5b-7758-4719-8d8f-88ae172e6bdb (SharePoint Online). Busca por identificador, no por nombre: el nombre para mostrar puede cambiar.

Qué riesgos hay para el correo, la información y la continuidad

Es importante separar lo que las fuentes documentan de lo que es posible pero no está confirmado.

Lo documentado:

  • Intentos de inicio de sesión con las aplicaciones comprometidas en más de 2,250 tenants (Microsoft). Huntress contabilizó alrededor de 1,000 tenants con actividad de inicio de sesión y más de 300 con inicios de sesión exitosos en su base de clientes.
  • En parte de esos tenants: consultas al directorio vía Microsoft Graph, altas de credenciales en aplicaciones, cambios en identidades, grupos y roles privilegiados, y lectura de secretos en Key Vault (Microsoft).
  • Asignación de roles como Exchange Administrator y Global Administrator por parte de los service principals comprometidos (Huntress).
  • ConnectWise no tiene indicios de que los archivos de respaldo hayan sido accedidos y no observa actividad del atacante desde el 17 de octubre.

Lo posible, pero no confirmado de forma general:

  • Lectura de correo o archivos. Las aplicaciones de respaldo tienen permisos amplios sobre buzones y SharePoint. Huntress no observó acceso a correo o archivos en los tenants que revisó, y ConnectWise no puede ver lo que pasa dentro del tenant de cada cliente. Que en tu tenant no haya pasado nada no se puede asumir: hay que revisarlo.
  • Persistencia. Un secreto agregado a otra aplicación, un rol asignado o una regla de reenvío de correo le daría al atacante una puerta que sobrevive al corte de la credencial original. Es la razón por la que no basta con deshabilitar la aplicación de ConnectWise.
  • Continuidad. Mientras el servicio de respaldo está suspendido, los respaldos nuevos no se están ejecutando y la restauración no está disponible. Si dependías de ese respaldo como único mecanismo de recuperación, hoy tienes una ventana sin cobertura.

Microsoft es explícito: la presencia de las aplicaciones en tu tenant, o incluso un inicio de sesión exitoso, no significa por sí sola que tus datos hayan sido accedidos. Las lecturas de directorio vía Graph no dejan rastro en el registro de auditoría, así que la ausencia de evidencia tampoco es una garantía. Eso es justo lo que hace necesaria una revisión ordenada.

Acciones recomendadas

Este es el orden que sugerimos, alineado con las recomendaciones de Microsoft, Huntress y ConnectWise vigentes al 23 de octubre:

  1. Inventario de aplicaciones. En Microsoft Entra ID, lista las aplicaciones empresariales y los registros de aplicación. Identifica las de ConnectWise y SkyKick por identificador. Después, el resto: para cada integración, anota quién la autorizó, para qué sirve, qué permisos tiene y si todavía se usa.
  2. Deshabilitar, no eliminar. Si tienes las aplicaciones involucradas, desactiva el inicio de sesión de usuarios en cada una. No las elimines todavía: borrar la aplicación destruye evidencia que vas a necesitar para la investigación. No las vuelvas a habilitar hasta que ConnectWise publique instrucciones formales de restauración.
  3. Revisión de permisos e identidades. Revisa credenciales (secretos y certificados) agregadas a cualquier aplicación desde el 13 de octubre; asignaciones de roles privilegiados; cambios en grupos y en cuentas de administrador; consentimientos nuevos; usuarios o aplicaciones que no reconozcas.
  4. Registros. Preserva los registros de inicio de sesión de Entra (incluidos los de service principals) y la auditoría de Microsoft Purview antes de que expiren por retención. Revisa actividad desde el 15 de octubre, y los inicios de sesión de service principals desde el 1 de octubre, con atención a las direcciones IP y agentes de usuario publicados por Microsoft.
  5. Cambios no autorizados. Busca reglas de reenvío o de bandeja de entrada nuevas, delegaciones de buzón, permisos de carpeta y políticas de acceso condicional modificadas. Lo que confirmes como no autorizado debe retirarse de forma controlada, por una persona con autoridad y dejando registro, no en caliente.
  6. Verificación de respaldos. Confirma qué respaldos tienes fuera del servicio suspendido, cuándo fue el último exitoso y cuándo fue la última prueba de restauración. Si el respaldo de ConnectWise era el único, define un plan temporal mientras el servicio regresa.
  7. Comunicación. Si trabajas con un MSP, pide por escrito qué conexiones tiene con tu tenant y qué revisó. Si eres el MSP, comunícalo a tus clientes antes de que te lo pregunten.

Una regla general que deja este incidente: revisar las integraciones de tu tenant debe ser una tarea periódica, no una reacción. Cada aplicación autorizada es un proveedor del que dependes y al que, en la práctica, le estás confiando tus llaves.

¿Cómo te ayudamos en StackFire?

En StackFire acompañamos a equipos de TI y a direcciones generales que necesitan saber dónde están parados y actuar con orden, sin alarmismo:

  • Evaluación de exposición. Determinamos si tu tenant tiene o tuvo las aplicaciones involucradas, con qué permisos, y qué otras integraciones de terceros tienen acceso hoy.
  • Revisión técnica. Analizamos registros de inicio de sesión y auditoría, credenciales agregadas, roles, consentimientos y reglas de correo, contra los indicadores publicados por Microsoft y Huntress, y te entregamos hallazgos con evidencia.
  • Contención coordinada. Si encontramos algo, lo retiramos contigo de forma controlada, preservando evidencia y sin romper lo que sí necesitas que siga funcionando.
  • Recuperación validada. Verificamos que tus respaldos existan, se puedan restaurar y cubran lo que crees que cubren, y te ayudamos a definir un plan de continuidad mientras el proveedor restablece su servicio.

Si quieres una revisión de tu Microsoft 365, escríbenos a través de la página de contacto de StackFire y platicamos sin compromiso.

Fuentes

Build something great.

Start deploying Contactar a ventas