El backup del teu Microsoft 365 entra amb una clau que no guardes tu

Dijous 15 d'octubre, de matinada, una eina de còpia de seguretat de Microsoft 365 va iniciar sessió en tenants d'empreses que no l'havien demanat. No hi va haver contrasenya robada, ni usuari enganyat, ni token de sessió segrestat en un portàtil. L'aplicació es va autenticar amb la seva pròpia credencial i va demanar els seus tokens, que és exactament el que fa cada nit quan copia el teu correu. L'única cosa diferent va ser qui manejava la credencial.

El titular de la setmana és «pirategen una eina de backup». La lectura que importa és una altra, i t'afecta encara que no facis servir aquesta eina: la clau que obre el teu Microsoft 365 no viu al teu Microsoft 365. Viu al tenant del proveïdor. No la veus, no la pots rotar, no saps quan es va rotar per última vegada. I —això és el que gairebé ningú no ha mirat aquesta setmana— el control que Microsoft ven per posar una tanca a aquest tipus d'identitat diu per escrit, a la seva pròpia documentació, que no s'hi aplica.

Què va passar, amb les hores posades

Val la pena llegir-ho en ordre, perquè l'ordre és l'argument. Totes les hores són UTC i estan preses de l'anàlisi pública d'Huntress i de l'avís del fabricant:

• 13 i 14 d'octubre. Intents d'inici de sessió per ruixada de contrasenyes (password spraying) contra quatre tenants de despatxos d'advocats, des d'una única IP: 144.172.64.128. No hi va entrar ningú — el bloqueig intel·ligent va tancar dos comptes i no es va observar cap inici de sessió d'usuari amb èxit. En aquest moment no semblava tenir res a veure amb el que vindria després.
• 15 d'octubre, 01:58. Principals de servei s'assignen a si mateixos rols de directori —sobretot Administrador d'Exchange—. En una cinquantena de tenants alhora, dels monitoritzats per Huntress; el total real no el sap ningú.
• 15 d'octubre, 03:44–03:49. En un tenant concret, una aplicació de Teams s'afegeix Administrador Global i posa un secret nou en dues aplicacions més: una de gestió d'MSP i la del mateix Huntress, l'empresa de seguretat que després publicaria l'anàlisi. Aquesta credencial es va fer servir per iniciar sessió set vegades seguides; Huntress la va detectar i la va retirar el dia 16. Convé quedar-se amb això: qui després va explicar la història també hi era a dins.
• 15 d'octubre, 06:13–08:34. L'aplicació s'autentica des d'aquesta mateixa IP en 17 dels primers 290 tenants revisats, repartits en 17 comptes de partner diferents. El denominador importa: és una mostra, no un cens.
• 16 d'octubre, 19:00. 162 tenants amb inicis de sessió no autoritzats confirmats. A la mateixa anàlisi: prop de mil tenants d'Entra amb activitat d'inici de sessió des d'aquesta IP, dels quals més de tres-cents van tenir èxit.
• 17 d'octubre, 05:01. ConnectWise anuncia la interrupció del servei: «hem identificat recentment accessos no autoritzats a identitats d'aplicació dins de l'entorn de ConnectWise Cloud Backup». I afegeix que no té indicis, fins a la data, que les dades de còpia dels partners s'hagin vist compromeses.

L'aplicació principal és 506e08f9-6e9a-4da4-942b-a099a03644ae, ConnectWise Cloud Backup, abans SkyKick Backup. No va ser l'única: també es va abusar de les aplicacions de ConnectWise Cloud Management per a Teams, Exchange Online i SharePoint Online. Si gestiones tenants de tercers, aquests identificadors són literals i cercables a la teva consola — no cal que et creguis ningú.

L'MFA no va fallar. Ningú no l'hi va preguntar.

Aquí és on la majoria de converses d'aquesta setmana es torcen. La pregunta que surt a la reunió és «però no teníem MFA?». Sí. I era irrellevant, perquè l'MFA s'avalua quan hi ha una persona a qui preguntar. En aquest flux no hi ha persona: l'aplicació presenta la seva pròpia credencial i demana un token. No hi ha segon factor a reclamar, no hi ha dispositiu a avaluar, no hi ha risc d'inici de sessió d'usuari a mirar.

