Van entrar com la teva aplicació, i Entra ID no va demanar cap MFA

Una sola adreça IP allotjada a Polònia va signar 412 intents d'inici de sessió en set dies contra registres d'aplicació de Microsoft Entra ID, en ràfegues de fins a 24 entrades en 10 segons i amb bucles de reintent d'onze segons. Cap d'aquests intents no va demanar un segon factor, ni va topar amb les teves polítiques d'accés condicional, ni va passar pel teu tallafoc. Eren aplicacions autenticant-se soles amb el seu propi secret, i aquest secret el tenia l'atacant.

Els números, amb la seva font

Qui ho va veure primer i ho va publicar amb detall va ser Todyl, el 3 de novembre del 2026. El seu primer registre és de l'1 de novembre a les 08:45 UTC i l'últim intent, ja bloquejat, del 3 de novembre a les 21:31 UTC. Enmig: uns 45 registres d'aplicació atacats en una vintena d'organitzacions —al voltant de 18—, més de 33 autenticacions amb èxit i accés efectiu a 27 organitzacions —les atacades directament més els clients assolits a través d'elles—. Sectors: administració pública, energia, alimentació i agricultura, transport, construcció, enginyeria, legal, educació i tercer sector.

El que l'actor va fer a dins, segons el mateix informe: unes 25 cerques en inquilins, 81 fitxers descarregats —a un ritme d'al voltant d'un fitxer per segon des de SharePoint— i uns 2.279 elements de bústia consultats. El 95 % dels inicis de sessió venien de clients programats, no d'un navegador. I l'ordre era gairebé sempre el mateix: primer un token d'Azure Resource Manager, després Key Vault —sovint en qüestió de segons—, i tot seguit Microsoft Graph, Storage i Cognitive Services. En un cas documentat van passar dos minuts i mig entre descarregar l'arxiu d'un connector i autenticar-se com l'aplicació d'aquest connector.

Microsoft va publicar la seva pròpia recerca el 5 de novembre i hi va afegir una dada que mou la data d'inici enrere: va veure inicis de sessió de servei amb èxit des d'aquesta mateixa IP ja el 28 d'octubre, quatre dies abans del primer avistament de Todyl. I una frase de Todyl que convé no perdre de vista: «No Microsoft vulnerability is involved.» No hi ha cap vulnerabilitat de Microsoft implicada. Ningú no va rebentar res. L'atacant tenia credencials vàlides i les va fer servir.

Per què el teu MFA no hi té res a veure

La frase de Todyl que explica la meitat de l'assumpte és aquesta: «Because these are app sign-ins, there is no MFA prompt, user-scoped Conditional Access doesn't apply, and firewall rules never see the traffic.» Com que són inicis de sessió d'aplicació, no hi ha petició d'MFA, l'accés condicional amb abast d'usuari no s'aplica i les regles del tallafoc no veuen mai aquest trànsit.

És el flux de credencials de client funcionant exactament tal com està dissenyat, i això és el que incomoda. Una aplicació presenta el seu identificador i el seu secret, Entra ID li retorna un token i l'aplicació treballa. No hi ha persona a qui preguntar res, així que no se li pregunta. La mateixa pàgina de Microsoft sobre accés condicional per a identitats de càrrega de treball ho resumeix en tres trets d'aquestes identitats: «Can't perform multifactor authentication», «Often have no formal lifecycle process» i «Need to store their credentials or secrets somewhere». No poden fer segon factor, gairebé mai no tenen un cicle de vida formal i necessiten desar la credencial en algun lloc. És el mateix territori que ja vam recórrer amb el token que no demana mai MFA, amb una diferència important: allà l'atacant s'hi colava per un consentiment que algú donava; aquí no cal enganyar ningú, n'hi ha prou de tenir la contrasenya de l'aplicació.

El control que ho atura es ven a part

Sí que hi ha una política que hauria bloquejat això per adreça IP: l'accés condicional per a identitats de càrrega de treball. L'informe explica que el 3 de novembre, a les 18:12 UTC, l'accés condicional va arribar a bloquejar tokens de refresc reutilitzats —d'usuaris, i sense precisar amb quin tipus de política—, així que alguna cosa funciona. Todyl la recomana i avisa que exigeix la llicència Workload ID Premium. El que gairebé mai no apareix és el preu: 3 dòlars per identitat de càrrega de treball i mes.

I aquí hi ha el segon preu, que no es paga en dòlars. Microsoft escriu a la pàgina d'accés condicional per a identitats de càrrega de treball, la que la mateixa FAQ enllaça: «Policy can be applied to single tenant service principals that are registered in your tenant. Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies. Managed identities aren't covered by policy.» Les aplicacions multiinquilí queden fora. I multiinquilí és justament la forma de l'aplicació que un proveïdor extern —el teu, o nosaltres— té dins del teu inquilí. El control de 3 dòlars al mes arriba a les teves aplicacions pròpies i s'atura on comença el cas d'aquest episodi.

