La mateixa IP va entrar en 29 empreses i va rebotar en quatre

Una adreça IP, 193.26.115.72, va passar per desenes de tenants de Microsoft 365 en quatre dies de setembre. En quatre organitzacions es va quedar fora 1.052 vegades. En unes altres vint-i-nou hi va entrar, i l'informe que ho explica ho resumeix així: «res no s'hi va interposar». L'atacant era el mateix, els tokens robats eren els mateixos i el calendari també. L'única cosa diferent era la configuració que cada empresa tenia posada abans que res d'això comencés.

Els dos grups del mateix atac

Els números surten de l'informe que Huntress va publicar el 22 d'octubre del 2026 sobre una campanya de token spray and replay contra Microsoft 365. La finestra va del 14 de juliol al 22 de setembre: deu setmanes, 497 inicis de sessió vàlids en 79 organitzacions i més de 200.000 intents fallits. Tota l'activitat es va concentrar al rang 193.26.115.0/24 d'un proveïdor d'allotjament alemany (1337 Services GmbH, AS210558, Hamburg), amb sis adreces que l'atacant va anar rotant per fases.

El paràgraf de l'informe sobre aquella adreça diu, sencer: «En quatre dies, l'adreça va completar 303 inicis de sessió amb èxit en 29 organitzacions. L'accés condicional va fer feina de debò aquí. La mateixa adreça va registrar 1.052 inicis de sessió bloquejats mentre els intents continuaven, però tots aquests blocatges van venir de només quatre organitzacions. A les 29 organitzacions on va entrar, res no s'hi va interposar».

Cal dir també que l'informe no es quadra amb si mateix, i com que el títol d'aquest post en depèn, ho posem damunt la taula. A la seva secció de mitigació, el mateix document dona un altre recompte per a la mateixa adreça: els mateixos 1.052 blocatges de quatre organitzacions, però 232 inicis amb èxit en 28 organitzacions diferents, i precisa que no hi ha solapament entre els dos grups. 303 en 29 davant de 232 en 28. Fem servir les del relat de la fase perquè és on apareixen al costat dels 1.052 blocatges, que és la comparació que ens interessa; els dos recomptes probablement mesuren retalls diferents del mateix període. La diferència és d'una organització i no mou res del que ve després, però qui vagi a la font es trobarà les dues xifres.

Un segon matís, perquè és el tipus de cosa que es perd quan se cita d'oïda: l'informe no publica la configuració d'accés condicional de cada víctima, així que ningú de fora pot dir «la política X va parar l'atac a l'empresa Y». El que sí que està escrit, amb número i atribució, és que la meitat defensada del repartiment cap en quatre empreses i que el que va fer la feina va ser accés condicional. Aquesta asimetria és la dada. Contra aquest atac sí que es pot fer alguna cosa, i el que separa els dos grups és si algú es va asseure a escriure una política.

El token s'emet després de l'MFA

Aquí no hi va haver contrasenyes endevinades. La frase que resumeix la campanya és que «els comptes de Microsoft van ser compromesos sense que l'atacant necessités mai una contrasenya». Les tres vies d'obtenció que descriu l'informe són retransmissors adversary-in-the-middle que capturen la sessió ja posterior a l'MFA, phishing de codi de dispositiu i enginyeria social durant un inici de sessió legítim.

La mecànica del primer és la que més costa explicar en una reunió. La víctima no veu una pàgina falsa mal feta: veu la pàgina real de Microsoft, perquè el retransmissor l'hi serveix tal qual. Posa la contrasenya de debò, li arriba l'avís d'MFA de debò, l'aprova, i entra. Tot va funcionar. El que passa és que la galeta de sessió que Microsoft emet al final d'aquest procés se la queda l'intermediari. I aquesta galeta ja és, per definició, una sessió amb l'MFA complert: ningú no l'hi tornarà a demanar. Demanar un segon factor més fort en aquella pantalla no canvia res, perquè el robatori passa un pas després de la pantalla.

