El backup de tu Microsoft 365 entra con una llave que no guardas tú

El jueves 15 de octubre, de madrugada, una herramienta de copia de seguridad de Microsoft 365 inició sesión en tenants de empresas que no la habían llamado. No hubo contraseña robada, ni usuario engañado, ni token de sesión secuestrado en un portátil. La aplicación se autenticó con su propia credencial y pidió sus tokens, que es exactamente lo que hace cada noche cuando copia tu correo. Lo único distinto fue quién manejaba la credencial.

El titular de la semana es «hackean una herramienta de backup». La lectura que importa es otra, y te afecta aunque no uses esa herramienta: la llave que abre tu Microsoft 365 no vive en tu Microsoft 365. Vive en el tenant del proveedor. No la ves, no la puedes rotar, no sabes cuándo se rotó por última vez. Y —esto es lo que casi nadie ha mirado esta semana— el control que Microsoft vende para ponerle una valla a ese tipo de identidad dice por escrito, en su propia documentación, que no se aplica a ella.

Lo que pasó, con las horas puestas

Conviene leerlo en orden, porque el orden es el argumento. Todas las horas son UTC y están tomadas del análisis público d'Huntress y del aviso del fabricante:

• 13 y 14 de octubre. Intentos de inicio de sesión por rociado de contraseñas (password spraying) contra cuatro tenants de despachos de abogados, desde una única IP: 144.172.64.128. No entró nadie — el bloqueo inteligente cerró dos cuentas y no se observó ningún inicio de sesión de usuario con éxito. En ese momento no parecía tener nada que ver con lo que vendría después.
• 15 de octubre, 01:58. Principales de servicio se asignan a sí mismos roles de directorio —sobre todo Administrador de Exchange—. En unos cincuenta tenants a la vez, de los monitorizados por Huntress; el total real no lo sabe nadie.
• 15 de octubre, 03:44–03:49. En un tenant concreto, una aplicación de Teams se añade Administrador Global y pone un secreto nuevo en otras dos aplicaciones: una de gestión de MSP y la del propio Huntress, la empresa de seguridad que después publicaría el análisis. Esa credencial se usó para iniciar sesión siete veces seguidas; Huntress la detectó y la retiró el día 16. Conviene quedarse con esto: el que luego contó la historia también estaba dentro de ella.
• 15 de octubre, 06:13–08:34. La aplicación se autentica desde esa misma IP en 17 de los primeros 290 tenants revisados, repartidos en 17 cuentas de partner distintas. El denominador importa: es una muestra, no un censo.
• 16 de octubre, 19:00. 162 tenants con inicios de sesión no autorizados confirmados. En el mismo análisis: cerca de mil tenants de Entra con actividad de inicio de sesión desde esa IP, de los que más de trescientos tuvieron éxito.
• 17 de octubre, 05:01. ConnectWise anuncia la interrupción del servicio: «hemos identificado recientemente accesos no autorizados a identidades de aplicación dentro del entorno de ConnectWise Cloud Backup». Y añade que no tiene indicios, hasta la fecha, de que los datos de copia de los partners se hayan visto comprometidos.

La aplicación principal es 506e08f9-6e9a-4da4-942b-a099a03644ae, ConnectWise Cloud Backup, antes SkyKick Backup. No fue la única: también se abusó de las aplicaciones de ConnectWise Cloud Management para Teams, Exchange Online y SharePoint Online. Si gestionas tenants de terceros, esos identificadores son literales y buscables en tu consola — no hace falta que te creas a nadie.

El MFA no falló. Nadie se lo preguntó.

Aquí es donde la mayoría de las conversaciones de esta semana se tuercen. La pregunta que sale en la reunión es «¿pero no teníamos MFA?». Sí. Y era irrelevante, porque el MFA se evalúa cuando hay una persona a la que preguntar. En este flujo no hay persona: la aplicación presenta su propia credencial y pide un token. No hay segundo factor que reclamar, no hay dispositivo que evaluar, no hay riesgo de inicio de sesión de usuario que mirar.

No hace falta deducirlo: Microsoft lo escribe en la primera pantalla de su propia documentación sobre identidades de carga de trabajo. Dice que estas identidades no pueden hacer autenticación multifactor, que a menudo no tienen un proceso formal de ciclo de vida y que necesitan guardar sus credenciales o secretos en algún sitio. Las tres frases son del fabricante. La tercera es la que aquí hace daño: en este caso, ese «algún sitio» era el tenant del proveedor. La credencial se usó mediante client assertion, lo que significa, en el análisis d'Huntress, que la credencial vive en el tenant propio del fabricante del software.