La credencial que el mateix fabricant et diu que no facis servir

La credencial que és al centre de tot això —el secret de client— és exactament la que Microsoft desaconsella. La seva pàgina sobre credencials d'aplicació ho escriu així: «Client secrets are less secure than certificate or federated credentials and therefore should not be used in production environments.» No s'haurien de fer servir en producció. I són en producció gairebé a tot arreu.

La mateixa pàgina posa dues xifres damunt la taula: la vida d'un secret de client està limitada a dos anys (24 mesos) o menys i no se'n pot demanar un període més gran; i Microsoft recomana fixar una caducitat inferior a 12 mesos. El sostre són dos anys; la recomanació del mateix fabricant és menys de la meitat. Val la pena mirar quina data tenen els teus.

Cinc minuts

D'on van sortir aquests secrets és la pregunta que de debò canvia coses. Microsoft i Todyl apunten a ARTEX, un marc ofensiu agèntic —és a dir, automatitzat amb un model que decideix els passos següents— que des de l'agost del 2026 llança grans volums de consultes a GitHub buscant secrets. Les consultes, segons Microsoft, solen combinar el nom de l'organització objectiu amb paraules clau de secrets i de serveis al núvol.

Aquest número trenca un càlcul corrent, encara que no es digui: «si se m'escapa una clau en un repositori, tinc marge per rotar-la». El marge existia perquè trobar-la era car. Buscar ja no costa res, i el que abans era una tasca d'algú ara és un bucle que no dorm. És la mateixa mecànica que descrivíem en parlar de qui figura al registre quan treballa un agent d'IA: l'agent no hi surt, hi surt la credencial que algú li va deixar. Microsoft va ampliar la cobertura el 6 de novembre amb un segon avís sobre el mateix marc apuntant al sector financer, així que això no s'ha tancat.

Todyl hi afegeix un detall sobre l'origen que, si tens proveïdors, hauries de llegir dues vegades: uns quants dels secrets inicials només s'havien fet servir des d'equips del personal o des de xarxes d'oficina, i alguns van arribar en parelles de versió vigent i caducada, cosa que per a ells suggereix un magatzem de fitxers o un sistema en funcionament, no un repositori públic. Un secret amb el seu historial al costat surt d'un document, d'una exportació de gestor de contrasenyes o d'una fitxa d'eina de suport.

On ens assenyala això a nosaltres

Convé dir-ho amb totes les lletres: everyWAN és un proveïdor de serveis gestionats, i la porta per la qual va entrar aquest actor és exactament la nostra. Tenim registres d'aplicació dins d'inquilins de clients —per a còpies, per a monitorització, per a automatització— igual que els té qualsevol que faci aquesta feina. Una campanya que recorre proveïdors per arribar als seus clients ens posa al costat de l'auditat.

Les recomanacions que Todyl dirigeix específicament a proveïdors són tres i són incòmodes en el bon sentit: revisar l'accés a Partner Center i les relacions GDAP, auditar les aplicacions que el proveïdor té en inquilins de clients, i no guardar mai secrets d'aplicació de clients en runbooks, en notes de l'eina de suport ni en documentació. Aquesta última és la que separa un proveïdor seriós de la resta, i no es comprova amb un certificat: es comprova preguntant. Si un proveïdor teu no et pot dir avui quins registres d'aplicació té al teu inquilí i amb quins permisos, ja tens la primera línia de la teva auditoria. I sí, tens dret a fer-nos a nosaltres la mateixa pregunta.

Hi ha una conseqüència legal que tampoc no convé esquivar. Todyl classifica l'accés confirmat com un possible esdeveniment d'exposició de dades que requereix involucrar els responsables jurídics i de privacitat. Bústies llegides i fitxers descarregats en inquilins de clients és, en termes de compliment i continuïtat, material de notificació amb terminis, no d'informe intern. Qui hagi de decidir això necessita saber abans què es va tocar i durant quant de temps, i per a això cal el registre del punt següent.

Tres comprovacions, amb les seves ordres

Això es pot mirar avui, sense comprar res i sense finestra d'aturada. Són tres preguntes i totes tres tenen resposta amb un número.

1. Quants secrets vius tens i quan caduquen. Amb el mòdul de Microsoft Graph per a PowerShell, en mode lectura:

Mira la columna Secretos davant la de Certificados. Cada fila amb secrets i sense certificat és una aplicació que s'està autenticant amb allò que Microsoft diu que no es faci servir en producció. La llista completa sol ser més llarga del que espera qui la demana, per la mateixa raó per la qual el directori acaba tenint més fitxes que empleats: ningú no dona de baixa allò que ningú no recorda haver donat d'alta.

