Le password e l'autenticazione a più fattori proteggono il processo di accesso. Non proteggono necessariamente una sessione del browser autenticata dopo il completamento dell'accesso. Questa distinzione è diventata importante per gli account AI perché una sessione attiva può includere accesso all'uso a pagamento dei modelli, alle conversazioni, ai materiali caricati, ai flussi di lavoro connessi e ad altre capacità concesse all'account.
Anthropic ha recentemente avvertito alcuni utenti di Claude che comuni malware infostealer avevano copiato sessioni di accesso attive da computer infetti. Secondo la cronaca di BleepingComputer, gli aggressori hanno riutilizzato tali sessioni per entrare negli account e consumare l'utilizzo disponibile. Anthropic ha risposto revocando le sessioni interessate, disconnettendo gli utenti, rimuovendo i metodi di pagamento salvati e rimborsando gli addebiti identificati come non autorizzati. L'azienda ha affermato di non avere motivo di ritenere che il malware provenisse da Claude o fosse il risultato dell'uso del servizio.
Non è stato descritto come un attaccante che craccava password o superava una verifica MFA. Dopo che l'utente si è autenticato con successo, il browser riceve normalmente un cookie o un token. Il browser presenta quell'artefatto nelle richieste successive affinché l'utente non debba inserire una password e completare MFA in ogni pagina. Se il malware estrae l'artefatto e un servizio lo accetta da un altro ambiente, l'attaccante può ereditare uno stato già autenticato.
MITRE ATT&CK classifica questo comportamento come uso di un cookie di sessione web rubato. La descrizione spiega che un avversario può importare un cookie rubato in un browser controllato e usare l'applicazione come la vittima mentre la sessione resta attiva. La tecnica può aggirare alcuni protocolli MFA perché la sessione sottostante ha già superato l'autenticazione. Microsoft descrive il modello comparabile come “pass-the-cookie”: il malware estrae i cookie del browser e un attaccante li inserisce in un altro browser per superare i controlli che si applicherebbero durante un nuovo accesso.
È quindi più preciso dire che il furto di sessione può aggirare la necessità di una nuova password e di una verifica MFA. Non prova che la password sia stata recuperata, che il secondo fattore sia stato violato crittograficamente o che MFA non abbia valore. MFA blocca ancora molti attacchi basati soltanto su credenziali rubate. Il problema è che un artefatto di sessione riutilizzabile si trova a valle di tali protezioni e può funzionare temporaneamente come credenziale a sé stante.
La prima risposta dovrebbe essere il contenimento da un dispositivo diverso e affidabile. Apri i controlli di gestione delle sessioni del servizio AI e termina le sessioni sconosciute. Se il servizio offre un'opzione di disconnessione globale, usala quando l'ambito è incerto. La pagina delle sessioni attive di Anthropic consente agli utenti Claude di esaminare dispositivi e browser connessi e di terminare da remoto le sessioni che non riconoscono. Questa azione colpisce direttamente lo stato di autenticazione rubato; cambiare soltanto la password potrebbe non invalidare subito ogni sessione esistente in ogni servizio.
Poi proteggi il percorso di recupero. Esamina l'account e-mail principale, le relative sessioni attive, gli indirizzi di recupero, i numeri telefonici di recupero e i metodi di autenticazione. L'e-mail spesso controlla la reimpostazione delle password per altri servizi, perciò un attaccante che ne conserva l'accesso può annullare il lavoro di recupero successivo. Rimuovi dove opportuno l'accesso ai pagamenti salvato, verifica acquisti o consumi inspiegati e segnala l'attività non autorizzata tramite la procedura di assistenza ufficiale del fornitore.
Indaga quindi il computer interessato prima di crearvi sessioni sostitutive. L'avviso di Anthropic ha sottolineato che disconnettere un utente interrompe la sessione rubata ma non rimuove il malware. Se l'infostealer resta attivo, effettuare di nuovo l'accesso gli fornisce semplicemente una nuova sessione da copiare. Usa strumenti affidabili di sicurezza degli endpoint e segui la procedura di risposta agli incidenti del proprietario del dispositivo o dell'organizzazione. Quando la fiducia nella bonifica è bassa, ricostruire il dispositivo da una fonte attendibile può offrire un confine di recupero più chiaro che effettuare ripetutamente l'accesso e la scansione.
Solo dopo aver spostato il recupero dell'account in un ambiente affidabile e aver affrontato l'endpoint, gli utenti dovrebbero reimpostare le credenziali esposte e creare nuove sessioni. Le password archiviate nel browser o immesse mentre il malware era attivo meritano una revisione che va oltre l'account AI. Gli infostealer generalisti sono progettati per raccogliere più tipi di informazioni disponibili localmente; un avviso Claude va quindi trattato come evidenza di una compromissione più ampia del dispositivo e non come un problema isolato nell'uso del modello.
I team dovrebbero ampliare tale revisione in base a ciò a cui la persona interessata poteva accedere. L'ambiente di uno sviluppatore può contenere credenziali di repository, accesso al cloud, token di registri di pacchetti, chiavi API e sessioni di lavoro. L'incidente Claude riportato riguardava sessioni di accesso nel browser; non ha stabilito una compromissione di chiavi API Anthropic, console per sviluppatori, provider di identità aziendale o di ogni altra credenziale su una macchina infetta. Esaminare queste risorse è una precauzione giustificata dalla natura del malware generalista che ruba informazioni, non la prova che ogni risorsa sia stata sottratta.
Dopo il contenimento, conserva e ispeziona le prove fornite dai sistemi disponibili. I record utili includono cronologia delle sessioni, notifiche di sicurezza, variazioni di consumo, acquisti, rilevamenti endpoint, eventi del provider di identità e log di audit amministrativi. Microsoft raccomanda di esaminare gli account compromessi per individuare persistenza e modifiche sospette dopo il furto di token. Le verifiche esatte dipendono dall'applicazione, ma il principio è duraturo: revocare l'artefatto interrompe un percorso di accesso, mentre l'indagine determina se l'attaccante ne ha creato un altro.
Il rapporto pubblico su Claude sostiene un insieme limitato di conclusioni. I computer di alcuni utenti erano infetti da infostealer comuni; sessioni Claude attive sono state raccolte e abusate; e Anthropic ha applicato una correzione relativa a account e pagamenti. Il rapporto ha identificato diverse famiglie di malware Windows e un numero minore di casi Mac. Ha inoltre descritto l'esaurimento inatteso dell'utilizzo come un sintomo che alcuni utenti interessati potevano osservare.
Il rapporto non divulga il numero totale di utenti interessati, la finestra completa dell'abuso, l'utilizzo non autorizzato complessivo o il metodo di rilevamento dell'indagine. Non stabilisce che i sistemi centrali, i modelli o il database degli account di Anthropic siano stati violati. Né prova che gli attaccanti abbiano letto cronologie di conversazione, aperto file caricati, usato connettori o cambiato impostazioni dell'account. Una sessione valida può offrire capacità disponibili al suo utente, ma possibile accesso e attività dell'attaccante dimostrata non sono la stessa affermazione.
Questa prudenza conta per le decisioni di sicurezza. Minimizzare l'evento come semplice riuso di password produrrebbe l'ordine di recupero sbagliato. Esagerarlo come violazione della piattaforma identificherebbe erroneamente il punto di ingresso riportato. L'interpretazione difendibile è che il malware sull'endpoint ha corrotto la fiducia rappresentata dallo stato autenticato del browser e che il conseguente abuso è diventato visibile nel servizio AI.
Per acquirenti e amministratori, la visibilità delle sessioni è il primo controllo di prodotto da valutare. Gli utenti possono vedere dispositivi e browser attivi, località approssimative e attività recente? Possono terminare una sessione senza interrompere ogni dispositivo? Esiste anche una disconnessione globale affidabile per gli incidenti incerti? Gli amministratori possono revocare centralmente le sessioni e l'effetto è immediato su web, desktop, dispositivi mobili ed esperienze connesse?
La semantica della revoca merita un esame particolare. Microsoft osserva che revocare un refresh token non invalida necessariamente subito un access token già emesso; l'accesso può persistere fino alla scadenza di quel token, salvo che la piattaforma supporti un'applicazione più rapida. I fornitori AI non devono usare l'architettura Microsoft per affrontare la stessa domanda di valutazione: dopo che un utente o amministratore preme “disconnetti”, quali artefatti di autenticazione smettono di funzionare, su quali superfici e con quale rapidità?
La durata della sessione è un altro compromesso da esaminare. Artefatti di durata più breve riducono il periodo in cui un token copiato è utile, ma impongono più riautenticazioni e possono interrompere lavori di lunga durata. La riautenticazione basata sul rischio può offrire un confine più selettivo, richiedendo una verifica per azioni sensibili, ambienti insoliti o operazioni con privilegi elevati. I clienti dovrebbero chiedere quali eventi attivano un nuovo controllo di autenticazione e se le modifiche ai pagamenti salvati o altre azioni consequenziali ricevono ulteriore protezione.
Rilevamento e notifica determinano quanto presto possano operare i controlli reattivi. Capacità utili includono avvisi per sessioni sconosciute, località insolite, consumo anomalo e cambiamenti nelle impostazioni di sicurezza. Nessuna è conclusiva da sola: gli utenti legittimi viaggiano, cambiano rete, passano da un browser all'altro e variano l'uso dell'AI. I prodotti dovrebbero combinare segnali, conservare una cronologia di audit utile e offrire agli utenti abbastanza contesto per distinguere l'attività ordinaria da una sessione da revocare.
Le politiche per dispositivi gestiti possono ridurre l'esposizione degli account organizzativi. Microsoft raccomanda visibilità su dove gli utenti si autenticano, controlli di conformità dei dispositivi per applicazioni importanti e controlli di sessione compensativi per dispositivi non gestiti. I team che valutano servizi AI dovrebbero determinare se i piani aziendali possano limitare l'accesso ai dispositivi noti, integrarsi con i controlli di identità esistenti, separare l'amministrazione privilegiata dall'uso ordinario e supportare un contenimento rapido senza attendere la risposta di ogni dipendente.
Le sessioni legate al dispositivo offrono una difesa più diretta contro il replay di cookie esportati. Il design Device Bound Session Credentials di Google usa una chiave privata non esportabile, supportata da hardware, e cookie di breve durata. Il browser deve dimostrare ripetutamente il possesso della chiave corrispondente prima che il server emetta nuovi cookie di sessione. Un cookie copiato su un'altra macchina dovrebbe quindi scadere rapidamente senza la chiave detenuta dal dispositivo. Google ha annunciato la disponibilità pubblica per gli utenti Windows in Chrome 146 e ha dichiarato che il supporto macOS sarebbe seguito in una versione successiva.
Questa protezione non è né automatica né assoluta. Un servizio deve implementare gli endpoint richiesti per registrazione e aggiornamento, e il solo supporto del browser non dimostra che un particolare prodotto AI usi DBSC. Il legame al dispositivo è progettato per ostacolare il replay remoto di cookie esportati; non rende affidabile un computer infetto. Il malware in esecuzione sul dispositivo può ancora rubare altre informazioni o agire tramite l'ambiente compromesso. Recupero, uso su più dispositivi, hardware non supportato e identità federata pongono inoltre questioni di distribuzione che gli acquirenti dovrebbero chiedere ai fornitori di spiegare.
La postura di prodotto più forte combina livelli: protezione dell'endpoint per ridurre il furto, sessioni visibili e revocabili per contenerlo, finestre di autenticazione più brevi o sensibili al rischio per limitarne l'utilità, rilevamento per identificare gli abusi e legame al dispositivo per rendere più difficile riprodurre gli artefatti esportati. Procedure di assistenza chiare e rimedio della fatturazione riducono il danno dopo il fallimento dei controlli, ma dovrebbero integrare il design preventivo anziché sostituirlo.
Per gli utenti AI, la regola pratica è semplice: un aumento inatteso dell'utilizzo o un avviso di sessione può essere un incidente di endpoint anche se password e metodo MFA sembrano invariati. Revoca l'accesso da un dispositivo pulito, proteggi gli account di recupero, indaga l'endpoint, ruota le credenziali esposte e solo allora crea nuove sessioni affidabili. Per i team, la lezione duratura è più ampia: valuta lo stato della sessione autenticata con la stessa serietà riservata a password, chiavi API e altre credenziali, perché gli attaccanti lo fanno già.
Uniamo fonti primarie, documentazione dei prodotti e scenari d'uso reali per aiutarti a capire se uno strumento è adatto al tuo flusso di lavoro.