L'avís el va enviar Anthropic, no el teu antivirus

El 30 d'agost es va saber que Anthropic estava enviant un correu a alguns usuaris de Claude. Ho resumeix una frase seva: «hem sabut recentment d'un actor maliciós que està fent servir malware infostealer comú per robar sessions d'inici de Claude dels ordinadors de la gent, i després fer servir aquelles sessions per accedir als comptes i consumir-ne l'ús». La cobertura ho va tractar com una notícia d'intel·ligència artificial. No ho és. Si algú de la teva empresa va rebre aquell correu, el que tens al davant és un comunicat d'infecció d'un equip del teu parc, signat per un proveïdor que ni tan sols és teu.

Venem automatització i IA i ciberseguretat, o sigui que l'interès està declarat des de la primera línia. Per això comencem per la part que ens treu l'argument fàcil, i que Anthropic va deixar escrita sense ambigüitat: «no tenim cap motiu per creure que aquest malware estigui relacionat amb Claude, s'hagi instal·lat a través de Claude o tingui a veure amb res que fessis amb Claude». És malware genèric, del que arriba amb un instal·lador no oficial o una aplicació maliciosa. No hi ha cap forat al producte. I tot i així, per a força empreses, aquest serà l'avís de seguretat més útil del mes.

Què va passar, i per on se'n van assabentar

Les famílies que Anthropic anomena són les de sempre: Vidar, LummaC2, StealC, RedLine i Acreed a Windows, i Atomic Stealer (AMOS) a macOS, aquest últim en un nombre petit de casos. El que copien tampoc no és nou: contrasenyes desades, galetes del navegador i credencials emmagatzemades en local. Anthropic va tancar la sessió als afectats, va revocar les sessions compromeses, va treure els mètodes de pagament desats dels comptes, va tornar els càrrecs que va identificar com a no autoritzats i va mantenir els plans fins al final del període de facturació en curs.

La frase que a nosaltres ens sembla la més interessant de tot l'avís és aquesta altra, i no parla de seguretat: «si els teus límits d'ús semblaven recarregar-se i després buidar-se mentre tu no estaves fent servir Claude, aquesta va ser probablement la causa». Aquí hi ha el sensor. L'indici que va fer saltar tot això no va ser un antivirus, ni una regla de detecció, ni un analista mirant telemetria d'un equip. Va ser el consum: comptes que gastaven a hores en què el seu propietari no hi era. Un patró de facturació.

Claude no és l'incident. És el canari.

Hi ha una altra frase a l'avís que convé llegir dues vegades, perquè és la que reclassifica l'assumpte sencer: «tancar-te la sessió a Claude atura les sessions robades, però no elimina el malware». Un infostealer no va a per un compte concret. Va a pel perfil del navegador sencer i pel que hi hagi desat al disc. Si l'equip d'un empleat teu va entregar la galeta de Claude, va entregar alhora tota la resta que visqués en aquell perfil: la sessió de Microsoft 365, el portal de la VPN, el panell del router, el GitLab, el correu web, el gestor de contrasenyes si estava desbloquejat.

Claude només és el lloc on el robatori es nota, i es nota per una raó ximple: el lladre gasta. De totes les sessions que hi ha en un perfil de navegador d'oficina, la de l'eina d'IA és de les poques que tenen un comptador que es buida. Si et roben la sessió del correu corporatiu, ningú no veurà un límit d'ús esgotant-se de matinada. Per això aquest avís va arribar i els altres no. És el mateix origen que ja vam veure a l'agost, quan algú venia directoris sencers d'Entra amb més fitxes que empleats: no hi havia cap bretxa de plataforma, les credencials es van rastrejar fins a infeccions d'infostealer en equips d'usuaris. I a macOS ja vam explicar com hi arriba aquell malware sense explotar cap vulnerabilitat: l'enganxa el mateix usuari al Terminal. El que aquest cas afegeix al que ja vam dir parlant de passkeys no és el diagnòstic —l'anella es va moure a l'equip, això ja estava dit— sinó l'aritmètica del que passa després, que és el que ve ara.

L'MFA no va fallar: no va arribar a jugar

Gairebé tota la cobertura resumeix això com «el robatori esquiva el doble factor». És cert, però està mal explicat, i el matís canvia què cal fer. L'MFA no va fallar. L'MFA no va arribar a entrar en joc. Una galeta de sessió no és una credencial: és el comprovant d'una autenticació que ja va passar i que va sortir bé. L'atacant no inicia sessió, o sigui que no hi ha cap moment en què algú li pugui demanar un segon factor. Reprodueix una sessió que ja estava iniciada. És la mateixa família de problema que vam explicar amb els tokens de les aplicacions connectades a Microsoft 365, amb una diferència important: allà el token el concedies tu signant un consentiment, i aquí te'l treuen del disc sense preguntar-te res.