2. Quins permisos de només-aplicació té cadascuna. Un secret robat val el que valguin els permisos de la seva aplicació. Els que es concedeixen a l'aplicació sencera, sense usuari al darrere, són els que importen aquí:

Si alguna aplicació amb secret té Mail.Read, Files.Read.All o Directory.Read.All a nivell d'aplicació, ja saps què s'hauria endut l'actor d'aquest episodi a casa teva: bústies i fitxers, que és exactament el que es va endur a les alienes.

3. El registre que no estàs mirant. Els inicis de sessió d'aplicació viuen en una altra pestanya del registre d'inicis de sessió —«Inicis de sessió de principal de servei», a Entra ID > Monitoratge i estat— i en una altra taula de Log Analytics. Si exportes els registres d'Entra:

Aquí ve la part honesta: pot ser que no tinguis aquest històric. Al portal, els registres d'Entra es guarden 7 dies al pla gratuït i 30 dies amb P1 o P2, i el canvi no és retroactiu: la mateixa documentació avisa que en passar de Free a P1 o P2 només recuperes el que encara sigui dins d'aquests set dies. Todyl recomana retrocedir com a mínim fins al 28 d'octubre per buscar aquesta activitat. Aquesta data, avui, ja és fora de la finestra gratuïta.

El que no faríem aquesta setmana

No compraríem Workload ID Premium avui. Una política necessita un subjecte, i a 3 dòlars per identitat i mes el primer que es paga sense el cens fet és l'inventari que no has fet. L'ordre que ens sembla defensable és un altre: primer la llista del punt 1; després treure aplicacions que ja no fa servir ningú i credencials caducades; tot seguit passar a certificat o a credencial federada tot allò que el producte permeti —que és més del que sembla, perquè moltes integracions ho suporten i ningú no ho va canviar en el seu moment—; i només amb el que quedi damunt la taula decidir si justifica el SKU. Pot ser que sí. Però llavors serà una decisió amb un número al darrere.

I no esborraríem secrets en bloc un divendres a la tarda. Un registre d'aplicació sense credencial vàlida és una còpia de seguretat que deixa d'executar-se, un connector que deixa de sincronitzar o una alerta que deixa d'arribar, i d'això te n'assabentes el dilluns. Cada secret que es treu necessita saber abans quin procés el feia servir. Aquesta frase, dita així, sembla de manual; el que té d'incòmode és que gairebé mai no hi ha qui pugui respondre-la sense obrir una eina.

Fonts (verificades el 08-11-2026): cronologia (1 de novembre 08:45 UTC, últim intent bloquejat el 3 de novembre 21:31 UTC), 412 intents en set dies, 45 registres d'aplicació en ~18 organitzacions, 33+ autenticacions amb èxit, 27 organitzacions assolides, ~25 cerques en inquilins, 81 fitxers, ~2.279 elements de bústia, 95 % de clients programats, ràfegues de 24 inicis en 10 s amb reintents d'11 s, ordre ARM → Key Vault → Graph/Storage/Cognitive Services, els dos minuts i mig del connector, la frase sobre l'MFA i l'accés condicional, l'origen dels secrets (ús previ només des d'equips del personal i parelles vigent/caducat) i les recomanacions per a proveïdors (Partner Center, GDAP, no guardar secrets de clients en runbooks ni documentació) — informe de Todyl, 03-11-2026; inicis de sessió de servei amb èxit des de la mateixa IP ja el 28 d'octubre, el marc ARTEX, les consultes a GitHub des de l'agost del 2026 i la citació dels cinc minuts — Microsoft Threat Intelligence, 05-11-2026 i la seva continuació del 06-11-2026 sobre el sector financer; cobertura independent de la campanya i del seu abast en clients de proveïdors — Cybersecurity Dive, 04-11-2026; frases literals sobre els secrets de client («should not be used in production environments»), el sostre de 24 mesos i la recomanació de menys de 12 — Microsoft Learn, credencials d'aplicació; SKU independent de Workload ID Premium a 3 $/identitat/mes, taula de funcions Free vs Premium i la frase sobre aplicacions d'un sol inquilí — preguntes freqüents de Microsoft Entra Workload ID. La retenció de 7 dies al pla gratuït i 30 amb P1/P2 és la documentada per Microsoft per als registres d'Entra. L'exclusió d'aplicacions multiinquilí i d'identitats administrades, la frase sobre els tres trets de les identitats de càrrega de treball i la ruta del registre d'inicis de sessió de principal de servei — Microsoft Learn, accés condicional per a identitats de càrrega de treball. Les ordres de PowerShell i la consulta KQL són elaboració nostra. Fotografia: «Key cabinet», de Thomas Quine, CC BY 2.0 via Wikimedia Commons, retallada per nosaltres.