Furto di sessione: perché cambiare la password non chiude l’accesso

Il furto di sessione permette di entrare in un account senza password e senza secondo fattore. L’attaccante non indovina le credenziali. Copia la prova che l’accesso è già avvenuto e la presenta al servizio al posto dell’utente.

Dopo l’autenticazione il servizio consegna al browser un cookie di sessione, oppure all’applicazione un token di accesso. Chi presenta quell’oggetto viene trattato come l’utente autenticato, finché il servizio non lo dichiara scaduto. L’articolo tratta solo questo oggetto. La catena completa dell’account takeover e il rilevamento con l’ITDR sono già trattati dalla testata.

Che cosa si ruba con il furto di sessione

Il NIST spiega nella linea guida SP 800-63B-4, pubblicata il 31 luglio 2025, che la continuità di una sessione autenticata si basa sul possesso di un segreto. Il servizio lo emette al momento dell’autenticazione. Tra gli esempi il NIST cita il cookie di una sessione nel browser.

Google scrive nel post del 9 aprile 2026 che i cookie hanno spesso una vita lunga. Chi li sottrae può quindi accedere agli account senza conoscere la password. Secondo Google, gli attori malevoli spesso raggruppano, scambiano o vendono questi accessi.

Il cookie di sessione

MITRE ATT&CK classifica il furto del cookie come tecnica T1539 (versione 1.5, modificata il 12 maggio 2026). Secondo MITRE, i cookie si trovano su disco, nella memoria dei processi del browser e nel traffico di rete. MITRE scrive che possono aggirare alcuni protocolli di autenticazione a più fattori.

Il riuso del cookie rubato è la tecnica T1550.004, che in gergo si chiama pass-the-cookie. Il nome compare nel titolo di uno scritto del ricercatore Johann Rehberger (dicembre 2018), che MITRE cita nella scheda T1539. MITRE riporta due casi. Nella campagna SolarWinds, il gruppo APT29 ha usato cookie rubati per accedere a risorse cloud e un cookie duo-sid falsificato per aggirare l’autenticazione a più fattori su un account di posta. Il gruppo Star Blizzard ha aggirato lo stesso controllo sugli account di posta delle vittime con cookie rubati tramite EvilGinx.

Token di accesso e refresh token

Nei servizi che usano OAuth 2.0 il cookie lascia il posto ai token. Il token di accesso autorizza le richieste verso un’API. Il refresh token serve a ottenerne di nuovi senza ripetere l’accesso. Microsoft indica che Entra ID emette token di accesso che durano un’ora per impostazione predefinita.

L’RFC 9700, la guida di sicurezza su OAuth 2.0 pubblicata dall’IETF a gennaio 2025, raccomanda di vincolare i token di accesso a chi li ha ricevuti. Per i client pubblici prescrive di vincolare i refresh token oppure di ruotarli a ogni uso.

Perché il secondo fattore non interviene

Il secondo fattore verifica l’utente al momento dell’accesso, mentre il cookie rubato nasce dopo. Microsoft lo documenta nell’analisi del 12 luglio 2022 su una campagna di phishing con intermediario (in inglese adversary-in-the-middle, AiTM). Secondo Microsoft, l’attaccante si autentica a nome dell’utente a prescindere dal metodo di accesso. In più casi i cookie contenevano già la dichiarazione dell’autenticazione a più fattori avvenuta.

Come avviene il furto di sessione

Le fonti consultate descrivono tre strade: il malware sul dispositivo, il proxy di phishing e le fughe dai sistemi di supporto.

Infostealer sul dispositivo

L’ACN ha pubblicato a gennaio 2026 il report «Infostealer: caratteristiche della minaccia e raccomandazioni», versione 1.0. Tra i dati che questi malware raccolgono dal browser, l’ACN elenca le credenziali salvate, la cronologia, i cookie e i token di sessione. Citando uno studio di Secureworks del 2023, l’ACN scrive che la fase di raccolta nella maggior parte dei casi non supera il minuto.

Nello stesso report l’ACN indica le famiglie che nel 2025 hanno esfiltrato più credenziali di soggetti italiani: LummaC2, RedLine Stealer, DcRat, StealC e Vidar Stealer, in ordine decrescente. L’ACN aggiunge che i log raccolti vengono per lo più venduti ad altri attori.