Dicho en corto: alguien hizo una copia de la llave de tu casa y la guarda en la suya. Tú no puedes cambiar esa cerradura.

El control que buscarías dice por escrito que no sirve aquí

Si te dedicas a esto, lo primero que piensas es: vale, pues le pongo Acceso Condicional al principal de servicio y bloqueo los inicios de sesión que vengan de fuera de mis rangos de IP conocidos. Es exactamente la política que habría parado los accesos desde 144.172.64.128. Existe, se llama Acceso Condicional para identidades de carga de trabajo, y Microsoft la documenta paso a paso.

En la misma página, dentro de una nota gris que se lee en cuatro segundos, está la frase que desarma el plan: «La directiva se puede aplicar a principales de servicio de un solo inquilino registrados en tu inquilino. Las aplicaciones de Microsoft y las aplicaciones SaaS de terceros, incluidas las aplicaciones multiinquilino, no están cubiertas por estas directivas.»

Una herramienta de copia de Microsoft 365 que un proveedor despliega en los tenants de sus clientes es, por definición, una aplicación multiinquilino de terceros. El motivo técnico es coherente aunque resulte incómodo: tu directiva no puede gobernar el comportamiento de autenticación de una identidad cuyo origen y cuya autoridad están en otro inquilino. Las credenciales de esa identidad las gestiona su inquilino de origen, no el tuyo. Es la misma frase de antes vista desde el otro lado.

Y para que nadie se vaya con la idea de que basta con comprar la licencia: ese Acceso Condicional para identidades de carga de trabajo requiere licencias Workload Identities Premium, que son un SKU aparte; el único control de concesión disponible es bloquear el acceso (no puedes pedirle un MFA a una aplicación, porque no sabe hacerlo); y si metes el principal de servicio en un grupo y aplicas la directiva al grupo, no se aplica — hay que asignarlo directamente. Tres detalles que convierten una idea de pizarra en un proyecto. Ya escribimos sobre otra situación con la misma forma, cuando el remedio oficial de un incidente chocaba con la política de la propia casa: el consejo que tu propia política bloquea.

Entonces qué te queda (que es más de lo que parece)

Esta no es una de esas historias en las que no se puede hacer nada. Es una de esas en las que lo que sirve es barato y aburrido, y por eso no está hecho. Cuatro cosas, de menos a más coste:

1. El inventario, que es gratis y lo tienes delante. En Entra ID, Aplicaciones empresariales: ahí está la lista completa de aplicaciones que pueden entrar en tu tenant, con los permisos que les concediste, quién dio el consentimiento y cuándo. No tienes que fiarte de lo que te cuente un comercial sobre los permisos de su producto: están escritos en tu propio directorio. En la mayoría de empresas que miramos, esa lista no la ha leído nadie entera desde que se montó el tenant. Si solo vas a hacer una cosa después de leer esto, que sea abrirla.

2. El registro que sí vio esto. En Supervisión y mantenimiento > Registros de inicio de sesión hay una pestaña aparte: inicios de sesión de principal de servicio. Es una pestaña distinta de la de usuarios, y por eso casi nunca se mira. Toda la cronología de arriba —las horas, la IP, los 17 tenants— salió de ahí. No es un control, es visibilidad, y fue lo único que dejó ver esto desde tu lado del cristal. No costaba dinero: costaba acordarse de que esa pestaña existe. (El bloqueo inteligente también hizo su trabajo los días 13 y 14, cuando el intento todavía iba contra cuentas de usuario; en cuanto el ataque pasó a ser una aplicación, dejó de tener nada que bloquear.)

3. El consentimiento, que es una decisión y no un botón. Si cualquier usuario de tu organización puede aprobar que una aplicación lea su correo, el inventario del punto 1 crece sin que nadie lo decida. Exigir consentimiento de administrador y montar el flujo de aprobación convierte «alguien hizo clic en Aceptar» en «alguien firmó». Es una hora de configuración y un acuerdo interno sobre quién firma.