Després ve la part industrial, que és d'on surt el nom: els tokens es reprodueixen en bloc. Més de 200.000 intents per 497 encerts deixa una taxa d'encert que no arriba al 0,25%, i aquesta proporció explica la veritat del mètode. Aquí entrem en lectura nostra, que l'informe no desglossa a què corresponen aquests fallits: el més probable és que la major part de la bossa siguin tokens ja caducats o revocats, encara que també hi haurà blocatges d'accés condicional i comptes que ja no existeixen. L'atacant no necessita distingir-los; els prova tots i es queda amb els que encara respiren. És força bruta, però contra sessions en lloc de contra contrasenyes, i el soroll forma part del mètode.

El car va començar després d'entrar

Un inici de sessió no val diners. El que val diners és quedar-s'hi. I en això la campanya va ser qualsevol cosa menys sorollosa:

• Dispositius seus dins del teu directori. L'informe observa, en el conjunt de la campanya i acotat a una de les agrupacions de client que anomena Build A, «48 dispositius diferents units a Entra, anomenats DESKTOP- més exactament vuit caràcters hexadecimals en majúscules». No són 48 a casa teva: són 48 repartits entre les víctimes. Un equip registrat és una manera de tornar a entrar que ja no depèn del token robat.
• L'MFA de l'usuari, esborrat i substituït. «En 19 organitzacions, els mètodes d'MFA existents de la víctima van ser eliminats i se'n va registrar un de nou en menys de tres hores des del primer inici de sessió d'una adreça de la campanya.» Tres hores marca el rellotge al qual cal respondre.
• Regles de bústia amb noms que ningú no llegeix. Els noms documentats són ., sss, ss, iT, ,., ........, s i d. Marcaven com a llegit, esborraven o movien correu a carpetes com Canals RSS, Subscripcions RSS o Historial de converses. Ningú no mira allà. Aquesta és la idea: que el titular del compte no vegi una part del seu propi correu.

L'ordre importa: primer una clau que no caduca, després el control del segon factor, després el silenci. Dels tres passos, l'únic que el teu usuari podria arribar a notar és el tercer, que és justament el que està dissenyat perquè no el noti.

El control que ataca això existeix, i no cobreix el navegador

Microsoft té un control pensat literalment contra això. Es diu protecció de tokens i és un control de sessió d'accés condicional que, en paraules de la seva pròpia documentació, «intenta reduir els atacs de reproducció de token assegurant que Microsoft Entra ID només accepti tokens de sessió d'inici lligats al dispositiu, com els Primary Refresh Tokens». La idea és la correcta: el token es lliga criptogràficament a l'equip, «de manera que encara que un actor maliciós robi el token, no el pugui fer servir des d'un altre dispositiu». Exactament l'atac de l'informe.

Ara la lletra petita, que està publicada i és la part que gairebé mai no s'explica. La taula de disponibilitat per plataforma d'aquesta mateixa pàgina (revisió del 14 d'agost del 2026) diu: aplicacions natives a Windows, iOS/iPadOS i macOS, disponible amb caràcter general; aplicacions basades en navegador, vista prèvia a Windows i macOS i no suportat a iOS/iPadOS. I l'abast d'aquesta vista prèvia és més estret del que sona: «el suport d'aplicacions basades en navegador està limitat actualment a aplicacions web, navegadors i configuracions de dispositiu seleccionades que accedeixen a Azure Resource Manager». Els recursos on sí que s'aplica per a aplicacions natives són Exchange Online, SharePoint Online i Microsoft Teams, més Azure Virtual Desktop i Windows 365 a Windows.

Ajunta les dues coses i surt la frase incòmoda del dia: per a la via de robatori d'aquesta campanya, el control que l'ataca encara no està disponible amb caràcter general. Un retransmissor adversary-in-the-middle roba una sessió de navegador, i aquí la protecció de tokens va per vista prèvia i acotada a l'Azure Resource Manager. Convé no convertir això en una llei general: els tokens també es roben al costat natiu, per exemple amb un infostealer a l'equip, i per a aquest cas el control sí que és madur. Tampoc no és una pega que calgui amagar: és comportament documentat, i la mateixa pàgina demana desplegar-lo en mode només informe abans de forçar-lo. El que sí que canvia és el que pots prometre en una reunió. Si algú et diu «ho tenim cobert, hem activat protecció de tokens», la pregunta següent és: en natiu o en navegador, i per a quins recursos?

Què atura què, fase per fase

Canviar la contrasenya no fa fora ningú

L'informe ho diu en dues frases que haurien d'estar enganxades al procediment de qualsevol: «un restabliment de contrasenya per si sol no elimina els dispositius ni els mètodes d'MFA registrats per l'atacant» i «a més, cal revocar les sessions; un restabliment de contrasenya per si sol no invalida el token d'accés, la qual cosa significa que l'atacant podria mantenir l'accés fins que el token caduqui (temps de vida d'aproximadament 90 minuts)». Les dues van en la mateixa direcció: la contrasenya no era el camí d'entrada, així que canviar-la no tanca el camí d'entrada.