No cal deduir-ho: Microsoft ho escriu a la primera pantalla de la seva pròpia documentació sobre identitats de càrrega de treball. Diu que aquestes identitats no poden fer autenticació multifactor, que sovint no tenen un procés formal de cicle de vida i que necessiten guardar les seves credencials o secrets en algun lloc. Les tres frases són del fabricant. La tercera és la que aquí fa mal: en aquest cas, aquest «algun lloc» era el tenant del proveïdor. La credencial es va fer servir mitjançant client assertion, cosa que significa, segons l'anàlisi d'Huntress, que la credencial viu al tenant propi del fabricant del programari.

Dit en curt: algú va fer una còpia de la clau de casa teva i la guarda a la seva. Tu no pots canviar aquest pany.

El control que buscaries diu per escrit que aquí no serveix

Si et dediques a això, el primer que penses és: d'acord, doncs poso Accés Condicional al principal de servei i bloquejo els inicis de sessió que vinguin de fora dels meus rangs d'IP coneguts. És exactament la política que hauria aturat els accessos des de 144.172.64.128. Existeix, es diu Accés Condicional per a identitats de càrrega de treball, i Microsoft la documenta pas a pas.

A la mateixa pàgina, dins d'una nota grisa que es llegeix en quatre segons, hi ha la frase que desarma el pla: «La directiva es pot aplicar a principals de servei d'un sol inquilí registrats al teu inquilí. Les aplicacions de Microsoft i les aplicacions SaaS de tercers, incloses les aplicacions multiinquilí, no estan cobertes per aquestes directives.»

Una eina de còpia de Microsoft 365 que un proveïdor desplega als tenants dels seus clients és, per definició, una aplicació multiinquilí de tercers. El motiu tècnic és coherent encara que resulti incòmode: la teva directiva no pot governar el comportament d'autenticació d'una identitat l'origen i l'autoritat de la qual són en un altre inquilí. Les credencials d'aquesta identitat les gestiona el seu inquilí d'origen, no el teu. És la mateixa frase d'abans vista des de l'altre costat.

I perquè ningú no se'n vagi amb la idea que n'hi ha prou amb comprar la llicència: aquest Accés Condicional per a identitats de càrrega de treball requereix llicències Workload Identities Premium, que són un SKU a part; l'únic control de concessió disponible és bloquejar l'accés (no pots demanar un MFA a una aplicació, perquè no en sap); i si fiques el principal de servei en un grup i apliques la directiva al grup, no s'aplica — cal assignar-lo directament. Tres detalls que converteixen una idea de pissarra en un projecte. Ja vam escriure sobre una altra situació amb la mateixa forma, quan el remei oficial d'un incident xocava amb la política de la casa mateixa: el consell que la teva pròpia política bloqueja.

Aleshores què et queda (que és més del que sembla)

Aquesta no és una d'aquelles històries en què no es pot fer res. És una d'aquelles en què el que serveix és barat i avorrit, i per això no està fet. Quatre coses, de menys a més cost:

1. L'inventari, que és gratis i el tens al davant. A Entra ID, Aplicacions empresarials: allà hi ha la llista completa d'aplicacions que poden entrar al teu tenant, amb els permisos que els vas concedir, qui va donar el consentiment i quan. No t'has de refiar del que t'expliqui un comercial sobre els permisos del seu producte: estan escrits al teu propi directori. A la majoria d'empreses que mirem, ningú no ha llegit aquesta llista sencera des que es va muntar el tenant. Si només has de fer una cosa després de llegir això, que sigui obrir-la.

