Compromiso de ConnectWise SkyKick: más de 100 tenants de M365

El 16-17 de octubre de 2026, Huntress emitió una alerta de respuesta rápida y ConnectWise divulgó un incidente generalizado: un atacante abusó del acceso obtenido a través de ConnectWise Cloud Backup para Microsoft 365 —antes SkyKick— para pivotar a los tenants de Microsoft 365 de los clientes. Huntress ha confirmado más de 100 tenants comprometidos. Lo propagamos con todo el crédito a los investigadores; los hechos e indicadores de abajo son suyos, y la fuente de referencia es el aviso de ConnectWise.

El detalle que más importa: esto es un inicio de sesión de aplicación con una credencial de proveedor, no un inicio de sesión de usuario. Nunca pide el MFA de un usuario y no aparece en el registro de inicios de sesión que la mayoría de los equipos vigila. Esa es toda la historia de por qué una app de copias de seguridad se convirtió en una llave maestra. La misma revisión se aplica a cualquier app que dejes entrar en Microsoft 365; nuestra revisión de seguridad de apps de terceros de Teams enumera las cuatro comprobaciones antes de conceder acceso.

SkyKick y ConnectWise Cloud Backup: una app, dos nombres

SkyKick y ConnectWise Cloud Backup son el mismo producto en este incidente: el servicio afectado es ConnectWise Cloud Backup para Microsoft 365, antes SkyKick Cloud Backup. Por eso aparecen ambos nombres en las búsquedas y en los tenants.

• Qué verás en Entra: la aplicación empresarial puede aparecer como «SkyKick Backup» o «ConnectWise Cloud Backup», según cuándo se consintió. Busca ambos nombres, o ve directo al App ID 506e08f9-6e9a-4da4-942b-a099a03644ae, que es el mismo en cualquier caso.
• Por qué importa el nombre: un administrador que busca solo «ConnectWise» puede pasar por alto una app que todavía lleva el nombre SkyKick, y al revés. Desactiva y busca por el App ID, no por el nombre visible.
• Qué significa la presencia de la app: según ConnectWise, tener la app instalada confirma que eres cliente, no que te hayan comprometido. La evidencia está en los inicios de sesión del service principal de ese App ID, sobre todo desde 144.172.64[.]128 o cualquier IP que no sea de Microsoft/Azure.

Sea cual sea el nombre que muestre tu tenant, los pasos de arriba se aplican sin cambios: desactiva el inicio de sesión de usuario de la app (no la borres) y luego busca en el registro del service principal y en el registro de auditoría unificado.

Haz esto ahora (guía de Huntress)

• ☐ Desactiva la app, no la borres. Centro de administración de Entra → Aplicaciones empresariales → busca «SkyKick Backup» / «ConnectWise Cloud Backup» (o busca el App ID) → Administrar → Propiedades → pon «Habilitada para que los usuarios inicien sesión» = No. Dejar la app en su sitio (desactivada) te permite reactivarla después sin volver a consentir.
• ☐ Busca en el registro correcto. Entra → Supervisión → Registros de inicio de sesión → la pestaña de inicios de sesión de service principal (la pestaña Usuario por defecto no lo mostrará), filtra por el App ID y marca cualquier IP de origen fuera de los rangos de Microsoft/Azure, sobre todo 144.172.64[.]128.
• ☐ Amplía la búsqueda. Consulta el registro de auditoría unificado de Microsoft 365 por el App ID, la IP y los user agents de Python; busca accesos a buzón, Teams y SharePoint y cualquier nuevo registro de app, secreto o concesión de consentimiento que el actor haya podido añadir.
• ☐ Asume password spray. La misma IP se vio haciendo spray; revisa los inicios de sesión interactivos fallidos y exitosos desde ella y restablece las credenciales expuestas.
• ☐ Ten en cuenta el compromiso. Desactivar la app detiene tus copias de seguridad; planifícalo. Y, según ConnectWise, la mera presencia de la app confirma que eres cliente, no que te hayan comprometido, así que busca antes de concluir.

La tendencia: las apps OAuth de proveedores son la vía silenciosa hacia Microsoft 365

Si quitas las marcas, esto es un caso de un patrón que lleva dos años creciendo: los atacantes entran cada vez más en Microsoft 365 no por la contraseña y el MFA de un usuario, sino por una aplicación de terceros consentida y su identidad de service principal (no humana). Una app empresarial consentida tiene permisos permanentes y a menudo amplios —aquí, según se informa, correo, Teams y SharePoint (según ThreatLocker)— y se autentica como ella misma, con su propio secreto, así que:

• no hay MFA interactivo que vencer;
• la actividad aterriza en el registro de inicio de sesión del service principal que la mayoría de los equipos nunca revisa;
• y la concesión de permisos sobrevive al restablecimiento de la contraseña de un usuario, porque no es la credencial del usuario.

Cuando la aplicación comprometida es una herramienta de MSP instalada en cientos de tenants de clientes, el radio de impacto se multiplica: un compromiso aguas arriba se convierte en un evento de cadena de suministro entre tenants, que es justo la forma de «más de 100 tenants» que describe Huntress. Es la misma clase de riesgo que las campañas de consent-phishing y de abuso de tokens OAuth; la diferencia aquí es que la app era un proveedor de confianza, preinstalado, así que no hubo que engañar a ningún usuario para que consintiera.

Qué debería sacar un líder de seguridad

• ☐ Inventaría tus apps empresariales de terceros y sus permisos. Cada app consentida en Entra es una identidad de carga de trabajo no humana permanente con una llave a parte de tus datos. Sabe cuáles pueden leer correo, archivos y Teams, y quién es responsable de cada una.
• ☐ Vigila los inicios de sesión de service principal, no solo los de usuario. Crea detecciones sobre inicios de sesión de apps desde IP/geografías inesperadas y sobre volúmenes anómalos; la señal en este incidente estaba en una pestaña que la mayoría de los SOC no monitorea.
• ☐ Trata las credenciales de proveedores como identidades privilegiadas. Acota los permisos de las apps al mínimo privilegio, prefiere credenciales de vida corta y ten una vía ensayada para eliminar una app de proveedor maliciosa en todos los tenants que gestionas.
• ☐ Ten lista la respuesta a brechas de terceros. Cuando un proveedor es el punto de entrada, la rapidez en la notificación, en las palancas contractuales y en la evaluación del radio de impacto es el trabajo. Ensáyalo en el Vendor-Breach Board Response Lab → y trabaja desde el playbook de brechas de terceros →.
• ☐ Puntúa las identidades. Una app consentida es una identidad como cualquier otra; califica tus identidades humanas, de servicio y de app con la calculadora de riesgo de identidad → y entrena las decisiones de consentimiento de apps y de acceso condicional en el OAuth Consent Phishing Lab →.

Créditos y fuentes

Este aviso se propaga del trabajo de otros, para que llegue a más defensores más rápido. Fuente principal y guía vigente: los avisos de ConnectWise Trust. Descubrimiento, indicadores y pasos de respuesta: el hilo de respuesta rápida de Huntress (@HuntressLabs). Cobertura corroborante: ThreatLocker, Blumira y Coalition. Los indicadores y el alcance son de un incidente que cambia rápido y pueden variar; confirma siempre con el aviso oficial de ConnectWise antes de actuar.

Ensaya la decisión de brecha de proveedor en el Vendor-Breach Board Response Lab, trabaja el playbook de brechas de terceros y puntúa tus identidades de app y de servicio con la calculadora de riesgo de identidad. Lectura relacionada: por qué la identidad no humana / agéntica es el control fundamental.