Google spiega nel post del 30 luglio 2024 che l’API DPAPI, usata da Chrome su Windows, non difende i cookie dalle applicazioni malevole eseguite con i privilegi dell’utente. Con Chrome 127 Google ha introdotto la cifratura legata all’applicazione, che un malware con privilegi elevati può comunque aggirare. Nel post del 9 aprile 2026 Google aggiunge che, con un malware sofisticato già sulla macchina, non esiste un modo affidabile di impedire l’esfiltrazione dei cookie con il solo software. La dichiarazione è di Google, che produce il browser.

Proxy di phishing

Nell’analisi del 12 luglio 2022 Microsoft descrive una campagna AiTM che dal settembre 2021 ha cercato di colpire oltre 10.000 organizzazioni. Il server proxy sta tra l’utente e il sito reale e mantiene due sessioni TLS, una con la vittima e una con il servizio legittimo. Così intercetta la password e il cookie di sessione. Tra i kit diffusi Microsoft cita Evilginx2, Modlishka e Muraena. Descrizione e cifre sono di Microsoft.

Sistemi di supporto e file di diagnostica

Il 3 novembre 2023 Okta ha pubblicato la causa dell’incidente al proprio sistema di supporto clienti. Secondo Okta, un attore ha avuto accesso ai file del sistema dal 28 settembre al 17 ottobre 2023. Alcuni erano file HAR, cioè registrazioni del traffico del browser, e contenevano token di sessione. L’attore li ha usati per dirottare le sessioni di cinque clienti. I clienti con file esposti erano 134, meno dell’1% del totale. Cronologia e cifre sono di Okta.

Tra le misure correttive Okta ha collegato i token di sessione degli amministratori alla rete: se rileva un cambio di rete, chiede una nuova autenticazione.

Il tempo tra il furto e l’uso

Il report dell’ACN descrive un caso del 2024 gestito dal CSIRT Italia. Un ente di ricerca fu colpito da ransomware dopo un accesso con l’account VPN di un dipendente, il cui portatile personale era stato infettato da un infostealer circa sei mesi prima. Il CSIRT Italia ipotizza che l’attore del ransomware, diverso da quello dell’infostealer, abbia acquisito le credenziali su un mercato criminale o con uno scambio privato. Il caso riguarda credenziali VPN, non un cookie di sessione, ma mostra che furto e uso possono essere separati da mesi e da attori diversi.

Perché cambiare la password non chiude l’accesso

La lettura è della redazione, coerente con la definizione del NIST: la password serve a ottenere una sessione, non a mantenerla. Quando l’accesso è già aperto, il servizio verifica il segreto di sessione e non ripete il controllo della password. La risposta a un furto di sessione passa quindi dalla revoca delle sessioni.

La revoca secondo Microsoft

La pagina di Microsoft sulla revoca dell’accesso in Entra ID (aggiornata a giugno 2026) indica queste azioni distinte:

• disabilitare l’account;
• revocare le sessioni, cioè i refresh token, con il pulsante Revoke sessions oppure con il comando Revoke-MgUserSignInSession;
• disabilitare i dispositivi registrati dell’utente;
• negli ambienti ibridi, reimpostare due volte la password in Active Directory, per ridurre il rischio di pass-the-hash.

La stessa pagina avverte che la revoca non è istantanea. Dopo la revoca l’utente non ottiene nuovi token. I token di accesso già emessi restano validi fino alla scadenza, di norma un’ora. Microsoft indica la valutazione continua dell’accesso (CAE, continuous access evaluation) come strumento per revocare anche i token di accesso delle applicazioni compatibili. Entra ID non può invece revocare i token di sessione emessi dalle singole applicazioni: deve farlo l’applicazione, con le proprie regole.

I controlli che legano la sessione al dispositivo

Questi controlli sostituiscono un segreto valido per chiunque lo presenti con uno che richiede la prova di possesso di una chiave. Se la chiave non lascia il dispositivo, il token copiato altrove non funziona. L’RFC 9700 raccomanda questa strada per i token OAuth e cita due meccanismi, il TLS reciproco e DPoP. Per i cookie del browser esiste DBSC. Microsoft ha un controllo proprio.

DPoP, il vincolo a livello applicativo

L’RFC 9449, pubblicato a settembre 2023, definisce DPoP (Demonstrating Proof of Possession). Il client genera una coppia di chiavi e firma ogni richiesta con un JWT, che invia nell’intestazione HTTP DPoP. La firma copre il metodo e l’indirizzo della richiesta, un orario, un identificatore univoco e un’impronta del token di accesso. Il server verifica che il token sia presentato da chi detiene la chiave. Secondo l’RFC, se la chiave privata non è esportabile, un token sottratto da solo diventa inutilizzabile.

TLS reciproco e token legati al certificato