És la mateixa lliçó que explicàvem llegint l'informe de ransomware d'aquest mes i que resumíem llavors en què recuperar ràpid no és fer fora l'atacant: tornar a tenir els serveis en peu i haver fet fora qui va entrar són dues feines diferents, i la primera es mesura en hores mentre la segona es mesura en què has mirat. Aquí el que cal mirar està enumerat: dispositius, mètodes, regles.

Quan NO: dues coses que semblen la resposta

No tanquis això bloquejant adreces. És el primer que demana tothom quan veu un rang concret en un informe, i és temptador perquè es fa en deu minuts i queda bé a l'acta. Però el mateix informe explica sis adreces del mateix /24 fetes servir de manera seqüencial al llarg de quatre fases: el blocatge que escrius avui cobreix la foto d'ahir. Hi ha un cas en què sí que val la pena, i és diferent: bloquejar ara, amb l'incident obert, per guanyar hores mentre ordenes la resta. Com a mesura permanent és un indicador de compromís convertit en política de seguretat, que no és el mateix.

I no baixis la vida de les sessions per reflex. Escurçar la freqüència de reautenticació sona a solució i té una factura que es paga en un altre lloc. Un token robat es fa servir dins de la seva finestra, així que passar de dies a hores redueix el marge sense tancar-lo; en canvi, tothom comença a veure avisos d'inici de sessió uns quants cops al dia. I un usuari entrenat durant mesos a aprovar avisos sense pensar és, exactament, l'usuari que el pròxim retransmissor necessita. L'ajust que sí que mou l'agulla és el de la primera fila de la taula: credencials que un intermediari no pot retransmetre. Amb un advertiment que ens toca donar encara que resti: de les tres vies de l'informe, aquella credencial només tanca la del retransmissor. Contra el phishing de codi de dispositiu i contra l'enginyeria social durant un inici legítim no hi fa res, perquè allà l'usuari s'autentica de debò a la pàgina de debò; per a aquests toca blocar el flux de codi de dispositiu si no el fas servir i ensenyar què demana i què no demana el suport.

La comprovació d'aquesta tarda

Sis passos. Els quatre primers són de mirar i es fan avui; els dos últims són de decidir, i són els que canvien el resultat la pròxima vegada.