Els cinc esdeveniments que tallen una sessió, i el que no hi és

Si la teva identitat corporativa viu a Microsoft Entra, el mecanisme que existeix per a això es diu avaluació contínua d'accés (CAE). En comptes d'esperar que caduqui el token, els serveis se subscriuen a una llista d'esdeveniments crítics i reaccionen gairebé en temps real. La documentació n'enumera exactament cinc:

• El compte d'usuari s'esborra o es deshabilita.
• Es canvia o es restableix la contrasenya de l'usuari.
• S'activa l'MFA per a l'usuari.
• Un administrador revoca explícitament tots els refresh tokens de l'usuari.
• Microsoft Entra ID Protection detecta risc d'usuari alt.

Ara llegeix la llista una altra vegada buscant «l'equip de l'usuari està infectat». No hi és. No existeix un esdeveniment crític que signifiqui «aquesta màquina està entregant galetes». L'única porta per la qual aquell fet pot entrar és la cinquena, el risc d'usuari alt, i aquella porta cal obrir-la: o ho dedueix ID Protection pel seu compte, o algú ho marca. Dit d'una altra manera, i és la nostra lectura, no una citació: l'estat que de debò importa aquí no és un estat que l'emissor de tokens conegui tot sol. Algú l'hi ha de dir. Si ningú no l'hi diu, el token continua sent vàlid perquè, des d'on mira Entra, no ha passat res.

L'aritmètica de la revocació, sense adorns

Els números estan tots publicats i convé tenir-los junts, perquè gairebé ningú no els posa a la mateixa frase. Sense CAE, la vida per defecte d'un token d'accés és d'una hora. Amb CAE, aquell token passa a ser de llarga durada, fins a vint-i-vuit hores, precisament perquè la revocació deixa de dependre del rellotge i passa a dependre dels esdeveniments. La resposta a un esdeveniment crític es descriu com «gairebé en temps real», amb una latència declarada de fins a quinze minuts pel temps de propagació (l'aplicació de polítiques d'ubicació per IP sí que és instantània). I la implementació inicial, diu la mateixa documentació, se centra en Exchange, Teams i SharePoint Online.

