Cyberpediadi Brain
ITDEENESFR

Furto di cookie di sessione e token bearer

Un cookie di sessione rubato consente di spacciarsi per un dipendente senza password né secondo fattore. Meccanismo, caso reale e riflessi.

In 30 secondi

Dove succede
Sulla postazione di lavoro (malware), su un sito falso che inoltra la vera pagina di accesso1, oppure in un browser compromesso8.
Che cosa vuole l'attaccante
Riprendere una sessione già aperta, leggere i messaggi e agire a nome della vittima, aggirando alcuni secondi fattori2.
Il riflesso
Uscire dai servizi quando si ha finito, revocare le proprie sessioni in caso di dubbio, chiudere regolarmente le sessioni del browser.
Se è già successo
Avvisare subito il supporto informatico, perché la sessione rubata resta utilizzabile finché è attiva2.

Di cosa si tratta

Quando un dipendente accede alla posta elettronica o a uno strumento online, il servizio gli consegna un piccolo elemento di identificazione, il più delle volte un cookie, che dimostra che è già autenticato. Se un attaccante si impossessa di questo elemento, può entrare al posto della vittima senza conoscerne la password1.

Per il dipendente, di solito non si vede nulla: la sessione prosegue, e con essa il lavoro. Questa scheda spiega da dove nasce il furto, che uso ne fa un attaccante e che cosa può fare ciascuno per ridurre il rischio.

Domande dirette

Che cos'è un cookie di sessione?

Dopo un accesso riuscito, molte applicazioni web usano un cookie di sessione come prova di autenticazione1. Il protocollo web, di per sé, non ricorda chi è chi da una richiesta all'altra: il server invia quindi al browser un token, che il browser presenta a ogni scambio successivo3.

Che cos'è un token di accesso e in che cosa differisce dal cookie?

Un token di accesso serve a fare richieste autorizzate a nome di un utente o di un servizio. È comune nelle applicazioni online (SaaS) e nei servizi cloud4. I due oggetti hanno la stessa debolezza: chi li presenta viene accettato come la persona che li ha ottenuti. La SP 800-63B del NIST, versione sostituita dal 1° agosto 2025 dalla SP 800-63-4, precisava inoltre che la presenza di un token di accesso OAuth non deve essere interpretata come la presenza dell'utente in assenza di altri segnali, e che un token di questo tipo può restare valido a lungo dopo la fine della sessione di autenticazione5.

Il mio secondo fattore non mi protegge?

Protegge l'accesso, non la sessione che segue. MITRE indica che questa tecnica aggira alcuni protocolli di autenticazione a più fattori, poiché la sessione è già autenticata2. Microsoft precisa che non si tratta di una falla dell'autenticazione a più fattori: il cookie rubato autentica l'attaccante qualunque sia il metodo di accesso dell'utente6.

Per quanto tempo un cookie rubato resta utilizzabile?

I cookie restano spesso validi a lungo, anche se l'applicazione non viene usata attivamente1. L'attaccante può servirsene finché il cookie è attivo2. L'OWASP osserva inoltre che un timeout di inattività non limita un attaccante che ha preso la sessione: può generare attività per mantenerla aperta7.

1Nei panni dell'attaccante1 min

L'attaccante cerca un elemento riutilizzabile, non un segreto da indovinare. I cookie si trovano sul disco, nella memoria del browser e nel traffico di rete verso sistemi remoti. Anche altre applicazioni della postazione possono tenere in memoria cookie di autenticazione, per esempio quelle che si collegano a servizi cloud1.

Ottenuto il cookie, l'attaccante lo importa in un browser che controlla. Usa allora il sito come l'utente, finché la sessione è attiva. Può consultare informazioni sensibili, leggere e-mail o fare ciò che l'account della vittima è autorizzato a fare2.

Per il token di accesso, una via descritta è il phishing: l'attaccante registra un'applicazione trappola e invia un link per indurre la vittima a concederle l'accesso. Una volta concesso il token, l'applicazione può ottenere un accesso potenzialmente duraturo all'account4. I token di accesso hanno talvolta una durata limitata, ma l'attaccante può anche rubare un token di aggiornamento, che gli fornisce nuovi token di accesso senza chiedere nulla all'utente4.