4. El procedimiento, escrito antes de necesitarlo. Y aquí va el detalle menos intuitivo de toda la semana, que viene literalmente de las recomendaciones de respuesta publicadas: desactiva la aplicación, no la borres. El motivo que dan es operativo: borrarla elimina el consentimiento y, para recuperar el servicio, tendrás que volver a consentirlo entero. Nosotros le añadimos un segundo motivo, que nos preocupa más: con el consentimiento se va también el rastro de qué tenía concedido y desde cuándo — justo lo que te van a pedir si alguien pregunta, sea un cliente, una aseguradora o un regulador. El resto del procedimiento es igual de seco: desactivar aunque no veas nada raro, revisar los secretos y certificados de todas tus aplicaciones empresariales y registros de aplicación (empezando por las de gestión y seguridad, que son las que más permisos tienen), y no volver a activar nada hasta que el fabricante confirme que ha rotado sus credenciales.

El fallo es inevitable; la avería es una decisión de diseño

Que a un fabricante se le comprometa una credencial es un fallo. A escala suficiente, las credenciales se filtran: es estadística, no incompetencia. Lo que decide si ese fallo se convierte en una avería dentro de tu empresa no es la suerte, es lo que tuvieras preparado el martes anterior. ¿Tenías la lista de aplicaciones? ¿Alguien mira la pestaña de principales de servicio? ¿Existe el procedimiento de desactivar sin borrar, o se improvisa a las seis de la mañana?

Y conviene decir una cosa a favor del fabricante, porque cambia el diagnóstico: según su propio comunicado, no tiene indicios hasta la fecha de que los datos de copia de los partners se hayan visto comprometidos, y los archivos existentes seguirán accesibles cuando se restablezca el servicio. Si eso se sostiene —y es un «hasta la fecha», no un cierre—, entonces el backup funcionó. Lo que se rompió fue la identidad que el backup usaba para entrar. Son dos productos distintos viajando dentro del mismo contrato, y se compran juntos porque nadie te dice que son dos.

Las cuatro preguntas que deberías hacernos a nosotros

Nosotros vendemos copia de seguridad de Microsoft 365. Así que lo que viene juega en nuestra contra, y lo escribimos igual. Conviene precisar una cosa que estos días se está contando mal: Exchange Web Services no ha desaparecido. Microsoft empezó a bloquearlo por fases el 1 de octubre de 2026, con lista de permitidos por identificador de aplicación para quien lo necesite, y lo apaga del todo el 1 de abril de 2027. Mientras dure esa ventana, hay productos de copia muy extendidos —Veeam entre ellos— que siguen sacando los buzones de Exchange Online por EWS, porque Graph todavía no cubre bien el incremental. Da igual: por EWS o por Graph, la herramienta entra en tu directorio como una aplicación con permisos concedidos, y actualizar a la versión que migra a Graph consiste, literalmente, en concederle más. No existe la copia de 365 sin una identidad privilegiada dentro de tu tenant. La nuestra tampoco.

Lo que sí puedes exigir es que quien la opere te conteste cuatro cosas sin ponerse nervioso. Nos las puedes preguntar a nosotros, y deberías preguntárselas a cualquiera que tenga una aplicación dentro de tu directorio.

La primera es qué permisos exactos tiene su aplicación en tu tenant y cuáles son de escritura. Esta no hace falta que te la contesten, porque la respuesta está en tus Aplicaciones empresariales y puedes mirarla tú; lo que mides al preguntarla es si te dicen lo mismo que ves. Lo interesante viene después: por qué necesita los permisos de escritura y qué deja de funcionar si se los quitas. La segunda es dónde vive la credencial que abre tu tenant y cuándo se rotó por última vez. Si la respuesta es «en nuestro entorno», no te alarmes: es lo normal y es como funciona el modelo. Alármate si no saben decirte cada cuánto se rota ni quién lo comprueba.

La tercera es si esa credencial se compromete, te enteras por ellos o por la prensa, y aquí la respuesta solo vale con un número de horas detrás: «os avisaremos» no es un compromiso, es una intención. Y la cuarta es la que de verdad separa a quien tiene procedimiento de quien solo tiene producto: si mañana desactivas su aplicación, qué deja de funcionar y cómo se vuelve. Si nadie en la cadena sabe contestarla, lo que llamas desactivación de emergencia es en realidad un experimento, y lo vas a hacer el peor día del año. Nosotros preferimos que nos la hagas en frío.