Aquí hi ha el detall que tomba el pla de molta gent. El primer que fa gairebé tothom quan sospita d'un compte és treure aquella persona d'un grup o posar-li una política nova d'accés condicional. Doncs bé: la documentació diu que els canvis en polítiques d'accés condicional i en pertinença a grups poden trigar fins a un dia a ser efectius, per replicació entre Entra i els proveïdors de recurs, amb una optimització que baixa a dues hores els canvis de política i que, dit per la mateixa documentació, encara no cobreix tots els escenaris. L'única cosa que talla avui és revocar la sessió expressament: el botó «Revocar sessió» de la fitxa de l'usuari o l'ordre Revoke-MgUserSignInSession. I tres avisos més de la lletra petita: CAE no admet comptes de convidat —és a dir, els externs: el consultor, l'agència, el teu mateix proveïdor d'IT—; si la suma de rangs IP de les teves ubicacions amb nom supera els 5.000, CAE deixa d'aplicar el canvi d'ubicació en temps real i torna a emetre un token d'una hora (encara que continua aplicant la resta d'esdeveniments i polítiques); i SharePoint Online, segons la mateixa pàgina, no admet els esdeveniments de risc d'usuari, que era justament la cinquena porta de la llista d'abans.

La defensa específica existeix. Mira on és.

Contra exactament aquest atac —reproduir un token robat des d'una altra màquina— Microsoft té un control que es diu Token Protection. La idea és bona i és la correcta: quan un usuari registra un dispositiu compatible, s'emet un Primary Refresh Token lligat criptogràficament a aquell dispositiu, de manera que encara que un atacant robi el token no el pot fer servir des d'un altre equip. Amb Token Protection actiu, Entra només accepta aquells tokens de sessió lligats al dispositiu.

Ara la part honesta, que surt de la mateixa pàgina de documentació, actualitzada l'agost del 2026. Token Protection està en disponibilitat general per a aplicacions natives a Windows, iOS/iPadOS i macOS, i els recursos on es pot exigir són Exchange Online, SharePoint Online i Teams (a Windows, a més, Azure Virtual Desktop i Windows 365). Per a aplicacions de navegador està en vista prèvia a Windows i macOS, i limitada a determinades aplicacions web que accedeixen a Azure Resource Manager, amb requisits addicionals de sistema operatiu, navegador i extensió. A iOS/iPadOS, el navegador directament no està suportat. I un matís que la mateixa pàgina deixa veure: l'apartat de dispositius compatibles titula el bloc d'Apple com a «vista prèvia» i exigeix macOS 14 o superior, o iOS 16 o superior, amb el complement Enterprise SSO de Microsoft i només en dispositius gestionats per MDM.

Posa aquelles dues frases al costat del que va passar. El robatori va ser al navegador. La defensa dissenyada exactament contra aquest atac està generalment disponible al lloc on el robatori no va passar, i en vista prèvia, amb llista d'aplicacions, al lloc on sí que va passar. No és una crítica a Microsoft, que a més recomana desplegar-ho en mode només informe abans d'exigir-ho: és la foto real de l'agost del 2026, i convé tenir-la al davant abans de prometre a ningú —o a un comitè— que això està resolt amb una casella. I aquella foto només cobreix les aplicacions del teu directori; el robatori de Claude, si la subscripció és personal, cau fora de l'enquadrament sencer.

Quants comptes d'IA hi ha a la teva empresa que tu no puguis tancar?

Aquesta és la pregunta que ens sembla que deixa el cas, i no va de Claude ni de cap fabricant en concret. Va de l'inventari. Fes-te aquestes quatre, amb paper:

• Aquelles subscripcions estan a nom de l'empresa i dins del teu directori, o les va pagar algú amb la seva targeta i el seu correu personal?
• Si demà has de tallar-li l'accés a aquella persona, tens el botó, o li ho has de demanar per favor?
• Si li roben la sessió, qui se n'assabenta, i per on? En aquest cas se'n va assabentar el proveïdor, i se'n va assabentar pel consum. Tu te'n vas assabentar perquè et van reenviar un correu.
• Què hi ha enganxat en aquell historial de converses? Un fragment de configuració, un log amb noms de servidor, una taula de preus, l'esborrany d'un contracte. Res d'això no és secret d'estat, i tot això ho enganxa gent normal perquè l'ajudin amb la seva feina.

Res d'això no és un atac a la IA a l'empresa. Nosaltres la fem servir i la muntem: part de la nostra pròpia automatització interna corre sobre n8n autoallotjat. I per això mateix ja vam escriure sobre el pilot d'IA que ningú no va apagar, que acaba en producció sense propietari perquè ningú no va decidir mai que ho fos. Això és exactament el mateix, però del compte en comptes del servidor: el que entra per la porta del darrere no s'inventaria, i el que no s'inventaria no es pot apagar.

A qui no li demana gairebé res

Ho diem encara que no ens convingui. Si les teves eines d'IA estan contractades a nom de l'empresa, entren per inici de sessió únic i els seus comptes viuen al teu directori, això és mitja hora de feina i no un projecte: revoques sessions de qui hagi pogut estar infectat, canvies contrasenya i li passes una anàlisi a l'equip. Ja està. No necessites comprar res ni trucar a ningú. Si a més tenies el correu d'Anthropic reenviat a IT en qüestió de minuts, el teu problema real d'avui és un altre i aquest article no va amb tu.

Si la teva gent fa servir comptes personals, no tens mitja hora de feina: tens una conversa pendent. I la conversa tampoc no s'arregla comprant res, perquè el problema no és tècnic. La gent no es treu una subscripció pel seu compte per saltar-se IT; se la treu perquè la necessita per treballar i perquè demanar-la pel canal oficial triga tres setmanes. Si prohibeixes sense donar alternativa, l'únic que aconsegueixes és que la propera vegada no t'ho expliquin.

Què faríem dilluns

• Preguntar qui ha rebut aquell correu, i preguntar-ho sense ànim d'enxampar ningú. La meitat del valor d'aquest exercici està en què la gent ho digui sense por. Si qui ho explica s'emporta una bronca, deixes d'assabentar-te'n a partir del segon.
• Tractar l'equip com l'incident, no el compte. Anàlisi completa abans de tornar a iniciar sessió, que és exactament l'ordre que recomana Anthropic i no és casualitat: si tornes a entrar en un equip que continua infectat, li regales la sessió nova.
• Revocar la sessió corporativa expressament, sense confiar que caduqui sola: «Revocar sessió» a la fitxa de l'usuari o Revoke-MgUserSignInSession. Canviar la contrasenya també serveix, perquè és un dels cinc esdeveniments crítics. Treure la persona d'un grup, no: això pot trigar un dia.
• Mirar què més vivia en aquell perfil de navegador, i no només Microsoft 365. El portal de la VPN, el panell del router, l'allotjament, el banc, l'eina de facturació. És una llista avorrida d'escriure i és la que de debò mesura l'abast.
• Escriure la llista d'eines d'IA que fa servir la teva gent, amb qui paga cadascuna. Aquesta no és urgent i és l'única que canvia alguna cosa el mes que ve.

Qui va donar l'avís

El que ens va cridar l'atenció d'aquest cas no és el malware. N'hi ha un cada setmana i la majoria de les famílies de la llista fa anys que funcionen. El que ens va cridar l'atenció és la cadena de qui s'assabenta de què. Un equip d'una empresa s'infecta. Un proveïdor d'intel·ligència artificial detecta un patró de despesa estrany. I l'avís aterra a la bústia personal d'un empleat, que decideix si el reenvia o no. En tota aquella cadena no hi apareix ni el departament d'IT de l'empresa ni cap eina seva.

Ens agradaria poder dir que això és estrany. No ho és. És el que passa quan una part de les eines que fa servir la teva gent es contracta sense passar per tu: el sensor deixa de ser teu i passa a ser la factura d'un altre. Anthropic va fer bé la seva part —va avisar, va revocar, va treure les targetes i va tornar els diners—, però Anthropic només podia veure el seu tros, i el seu tros era el consum del seu producte. L'equip infectat continua on era.

Fonts (consultades el 31 d'agost del 2026): el text de l'avís d'Anthropic, les frases citades entre cometes, les famílies de malware (Vidar, LummaC2, StealC, RedLine i Acreed a Windows; Atomic Stealer a macOS, en un nombre petit de casos), i les accions de la companyia —tancament de sessió, revocació de sessions compromeses, retirada dels mètodes de pagament desats, devolució dels càrrecs no autoritzats i continuïtat dels plans fins al final del període de facturació— provenen de la cobertura de BleepingComputer del 30 d'agost del 2026 i de la de Security Affairs del 31 d'agost, que reprodueixen el mateix correu. No hem rebut aquell correu: el que citem és el que aquelles dues publicacions reprodueixen, i ho diem perquè importa. Els cinc esdeveniments crítics, la vida per defecte del token d'accés d'una hora, els tokens de llarga durada de fins a vint-i-vuit hores en sessions CAE, la latència de fins a quinze minuts per propagació davant de l'aplicació instantània de les polítiques d'IP, el focus inicial en Exchange, Teams i SharePoint Online, el retard de fins a un dia en canvis de polítiques i de pertinença a grups (amb optimització a dues hores que no cobreix tots els escenaris), les dues maneres de revocar la sessió a l'instant, la manca de suport per a comptes de convidat, el llindar de 5.000 rangs IP en ubicacions amb nom (amb l'advertiment que CAE continua aplicant la resta d'esdeveniments i polítiques) i que SharePoint Online no admet els esdeveniments de risc d'usuari surten de «Continuous access evaluation in Microsoft Entra» (Microsoft Learn). El funcionament de Token Protection, el vincle criptogràfic del Primary Refresh Token amb el dispositiu, la disponibilitat general per a aplicacions natives a Windows, iOS/iPadOS i macOS, els recursos on es pot exigir, l'estat de vista prèvia per a aplicacions de navegador a Windows i macOS limitat a determinades aplicacions web que accedeixen a Azure Resource Manager, el «Not supported» del navegador a iOS/iPadOS, l'encapçalament «Apple (Preview)» de l'apartat de dispositius compatibles amb els seus requisits de macOS 14 o iOS 16, complement Enterprise SSO i gestió per MDM, i la recomanació de desplegar-ho en mode només informe surten de «How Token Protection Enhances Conditional Access Policies» (Microsoft Learn), pàgina actualitzada l'agost del 2026. Són nostres, i les marquem com a criteri i no com a fets publicats: la reclassificació de l'avís com a comunicat d'infecció d'un equip; la lectura que el sensor d'aquest cas va ser el consum i no la seguretat; la idea que Claude és el canari perquè el lladre gasta i per tant es nota, mentre que en altres sessions robades no hi ha comptador que es buidi; l'observació que «l'equip de l'usuari està infectat» no figura entre els cinc esdeveniments crítics i que aquell estat l'hi ha de dir algú a l'emissor de tokens; la contraposició entre on està generalment disponible Token Protection i on va passar el robatori; tot l'apartat de l'inventari de comptes d'IA i les seves quatre preguntes; el checklist de dilluns; l'observació que la majoria d'aquelles famílies de malware fa anys que circulen; i la lectura final sobre la cadena de qui s'assabenta de què. Anthropic afirma explícitament que el malware no guarda relació amb Claude i nosaltres no insinuem el contrari en cap punt de l'article.