2. El registre que sí que va veure això. A Supervisió i manteniment > Registres d'inici de sessió hi ha una pestanya a part: inicis de sessió de principal de servei. És una pestanya diferent de la d'usuaris, i per això gairebé mai no es mira. Tota la cronologia de dalt —les hores, la IP, els 17 tenants— va sortir d'aquí. No és un control, és visibilitat, i va ser l'única cosa que va deixar veure això des del teu costat del vidre. No costava diners: costava recordar que aquesta pestanya existeix. (El bloqueig intel·ligent també va fer la seva feina els dies 13 i 14, quan l'intent encara anava contra comptes d'usuari; així que l'atac va passar a ser una aplicació, va deixar de tenir res a bloquejar.)

3. El consentiment, que és una decisió i no un botó. Si qualsevol usuari de la teva organització pot aprovar que una aplicació llegeixi el seu correu, l'inventari del punt 1 creix sense que ningú ho decideixi. Exigir consentiment d'administrador i muntar el flux d'aprovació converteix «algú va fer clic a Acceptar» en «algú va signar». És una hora de configuració i un acord intern sobre qui signa.

4. El procediment, escrit abans de necessitar-lo. I aquí va el detall menys intuïtiu de tota la setmana, que ve literalment de les recomanacions de resposta publicades: desactiva l'aplicació, no l'esborris. El motiu que donen és operatiu: esborrar-la elimina el consentiment i, per recuperar el servei, hauràs de tornar a consentir-lo sencer. Nosaltres hi afegim un segon motiu, que ens amoïna més: amb el consentiment se'n va també el rastre de què tenia concedit i des de quan — just el que et demanaran si algú pregunta, sigui un client, una asseguradora o un regulador. La resta del procediment és igual de seca: desactivar encara que no vegis res estrany, revisar els secrets i certificats de totes les teves aplicacions empresarials i registres d'aplicació (començant per les de gestió i seguretat, que són les que més permisos tenen), i no tornar a activar res fins que el fabricant confirmi que ha rotat les seves credencials.

La fallada és inevitable; l'avaria és una decisió de disseny

Que a un fabricant se li comprometi una credencial és una fallada. A escala suficient, les credencials es filtren: és estadística, no incompetència. El que decideix si aquesta fallada es converteix en una avaria dins de la teva empresa no és la sort, és el que tinguessis preparat el dimarts anterior. Tenies la llista d'aplicacions? Algú mira la pestanya de principals de servei? Existeix el procediment de desactivar sense esborrar, o s'improvisa a les sis del matí?

I convé dir una cosa a favor del fabricant, perquè canvia el diagnòstic: segons el seu propi comunicat, no té indicis fins a la data que les dades de còpia dels partners s'hagin vist compromeses, i els arxius existents continuaran accessibles quan es restableixi el servei. Si això se sosté —i és un «fins a la data», no un tancament—, aleshores el backup va funcionar. El que es va trencar va ser la identitat que el backup feia servir per entrar. Són dos productes diferents viatjant dins del mateix contracte, i es compren junts perquè ningú no et diu que en són dos.

Les quatre preguntes que ens hauries de fer a nosaltres

Nosaltres venem còpia de seguretat de Microsoft 365. Així que el que ve juga en contra nostra, i ho escrivim igualment. Convé precisar una cosa que aquests dies s'explica malament: Exchange Web Services no ha desaparegut. Microsoft el va començar a bloquejar per fases l'1 d'octubre de 2026, amb llista de permesos per identificador d'aplicació per a qui ho necessiti, i l'apaga del tot l'1 d'abril de 2027. Mentre duri aquesta finestra, hi ha productes de còpia molt estesos —Veeam entre ells— que continuen traient les bústies d'Exchange Online per EWS, perquè Graph encara no cobreix bé l'incremental. Tant és: per EWS o per Graph, l'eina entra al teu directori com una aplicació amb permisos concedits, i actualitzar a la versió que migra a Graph consisteix, literalment, a concedir-n'hi més. No existeix la còpia de 365 sense una identitat privilegiada dins del teu tenant. La nostra tampoc.

El que sí que pots exigir és que qui l'operi et contesti quatre coses sense posar-se nerviós. Ens les pots preguntar a nosaltres, i les hauries de preguntar a qualsevol que tingui una aplicació dins del teu directori.

La primera és quins permisos exactes té la seva aplicació al teu tenant i quins són d'escriptura. Aquesta no cal que te la contestin, perquè la resposta és a les teves Aplicacions empresarials i la pots mirar tu; el que mesures preguntant-la és si et diuen el mateix que veus. L'interessant ve després: per què necessita els permisos d'escriptura i què deixa de funcionar si els hi treus. La segona és on viu la credencial que obre el teu tenant i quan es va rotar per última vegada. Si la resposta és «al nostre entorn», no t'alarmis: és el normal i és com funciona el model. Alarma't si no et saben dir cada quant es rota ni qui ho comprova.

La tercera és si aquesta credencial es compromet, t'assabentes per ells o per la premsa, i aquí la resposta només val amb un nombre d'hores al darrere: «us avisarem» no és un compromís, és una intenció. I la quarta és la que de debò separa qui té procediment de qui només té producte: si demà desactives la seva aplicació, què deixa de funcionar i com es torna enrere. Si ningú de la cadena no sap contestar-la, el que en dius desactivació d'emergència és en realitat un experiment, i el faràs el pitjor dia de l'any. Nosaltres preferim que ens la facis en fred.

Res d'això és un argument per deixar de copiar Microsoft 365. Al contrari: Microsoft no fa les teves còpies per tu, i aquest contracte té lletra petita que ja hem esmicolat en un altre lloc — la teva còpia d'Exchange Online depèn d'un camp de text. L'argument és un altre: la còpia de 365 és, a més d'una còpia, una identitat privilegiada al teu directori, i fins aquesta setmana no es governava com a tal. La part d'identitat es governa amb els mateixos principis de mínim privilegi que apliques a les persones, encara que aquí no hi hagi cap persona a autenticar.

El que faríem aquesta setmana, començant per mitja hora

Sense projecte, sense llicències noves i sense reunió. Sis passos, per ordre:

1. Obre Entra ID > Aplicacions empresarials i ordena per data de creació. Llegeix la llista sencera, encara que sigui llarga. Marca les que no sàpigues explicar en una frase.
2. De les marcades, mira'n els permisos. Separa lectura d'escriptura i apunta quines toquen correu, fitxers o el directori mateix.
3. Obre Registres d'inici de sessió > inicis de sessió de principal de servei i filtra pels últims 30 dies. Mira des de quina IP i de quin país entra cada aplicació. Si alguna cosa entra des d'on no esperes, ja tens el matí ocupat.
4. Comprova si el consentiment d'usuari està obert. Si ho està, decideix avui qui signa a partir d'ara i activa-ho.
5. Escriu el procediment de desactivació en cinc línies, al mateix lloc on guardes la resta: desactivar sense esborrar, qui ho autoritza fora d'horari, a qui s'avisa, què es trenca, com es torna enrere.
6. Envia les quatre preguntes de dalt per correu a cada proveïdor que tingui una aplicació al teu tenant. El correu val igual que la resposta: deixa data.

Mitja hora ben gastada té una propietat rara en seguretat: serveix igual encara que el pròxim incident sigui d'un altre fabricant i amb un altre nom. La llista, el registre i el procediment no caduquen amb la notícia.

Fonts (consultades el 18-10-2026): la cronologia amb hores UTC, l'identificador d'aplicació 506e08f9-6e9a-4da4-942b-a099a03644ae, les aplicacions secundàries de ConnectWise Cloud Management abusades, la IP 144.172.64.128, la ruixada de contrasenyes contra quatre tenants de despatxos (sense cap inici de sessió d'usuari amb èxit i amb dos comptes tancats per bloqueig intel·ligent), els cinquanta tenants monitoritzats en què els principals de servei es van autoassignar rols, els 17 dels primers 290 tenants revisats, el secret afegit a l'aplicació del mateix Huntress i fet servir set vegades fins a la seva retirada el dia 16, els 162 tenants confirmats a les 19:00 UTC del 16 d'octubre, els prop de mil tenants amb activitat des d'aquesta IP i els més de tres-cents amb èxit, l'ús de client assertion («la credencial viu al tenant propi del fabricant») i la recomanació de desactivar sense esborrar —amb el seu motiu, que és operatiu: «esborrar-la elimina el consentiment i hauràs de tornar a consentir per restaurar el servei»— provenen de l'anàlisi pública d'Huntress. El comunicat de ConnectWise —«accessos no autoritzats a identitats d'aplicació» i «no tenim indicis fins a la data que les dades de còpia dels partners s'hagin vist compromeses»— i l'hora de l'avís d'interrupció estan recollits per BleepingComputer. Les cites sobre identitats de càrrega de treball, l'exclusió literal de les aplicacions multiinquilí de tercers, el requisit de llicències Workload Identities Premium, l'únic control de concessió disponible i la no aplicació de la directiva per pertinença a grup són a la documentació de Microsoft Entra. El calendari de retirada d'Exchange Web Services (bloqueig per fases des de l'1 d'octubre de 2026 amb llista de permesos per identificador d'aplicació, apagada completa l'1 d'abril de 2027) i el fet que les bústies d'Exchange Online se segueixin copiant per EWS a l'espera que Graph cobreixi l'incremental són a la KB4820 de Veeam. Nostre, i ho acotem: la lectura que el control d'Accés Condicional aplicable no cobreix aquesta mena d'aplicació, la segona raó per no esborrar l'aplicació (perdre el rastre del consentiment, que no és el motiu que dona la font), l'ordre de les quatre mesures per cost, les quatre preguntes a proveïdor, la llista de sis passos i la distinció entre el backup i la identitat del backup. No hem verificat de manera independent els recomptes de tenants: són els publicats per l'investigador, provenen de la seva pròpia telemetria i així els citem.