Cambiare una password può non espellere chi possiede già un token di sessione valido. È il punto operativo emerso dal caso Chainalysis: il 4 novembre 2026 l’azienda ha comunicato che nomi, username, hash delle password e token attivi degli utenti erano stati esposti a un attore malevolo. Per una PMI, la lezione non riguarda il settore crypto. Riguarda ogni servizio SaaS collegato a WordPress, CRM, automazioni, contabilità o assistenza clienti.

Quando un fornitore segnala una compromissione, “abbiamo cambiato la password” non è una chiusura dell’incidente. Password, sessioni web, chiavi API, token OAuth e webhook sono credenziali diverse, con scadenze e procedure di revoca diverse. La risposta efficace parte da un inventario delle dipendenze, revoca ciò che può essere usato subito e ripristina i flussi uno alla volta, verificando i log.

Il caso Chainalysis, senza riempire i vuoti

Chainalysis ha pubblicato il primo avviso il 30 ottobre 2026. In quella versione dichiarava di non avere evidenze di accesso non autorizzato a credenziali di autenticazione o token di sessione. Il 4 novembre l’aggiornamento è cambiato: l’azienda ha riferito di aver scoperto l’esposizione di informazioni dei clienti, compresi hash delle password e token attivi per gli utenti Chainalysis. Nello stesso giorno ha rilevato attività anomala e ha portato offline l’interfaccia e l’API KYT, i prodotti di address screening e la pagina di login.

Un secondo elemento è l’attacco “on-path” descritto dall’azienda, che avrebbe esposto una parte delle password dei clienti. Chainalysis ha dichiarato di avere contenuto e corretto quel vettore, ma non ha pubblicato i dettagli tecnici necessari per attribuire un ruolo preciso alle tecniche agentiche citate nel primo avviso. È quindi scorretto trasformare l’incidente nella prova che “un agente AI ha violato Chainalysis”. Le informazioni pubbliche consentono di dire che l’azienda ha rilevato tecniche offensive assistite da agenti e, separatamente, un attacco on-path; non consentono di ricostruire la catena completa.

Il 6 novembre Chainalysis ha iniziato a ripristinare gradualmente KYT e Address Screening. Per riottenere l’accesso, i clienti dovevano fornire indirizzi IP affidabili per una allowlist e prepararsi a reimpostare le password e ruotare le chiavi API. L’azienda dichiarava inoltre di non avere evidenze di accesso ai dati delle indagini o di manipolazione dei dati di attribuzione. Questa precisazione conta: dati esposti, account usati senza autorizzazione e contenuti alterati sono impatti distinti. Un report serio li separa.

Perché password, sessione e API key non sono la stessa cosa

Una password serve a dimostrare l’identità durante l’autenticazione. Dopo il login, il servizio può emettere una sessione o un access token che rappresenta un’autenticazione già avvenuta. Un’API key, invece, identifica spesso un’integrazione software: un connettore tra CRM e newsletter, un job che legge dati, un plugin WordPress che invia ordini o un’automazione che pubblica contenuti.

Il cambio password agisce sulla password. Non bisogna presumere che annulli automaticamente tutte le sessioni, i refresh token o le chiavi API: il comportamento dipende dal fornitore. Per questo la domanda corretta non è “abbiamo cambiato la password?”, ma “quali credenziali concedevano accesso, quali sono state revocate dal server e quali dipendenze usavano quelle credenziali?”. Il NIST ha dedicato l’IR 8587 alla protezione di identity token, access token e assertion, mettendo al centro verifica, gestione del ciclo di vita e monitoraggio continuo.

La distinzione ha una conseguenza pratica. Se un token rubato resta valido, attivare l’MFA protegge i login futuri ma non garantisce da solo la chiusura di quella sessione. L’MFA resta necessaria, soprattutto per gli account amministrativi, ma deve accompagnare la revoca delle sessioni attive e la rotazione delle credenziali applicative. Anche una chiave appena sostituita è poco utile se la vecchia chiave rimane accettata dall’API.