1. Llista els dispositius de l'Entra registrats els últims noranta dies i compara'ls amb l'inventari, no amb la teva memòria. Cerca noms del tipus DESKTOP- seguits de vuit caràcters hexadecimals que ningú no reconegui. Si el teu inventari d'equips viu en un full que ningú no actualitza, aquest pas et farà mal i per això és el primer.
2. Treu del registre d'auditoria els canvis en mètodes d'autenticació dels últims tres mesos. El que busques és un patró: un esborrat i un registre nou per al mateix usuari dins de la mateixa hora. Cada vegada que aparegui, es truca a l'usuari i se li pregunta. No s'assumeix.
3. Recorre les regles de bústia de totes les bústies amb Get-InboxRule i queda't amb dues coses: noms d'un o dos caràcters i destins del tipus Canals RSS, Subscripcions RSS o Historial de converses. Aprofita per llistar reenviaments externs; és el mateix escombrat i respon a l'altra meitat de la pregunta.
4. Caça als inicis de sessió el que recomana el mateix informe: peticions de tipus OAuth2:Token i Cmsi:Cmsi amb agents d'usuari node o un Mozilla/5.0 pelat. Un agent d'usuari no prova res per si mateix, però és un filtre baratíssim per començar a llegir.
5. Llegeix les teves polítiques d'accés condicional per les seves exclusions, no pels seus noms. La recomanació de l'informe és exigir MFA o blocar «per a tots els usuaris, totes les aplicacions al núvol i tots els tipus d'aplicació client, sense condicions». Compta quantes de les teves polítiques compleixen això de debò un cop descomptes les excepcions que algú va posar un dimarts per una urgència que ja es va resoldre. I mira també les polítiques d'accés condicional que no vas escriure: al teu tenant hi ha polítiques que no vas redactar tu.
6. Decideix a quines vint persones els poses credencial resistent al phishing aquest trimestre. No a tothom alhora, que és com s'aconsegueix no començar mai: els que signen pagaments, els que tenen rols privilegiats i els que parlen amb proveïdors. I escriu el procediment d'expulsió en sis línies —revocar sessions, dispositius, mètodes, regles, reenviaments, avís a l'usuari per un canal que no sigui el seu correu—, perquè tres hores no donen per improvisar-lo.

On encaixa això en el que fem

Nosaltres desplegem i mantenim tenants de Microsoft 365 d'altres empreses, i el que aquest informe retrata s'arregla configurant, que és una feina que algú ha de fer un dia qualsevol, quan no hi ha incident. Això és la part menys vistosa del lloc de treball modern —inventari d'equips que quadri, mètodes d'autenticació revisats, regles de bústia que ningú no va posar d'amagat— i és la que decideix en quin grup del repartiment de dalt acabes. La capa de Zero Trust és el nom formal de la idea: que una sessió vàlida no sigui, per si sola, permís per a tot.

Si vols que fem els quatre primers passos amb tu sobre el teu tenant —dispositius, mètodes, regles de bústia i la caça als inicis de sessió—, en parlem. És una tarda. I si surt net, t'ho diem i ja està: també és un resultat útil saber que no et toca.

Fonts. La campanya, les dates (14 de juliol a 22 de setembre del 2026), els 497 inicis de sessió vàlids en 79 organitzacions, els més de 200.000 intents fallits, el rang 193.26.115.0/24 de 1337 Services GmbH (AS210558, Hamburg) i les seves sis adreces, el repartiment de 193.26.115.72 (1.052 blocatges en quatre organitzacions; 303 inicis amb èxit en 29 organitzacions al relat de la fase i 232 en 28 sense solapament a la secció de mitigació —la discrepància és del document, no nostra, i l'assenyalem al cos—), els 48 dispositius units a l'Entra amb nom DESKTOP- més vuit hexadecimals observats en el conjunt de la campanya i acotats a Build A, les 19 organitzacions amb l'MFA esborrat i re-registrat en menys de tres hores, els noms de les regles de bústia i les seves carpetes de destí, la caça per tipus de petició i agent d'usuari i les frases sobre el restabliment de contrasenya i la revocació de sessions: Huntress, «M365 Token Spray and Replay Campaign Compromises Business Email Accounts» (22 d'octubre del 2026). La cobertura amb què va arribar el cas: Help Net Security, 23 d'octubre del 2026. La definició de la protecció de tokens, la taula de disponibilitat per plataforma (natiu disponible amb caràcter general; navegador en vista prèvia a Windows i macOS i no suportat a iOS/iPadOS), el límit de la vista prèvia a aplicacions web seleccionades que accedeixen a l'Azure Resource Manager, els recursos suportats i la recomanació de desplegar en mode només informe: Microsoft Learn, «How Token Protection Enhances Conditional Access Policies» (revisió del 14 d'agost del 2026). Tot verificat el 24 d'octubre del 2026. El que no està en aquestes fonts —quina política concreta tenia cada víctima— no ho afirmem: no és públic.