2Cosa si vede sullo schermo1 min

Il dipendente non vede nulla: possono esistere avvisi lato amministratore (vedere più avanti). Nel caso di un sito falso che fa da relay (descritto più avanti), la pagina è identica alla vera: l'unica differenza visibile è l'indirizzo6. Dopo l'inserimento della password, la vittima viene reindirizzata alla pagina legittima e l'attacco prosegue in secondo piano6.

Ecco un'illustrazione neutralizzata dell'indirizzo di un sito falso che fa da relay. È inventata per l'esempio.

Estratto
Illustrazione (indirizzo fittizio, neutralizzato):
hxxps://login[.]exemple-connexion[.]invalid/
[pagina identica alla vera pagina di accesso, cambia solo l'indirizzo]

Esistono alcuni segnali indiretti. Se l'attaccante accede mentre la vittima sta lavorando, lato amministratore possono comparire avvisi di «spostamento impossibile»6. Regole sconosciute nella posta in arrivo sono un altro segnale: nel caso descritto più avanti, l'attaccante ne ha creata una perché la vittima non vedesse le risposte del suo bersaglio6.

3Sotto il cofanoTeam IT2 min

Le fonti citate qui descrivono tre vie di furto.

  • Il malware ladro: software dannosi prendono di mira i cookie dei browser presenti sulla postazione1. Alcuni estraggono il cookie di sessione e lo inviano al server dell'attaccante1.
  • Il sito falso che fa da relay: nell'attacco detto dell'intermediario (adversary-in-the-middle), l'attaccante colloca un server proxy tra l'utente e il sito preso di mira. In questo modo cattura la password e il cookie di sessione6. Strumenti liberi come Evilginx2, Modlishka e Muraena automatizzano questo procedimento6.
  • Il browser compromesso: un attaccante può iniettare software in un browser per ereditare i cookie, le sessioni HTTP e i certificati client dell'utente, e usarli poi per entrare in una intranet autenticata8. Questa tecnica può aggirare anche l'autenticazione a due fattori8. Può richiedere privilegi particolari sulla postazione8.

Perché il replay funziona? Il cookie è la prova dell'accesso: il server non riverifica la password a ogni pagina6. La SP 800-63B del NIST ammette altri metodi per identificare in modo sicuro il dispositivo, tra cui il TLS reciproco e il token binding5. L'OWASP raccomanda di legare l'identificativo di sessione ad altre proprietà del client, come l'indirizzo IP o lo User-Agent. Riconosce tuttavia che un attaccante abile può aggirare questo controllo, per esempio condividendo la stessa rete della vittima o copiando lo User-Agent7.

Quanto alle durate, l'OWASP cita timeout di inattività comuni da 2 a 5 minuti per le applicazioni di alto valore e da 15 a 30 minuti per quelle a basso rischio. Per un impiegato che usa un'applicazione tutto il giorno, cita un timeout assoluto da 4 a 8 ore7. La SP 800-63B del NIST, sostituita dal 1° agosto 2025 dalla SP 800-63-4, richiedeva che i segreti di sessione venissero cancellati o invalidati alla disconnessione5.

4AutopsieCasi reali2 min

Campagna di phishing con sito relay contro Microsoft 365 (documentata il 12 luglio 2022)

Il 12 luglio 2022 Microsoft pubblica l'analisi di una campagna su larga scala. Secondo i suoi dati, ha tentato di colpire più di 10.000 organizzazioni a partire da settembre 20216. Gli attaccanti hanno usato siti relay per rubare le password e dirottare la sessione della vittima, anche con l'autenticazione a più fattori attivata6.

In una delle ondate osservate, un'e-mail con un allegato HTML annunciava un messaggio vocale. L'allegato mostrava una falsa barra di download, poi reindirizzava a un sito relay costruito con Evilginx2, che riproduceva la pagina di accesso dell'organizzazione6. La vittima inseriva le credenziali, veniva reindirizzata alla pagina legittima office.com, e l'attaccante risultava autenticato a suo nome6.

Il seguito mirava alla frode sui pagamenti. Secondo Microsoft, a volte sono bastati cinque minuti tra il furto e l'inizio della frode. L'attaccante usava il cookie rubato per entrare nella posta online, talvolta con un cookie che portava già l'indicazione di autenticazione a più fattori6. Cercava poi scambi legati ai pagamenti, eliminava l'e-mail di phishing iniziale e creava una regola della posta in arrivo che archiviava e segnava come lette le risposte del suo bersaglio, perché la vittima non notasse nulla6. Infine eliminava le proprie risposte dalle cartelle della posta inviata e degli elementi eliminati6.

Microsoft raccomanda autenticazioni resistenti al phishing (FIDO 2.0 o certificati) e politiche di accesso condizionale, che valutano ogni tentativo di uso di un cookie rubato6.

5Cosa fare1 min

Questi gesti derivano dalle fonti citate qui. Il loro effetto è ridurre la durata o la portata di una sessione rubata, non garantire che non venga rubata.

  • Uscire esplicitamente dai servizi quando si ha finito. L'OWASP indica che la chiusura del browser non forza in modo affidabile la disconnessione e consiglia una disconnessione esplicita, con timeout lato server7.
  • Revocare le proprie sessioni se sorge un dubbio (postazione infetta, pagina di accesso sospetta). Le fonti citate qui non dettagliano la procedura: la indica il supporto informatico dell'azienda.
  • Chiudere regolarmente le sessioni aperte nel browser. MITRE raccomanda di chiudere regolarmente tutte le sessioni del browser8.
  • Controllare l'indirizzo prima di inserire la password: l'indirizzo è l'unica differenza visibile tra un sito relay falso e quello vero6.
  • Segnalare ogni dubbio al supporto informatico, senza attendere: finché la sessione è attiva, l'attaccante può usarla2.

Sul versante aziendale, MITRE cita la configurazione dei browser per eliminare regolarmente i cookie persistenti2.

Scheda

Identificativo
CP-048
Ala
1. Attacchi e tecniche
Competenza Brain
Gestire le password (master_passwords)
Riflesso Brain
cr-023
Schema
G3 · Sezione anatomica
Lingue
de, en, es, fr, it
Fonti
8 fonti verificate il 3 novembre 2026
Fonti8 fonti
  1. MITRE ATT&CK, «Steal Web Session Cookie». https://attack.mitre.org/techniques/T1539/ (consultato il 3 novembre 2026)
  2. MITRE ATT&CK, «Use Alternate Authentication Material: Web Session Cookie». https://attack.mitre.org/techniques/T1550/004/ (consultato il 3 novembre 2026)
  3. OWASP, «Session hijacking attack». https://community.owasp.org/attacks/Session_hijacking_attack (consultato il 3 novembre 2026)
  4. MITRE ATT&CK, «Steal Application Access Token». https://attack.mitre.org/techniques/T1528/ (consultato il 3 novembre 2026)
  5. NIST, «NIST Special Publication 800-63B». https://pages.nist.gov/800-63-3/sp800-63b.html (consultato il 3 novembre 2026)
  6. Microsoft, «From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud», 12 luglio 2022. https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ (consultato il 3 novembre 2026)
  7. OWASP, «Session Management - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (consultato il 3 novembre 2026)
  8. MITRE ATT&CK, «Browser Session Hijacking». https://attack.mitre.org/techniques/T1185/ (consultato il 3 novembre 2026)

Cita questo articolo

Brain, «Furto di cookie di sessione e token bearer», Cyberpedia, 2026. https://startbrain.io/cyberpedia/it/articles/furto-cookie-sessione-token-bearer/

BibTeX 
@misc{brain_cp048_it_2026,
  author = {Brain},
  title = {Furto di cookie di sessione e token bearer},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/it/articles/furto-cookie-sessione-token-bearer/},
  note = {CC BY 4.0}
}
Licenza CC BY 4.0