Prima ora: contenere senza distruggere le prove

La prima ora non serve a scrivere il post-mortem. Serve a ridurre il tempo in cui una credenziale sottratta può ancora funzionare, senza cancellare i dati utili a capire cosa è successo. La checklist minima è questa:

  1. Nomina un responsabile. Una persona coordina decisioni, tempi e comunicazioni. Le attività tecniche possono essere distribuite, la regia no.
  2. Salva le evidenze disponibili. Esporta log di accesso, eventi amministrativi, indirizzi IP, user agent, modifiche a ruoli e integrazioni. Registra l’orario e il fuso.
  3. Revoca prima, ruota dopo. Chiudi le sessioni, revoca token e disabilita le chiavi sospette quando il servizio lo permette. Poi genera le sostitute. Creare una nuova chiave senza disattivare la precedente non contiene l’incidente.
  4. Riduci temporaneamente il perimetro. Sospendi job non essenziali, limita gli IP ammessi e abbassa i privilegi delle integrazioni che devono restare operative.
  5. Apri una timeline. Segna notifica del fornitore, prima evidenza interna, revoche eseguite, credenziali sostituite, test e riattivazioni.

Il playbook CISA indica, quando si sospetta una compromissione, la rotazione di chiavi private e segreti di account di servizio, la revoca degli accessi privilegiati e l’isolamento dei sistemi coinvolti. OWASP mette la revoca prima della rotazione nella risposta a un’esposizione di segreti. Non è una sfumatura terminologica: la revoca riduce l’accesso dell’attaccante; la rotazione consente ai flussi legittimi di ripartire.

Costruire l’inventario dal flusso, non dal vault

Molte piccole organizzazioni non hanno un inventario completo delle credenziali. In emergenza, guardare soltanto nel password manager o nel secrets manager produce una lista incompleta: mancano i token creati dentro i plugin, le connessioni OAuth autorizzate da un utente, i webhook configurati nei pannelli SaaS e le chiavi copiate anni prima in un job schedulato.

Conviene partire dai processi che generano valore. Per esempio: “un ordine WooCommerce entra nel gestionale”, “un modulo contatti crea una scheda nel CRM”, “una fattura aggiorna il foglio di controllo”, “un articolo viene distribuito sui social”. Per ogni flusso si annotano origine, destinazione, proprietario, credenziale, privilegi, luogo di conservazione e log disponibili. È un piccolo grafo delle dipendenze, più utile di un elenco alfabetico di password.

Assegna poi una priorità. In cima vanno le credenziali che permettono scrittura, esportazione massiva, gestione utenti, pagamenti o modifica delle configurazioni. Seguono le integrazioni in sola lettura con accesso a dati personali. In fondo restano i token limitati a dati pubblici o ambienti di test. La mia regola è semplice: si ruota prima ciò che può cambiare il sistema, poi ciò che può leggerlo. Il nome del fornitore conta meno del raggio d’azione della credenziale.

L’inventario deve includere anche le copie. Una chiave può essere presente nel pannello del provider, in una variabile d’ambiente, nella configurazione del plugin, nel sistema CI/CD e nel laptop di chi ha configurato il progetto. Non si tratta di copiare il valore del segreto nel foglio di risposta: si registra dove vive, chi lo usa e come revocarlo. Il valore rimane nel sistema destinato a proteggerlo.

Ruotare senza bloccare sito e automazioni

La rotazione d’emergenza non deve diventare un cambio simultaneo e non verificato di tutto lo stack. Per ogni integrazione, crea una finestra controllata: sospendi il job, revoca la vecchia credenziale, genera quella nuova con i privilegi minimi, aggiornala nel punto corretto e prova un’operazione innocua. Solo dopo riattiva il flusso.