L’RFC 8705, del febbraio 2020, lega il token al certificato del client. Il server di autorizzazione inserisce nel token l’impronta SHA-256 del certificato, in un campo chiamato cnf. Il server delle risorse accetta il token solo se la richiesta arriva con lo stesso certificato su una connessione di TLS reciproco. Tra i limiti, l’RFC indica che il rinnovo del certificato obbliga il client a ottenere nuovi token.

DBSC, il vincolo nel browser

DBSC (Device Bound Session Credentials) applica lo stesso principio ai cookie. Google l’ha reso disponibile il 9 aprile 2026 agli utenti Windows di Chrome 146 e ha annunciato l’estensione a macOS in una versione successiva. Il browser genera una coppia di chiavi in un modulo hardware, il TPM su Windows e il Secure Enclave su macOS, e la chiave privata non può lasciare la macchina. Chrome ottiene un nuovo cookie di sessione, a vita breve, solo dopo aver dimostrato al server di possedere quella chiave. Un cookie rubato scade presto e non si rinnova.

Il sito deve aggiungere due punti di accesso lato server, uno di registrazione e uno di rinnovo, senza modificare l’interfaccia. Google dichiara di aver osservato una riduzione significativa dei furti di sessione per le sessioni protette, senza fornire cifre. Un aggiornamento di Workspace del 28 maggio 2026 dichiara DBSC attivo per impostazione predefinita per gli utenti Workspace su Chrome per Windows, senza un controllo amministrativo per disattivarlo.

Sulla maturità della specifica le fonti dicono due cose. La specifica del W3C è, nella versione consultata, la prima bozza pubblica di lavoro del 21 agosto 2025; il documento stesso la definisce una stesura molto iniziale e i suoi editori lavorano per Google. Il NIST cita DBSC come specifica emergente nella SP 800-63B-4, e resta fermo che i limiti di durata della sessione valgono anche con la prova di possesso.

Protezione dei token di Microsoft Entra

Microsoft offre in Accesso condizionale un controllo di sessione, la protezione dei token (token protection). Per le applicazioni supportate, Entra ID accetta solo token di sessione legati al dispositivo, come i Primary Refresh Token. Secondo Microsoft, un token rubato non può essere usato da un altro dispositivo.

La pagina, aggiornata il 20 agosto 2026, elenca le applicazioni native supportate: Exchange Online, SharePoint Online e Teams, su Windows, macOS e iOS. Il supporto per le applicazioni nel browser è in anteprima e limitato ad Azure Resource Manager; su iOS manca. Sulle piattaforme Apple le due versioni della pagina divergono. La versione inglese indica nella tabella la disponibilità generale per le app native e «Apple (Preview)» nella sezione dei dispositivi. La versione italiana, aggiornata il 14 agosto 2026, indica l’anteprima in entrambi i punti. Microsoft non spiega la differenza, quindi lo stato va controllato prima di pianificare l’adozione. Microsoft suggerisce di partire da un gruppo pilota e dalla modalità solo report.

Durata della sessione e riautenticazione

Accorciare la vita della sessione è il controllo più semplice. Il NIST chiede una riautenticazione periodica e distingue due limiti: la durata massima complessiva e l’inattività. MITRE elenca tra le mitigazioni la cancellazione periodica dei cookie persistenti e la riduzione della loro validità. Così l’attaccante deve ripetere il furto e i difensori hanno più occasioni di rilevarlo. Entro la finestra residua il cookie rubato resta però utilizzabile.

Dove i controlli si fermano

Limiti dichiarati dalle fonti

L’RFC 9449 riconosce che chi controlla il client può creare prove DPoP in anticipo, anche con un orario futuro. In quel caso la protezione dipende dai nonce forniti dal server. Se un attaccante esegue codice nel contesto del client, può creare nuove prove finché il client è in linea. DPoP non garantisce l’integrità del corpo e della maggior parte delle intestazioni, quindi non sostituisce un trasporto sicuro.

La specifica del W3C è altrettanto netta. DBSC non impedisce l’accesso temporaneo alla sessione mentre l’attaccante è sul dispositivo: il malware non può esportare la chiave, ma può usarla per firmare come farebbe l’utente. Se l’attaccante sostituisce o altera il browser al momento della registrazione, può legare la sessione a chiavi non protette dal TPM oppure a un TPM che controlla. La documentazione di Chrome definisce questi attacchi molto più complessi e più rilevabili di quelli standard, non impossibili.

Letture della redazione

Le letture che seguono sono della redazione: nessuna fonte le sostiene in questa forma.