Nada de esto es un argumento para dejar de copiar Microsoft 365. Al revés: Microsoft no hace tus copias por ti, y ese contrato tiene letra pequeña que ya hemos desmenuzado en otro sitio — tu copia de Exchange Online depende de un campo de texto. El argumento es otro: la copia de 365 es, además de una copia, una identidad privilegiada en tu directorio, y hasta esta semana no se gobernaba como tal. La parte de identidad se gobierna con los mismos principios de mínimo privilegio que aplicas a las personas, aunque aquí no haya ninguna persona que autenticar.

Lo que haríamos esta semana, empezando por media hora

Sin proyecto, sin licencias nuevas y sin reunión. Seis pasos, por orden:

1. Abre Entra ID > Aplicaciones empresariales y ordena por fecha de creación. Lee la lista entera, aunque sea larga. Marca las que no sepas explicar en una frase.
2. De las marcadas, mira los permisos. Separa lectura de escritura y apunta cuáles tocan correo, ficheros o el propio directorio.
3. Abre Registros de inicio de sesión > inicios de sesión de principal de servicio y filtra por los últimos 30 días. Mira de qué IP y de qué país entra cada aplicación. Si algo entra desde donde no esperas, ya tienes la mañana ocupada.
4. Comprueba si el consentimiento de usuario está abierto. Si lo está, decide hoy quién firma a partir de ahora y actívalo.
5. Escribe el procedimiento de desactivación en cinco líneas, en el mismo sitio donde guardas el resto: desactivar sin borrar, quién lo autoriza fuera de horario, a quién se avisa, qué se rompe, cómo se vuelve.
6. Manda las cuatro preguntas de arriba por correo a cada proveedor que tenga una aplicación en tu tenant. El correo vale igual que la respuesta: deja fecha.

Media hora bien gastada tiene una propiedad rara en seguridad: sirve igual aunque el próximo incidente sea de otro fabricante y con otro nombre. La lista, el registro y el procedimiento no caducan con la noticia.

Fuentes (consultadas el 18-10-2026): la cronología con horas UTC, el identificador de aplicación 506e08f9-6e9a-4da4-942b-a099a03644ae, las aplicaciones secundarias de ConnectWise Cloud Management abusadas, la IP 144.172.64.128, el rociado de contraseñas contra cuatro tenants de despachos (sin ningún inicio de sesión de usuario con éxito y con dos cuentas cerradas por bloqueo inteligente), los cincuenta tenants monitorizados en los que los principales de servicio se autoasignaron roles, los 17 de los primeros 290 tenants revisados, el secreto añadido a la aplicación del propio Huntress y usado siete veces hasta su retirada el 16, los 162 tenants confirmados a las 19:00 UTC del 16 de octubre, los cerca de mil tenants con actividad desde esa IP y los más de trescientos con éxito, el uso de client assertion («la credencial vive en el tenant propio del fabricante») y la recomendación de desactivar sin borrar —con su motivo, que es operativo: «borrarla elimina el consentimiento y tendrás que volver a consentir para restaurar el servicio»— proceden del análisis público de Huntress. El comunicado de ConnectWise —«accesos no autorizados a identidades de aplicación» y «no tenemos indicios hasta la fecha de que los datos de copia de los partners se hayan visto comprometidos»— y la hora del aviso de interrupción están recogidos por BleepingComputer. Las citas sobre identidades de carga de trabajo, la exclusión literal de las aplicaciones multiinquilino de terceros, el requisito de licencias Workload Identities Premium, el único control de concesión disponible y la no aplicación de la directiva por pertenencia a grupo están en la documentación de Microsoft Entra. El calendario de retirada de Exchange Web Services (bloqueo por fases desde el 1 de octubre de 2026 con lista de permitidos por identificador de aplicación, apagado completo el 1 de abril de 2027) y el hecho de que los buzones de Exchange Online se sigan copiando por EWS a la espera de que Graph cubra el incremental están en la KB4820 de Veeam. Nuestro, y lo acotamos: la lectura de que el control de Acceso Condicional aplicable no cubre esta clase de aplicación, la segunda razón para no borrar la aplicación (perder el rastro del consentimiento, que no es el motivo que da la fuente), el orden de las cuatro medidas por coste, las cuatro preguntas a proveedor, la lista de seis pasos y la distinción entre el backup y la identidad del backup. No hemos verificado de forma independiente los recuentos de tenants: son los publicados por el investigador, proceden de su propia telemetría y así los citamos.