Su WordPress questo significa evitare di incollare segreti in pagine, snippet o repository. Una Application Password compromessa va revocata dal profilo dell’utente che l’ha emessa e sostituita solo se l’integrazione è ancora necessaria. Verifica che l’utente abbia il ruolo minimo sufficiente e mantieni una mappa degli accessi e degli asset WordPress. Per i plugin che collegano servizi esterni, controlla sia la configurazione nel sito sia il pannello del fornitore: eliminare il token da WordPress non equivale sempre a revocarlo lato SaaS.

Per le API che supportano due credenziali contemporanee, una rotazione pianificata può usare una breve sovrapposizione. In un incidente confermato, però, mantenere valida la chiave sospetta per comodità prolunga l’esposizione. Se il servizio non consente un passaggio senza sovrapposizione, è preferibile accettare un’interruzione breve e misurata, comunicandola ai responsabili del processo.

Dopo ogni sostituzione, registra quattro prove: la vecchia credenziale viene rifiutata; la nuova esegue solo l’azione prevista; i log attribuiscono correttamente l’uso; gli errori e i retry non stanno duplicando ordini, email o record. Un HTTP 200 dimostra che una chiamata ha ricevuto risposta, non che l’intero processo sia tornato affidabile.

Verificare l’eradicazione prima del ritorno alla normalità

La fase di ripristino deve cercare segnali contrari, non soltanto conferme. Interroga i log per vedere se token revocati continuano a essere usati, se compaiono nuovi IP, se sono stati creati utenti o webhook, se sono cambiati ruoli e redirect URI OAuth. Controlla anche regole di inoltro, account tecnici e connessioni autorizzate: sono punti di persistenza meno visibili di una password.

Stabilisci un periodo di osservazione proporzionato al rischio e mantieni alert più sensibili sulle integrazioni coinvolte. CISA raccomanda di testare i sistemi e i controlli prima del rientro in produzione e di continuare a monitorare eventuali tentativi di rientro. OWASP suggerisce audit capaci di mostrare chi ha richiesto un segreto, quando è stato usato, aggiornato o revocato e se qualcuno ha tentato di riutilizzarlo dopo la scadenza.

Il ritorno alla normalità non coincide con la riaccensione dell’ultimo job. Si chiude quando esistono un perimetro documentato, credenziali vecchie non più valide, flussi essenziali testati e una decisione esplicita sul rischio residuo. Se il fornitore non chiarisce quali token siano stati esposti, tratta come compromesse le credenziali comprese nel perimetro dichiarato e documenta l’assunzione.

La preparazione che riduce il prossimo incidente

Il caso Chainalysis mostra anche un limite organizzativo: le valutazioni di un incidente cambiano. Il 30 ottobre non risultavano evidenze di esposizione delle credenziali; il 4 novembre il perimetro comunicato comprendeva hash e token attivi. Una PMI non può aspettare una ricostruzione definitiva prima di preparare revoca e rotazione. Deve poter aggiornare le decisioni quando arrivano nuove evidenze.

Tre interventi riducono davvero il lavoro della prossima volta. Primo: credenziali separate per servizio e ambiente, mai una chiave condivisa da più automazioni. Secondo: privilegi minimi e confini espliciti, con scadenze brevi dove disponibili. Terzo: una scheda per ogni integrazione con proprietario, dipendenze, procedura di revoca, test di salute e contatto del fornitore. OWASP raccomanda di conservare metadati sul ciclo di vita dei segreti e di automatizzare la rotazione quando possibile.

La take operativa è questa: la capacità di revocare conta più della frequenza con cui si promette di ruotare. Una chiave cambiata ogni novanta giorni ma senza proprietario, inventario o procedura di emergenza resta un rischio difficile da contenere. Un token breve, limitato e revocabile trasforma invece una compromissione da caccia al tesoro a sequenza verificabile.

Come chiusura, prepara oggi una tabella con cinque colonne: flusso, proprietario, tipo di credenziale, privilegi e procedura di revoca. Scegli l’integrazione con accesso più ampio e prova la rotazione in un ambiente controllato. Se non riesci a dimostrare che la vecchia credenziale è stata rifiutata, hai trovato il primo punto da correggere.

Fonti