1. Il legame sposta il bersaglio. Con la chiave non esportabile, il malware non copia più il cookie e deve restare sul dispositivo. L’obiezione: costa di più all’attaccante, ma non gli è impossibile, e vale solo finché la chiave sta nel TPM.
2. Il vincolo protegge la sessione, non la decisione di aprirla. Se un attaccante accede con credenziali valide da un dispositivo che controlla, la sessione nasce già legata al suo dispositivo. L’obiezione: nessuna fonte consultata affronta questo caso, e il vincolo resta utile contro il riuso su altri dispositivi.
3. La copertura è disomogenea. Servono browser, sito e fornitore di identità allineati. Google dichiara Windows su Chrome e macOS in arrivo, mentre Microsoft limita il browser ad Azure Resource Manager. L’obiezione: i fornitori dichiarano di voler estendere il supporto.

Il furto di sessione negli obblighi NIS2 e nelle misure ACN

L’articolo 21 della direttiva NIS2 elenca tra le misure minime l’uso di soluzioni di autenticazione a più fattori o di autenticazione continua. Il d.lgs. 138/2024 lo ripete all’articolo 24, comma 2, lettera l).

Le misure di base dell’ACN, nell’Allegato 1 per i soggetti importanti, declinano l’obbligo nella misura PR.AA-03. Le modalità di autenticazione devono essere commisurate al rischio, con la valutazione almeno dei privilegi delle utenze, della criticità dei sistemi e delle operazioni consentite. Per i sistemi rilevanti sono impiegate soluzioni di autenticazione multifattore.

Misure da avviare

Le misure sono tratte dalle fonti citate sopra; l’ordine è della redazione:

• tenere pronta e provata la procedura di revoca, con account, sessioni, dispositivi e sessioni delle singole applicazioni (Microsoft);
• usare un’autenticazione a più fattori resistente al phishing, contro i proxy AiTM (Microsoft, MITRE M1032);
• accorciare la durata delle sessioni e imporre la riautenticazione periodica (NIST, MITRE M1054);
• attivare i controlli che legano la sessione al dispositivo dove il fornitore li offre, partendo dalla modalità solo report (Microsoft, Google);
• limitare le estensioni del browser (MITRE M1021), vettore trattato nell’articolo sulle estensioni malevole del browser;
• cercare cookie o token usati da posizioni o client insoliti, senza una nuova autenticazione (MITRE DET0509).

Conclusione: il furto di sessione si risolve sulla sessione

Il furto di sessione copia un permesso già concesso. Per questo la password cambia poco e il secondo fattore non interviene. La risposta passa dalla revoca delle sessioni e dal legame con il dispositivo.

Gli strumenti hanno date precise: token legati al certificato dal 2020, DPoP dal 2023, DBSC dal 2026 su Chrome per Windows. Nessuno ferma un malware attivo sul dispositivo. Servono a ridurre il valore di un cookie o di un token rubato, non a impedirne il furto.

Domande frequenti

Che cos'è il furto di sessione e come funziona?

Il furto di sessione è la copia di un cookie o di un token già emesso dopo l'accesso. L'attaccante lo presenta al servizio e viene trattato come l'utente, senza password e senza secondo fattore, finché la sessione non scade.

Il furto di sessione aggira l'autenticazione a più fattori?

Sì, può aggirarla. Il secondo fattore verifica l'utente al momento dell'accesso, mentre il cookie rubato nasce dopo. Microsoft e MITRE descrivono cookie rubati che aggirano il controllo, anche perché contenevano già la dichiarazione di autenticazione avvenuta.

Cambiare la password blocca chi ha rubato il cookie di sessione?

Non basta. Microsoft indica di disabilitare l'account, revocare le sessioni e disabilitare i dispositivi. I token di accesso già emessi durano in genere un'ora e le sessioni delle applicazioni vanno chiuse dall'applicazione.

Che cos'è DBSC e protegge davvero i cookie di sessione?

DBSC lega la sessione a una chiave non esportabile del dispositivo, che il browser deve provare di possedere per ottenere nuovi cookie. Google l'ha reso disponibile in Chrome 146 su Windows. Non ferma un malware attivo sul dispositivo, che può usare la chiave per firmare.

Cosa dicono la NIS2 e le misure ACN sull'autenticazione continua?

L'articolo 21 della NIS2 cita l'autenticazione a più fattori o continua. La misura ACN PR.AA-03 chiede un'autenticazione commisurata al rischio e il secondo fattore sui sistemi rilevanti; l'Allegato 1 non nomina sessioni o token.