sei nella clearnet. gli indirizzi elencati qui si aprono solo all'interno della rete tor - scarica il browser tor qui »
AlphaBay.Market
IT
ultimo controllo: 4 min fa 260 onion monitorati
home / notizie / sicurezza
26 ottobre 2026 sicurezza 6 min di lettura

Session hijacking: perché un cookie rubato vale più di una password

Una password rubata deve ancora superare il form di login: se l'account è protetto da autenticazione a più fattori, la porta di solito regge. Un cookie di sessione rubato è un'altra cosa: viene emesso dopo che il login è già riuscito, e tutto ciò che l'account fa dopo viene autenticato dal solo cookie. Quell'asimmetria spiega perché il furto di sessioni è diventato, senza clamore, la via preferita verso gli account protetti.

La meccanica è semplice: al login il server consegna al browser un cookie di sessione e, da quel momento, ogni richiesta successiva è autenticata dal solo cookie. La voce MITRE della tecnica T1539, Steal Web Session Cookie, nota che questi cookie possono trovarsi “su disco, nella memoria del processo del browser e nel traffico di rete”, e che chi ne possiede uno può usare l'applicazione “come utente autenticato senza bisogno di credenziali”. La tecnica complementare per il riutilizzo, T1550.004, registra che una sessione riprodotta “aggira alcuni protocolli di autenticazione a più fattori, poiché la sessione è già autenticata” e che i cookie “spesso restano validi per un periodo prolungato”.

Perché un cookie batte una password

Tre proprietà rendono il cookie più prezioso della credenziale che ha sostituito. È già oltre il muro della MFA, perché l'utente legittimo ha presentato il secondo fattore quando la sessione è stata creata. Il suo uso non genera rumore di login falliti: l'attaccante arriva come un browser normale e autenticato. E cambiare la password non necessariamente chiude la sessione. Il rilevamento si affida al comportamento più che alla richiesta in sé: MITRE segnala il riutilizzo di cookie “da user agent o località insolite” e “scenari di viaggio impossibile e comportamenti anomali”. Anche gli attori statali lavorano la stessa cucitura. MITRE registra che APT29 ha rubato cookie di Chrome copiando le directory dei profili del browser durante la compromissione di SolarWinds e ha poi usato un cookie duo-sid contraffatto per aggirare la MFA, mentre Star Blizzard ha usato cookie di sessione raccolti tramite un proxy in stile Evilginx per arrivare alle caselle di posta delle vittime. Niente di tutto ciò ha richiesto di rompere un cifrario o battere un fattore — solo una copia di qualcosa che il browser possiede già.

I kit AiTM fanno da proxy al muro di login

La versione industriale è il kit adversary-in-the-middle. Una finta pagina di login che si limita a raccogliere password muore al secondo fattore. Un sito AiTM invece fa da proxy al login vero: la vittima si autentica normalmente attraverso il relay dell'attaccante, il codice viene inserito e il kit raccoglie il cookie di sessione emesso a fine flusso. Microsoft ha documentato una campagna del genere a luglio 2022, costruita su esche con documenti Office e messaggi vocali, che avrebbe colpito circa 10.000 organizzazioni da settembre 2021 — una campagna progettata, per parole di Microsoft, per “rubare password, dirottare sessioni attive (rubare cookie di sessione) e aggirare la MFA”. Oggi il modello gira in abbonamento. A settembre 2026 BleepingComputer ha raccontato BigBear 2.0, un framework phishing-as-a-service basato su Evilginx2 che avrebbe aggirato la MFA in 258 organizzazioni. Un rapporto CloudSEK citato nell'articolo quantificava il pannello dell'operatore in 5.137 record di credenziali — inclusi 474 autenticazioni completate con MFA aggirata, 1.032 password in chiaro e 4.148 cookie di sessione — legati a 3.331 indirizzi IP unici di vittime in oltre 40 paesi. Le riproduzioni passano per proxy residenziali abbinati al paese di ogni vittima, e il JavaScript iniettato dal kit interferisce con i prompt FIDO2/WebAuthn per spingere le vittime verso fattori più deboli.

I log degli infostealer sono inventari di cookie

Il condotto più silenzioso è il malware infostealer, e il suo mercato è visibilmente girato. Il rapporto di aprile 2026 di BleepingComputer su uno stealer commercializzato come Storm descrive un pannello a noleggio — 300 dollari per una demo di sette giorni, fino a 1.800 dollari al mese per un piano team — il cui pezzo centrale non è un dump di password ma una dashboard di ripristino dei cookie che ricostruisce sessioni autenticate lato server:
Date al pannello un refresh token di Google e un proxy SOCKS5 geograficamente coerente, e il pannello ripristina in silenzio la sessione autenticata della vittima.
I ricercatori dietro il rapporto hanno osservato che il furto di cookie di sessione sta sostituendo il furto di password come obiettivo principale dello sviluppo degli stealer. Questo riscrive cosa sia un log di stealer: meno una lista di credenziali da provare che un inventario di porte già aperte, ciascuna valida fino alla scadenza della sessione.

Cosa riduce davvero il rischio

Le contromisure sono poco appariscenti — è in parte per questo che così spesso vengono saltate. Rispecchiano ciò che Microsoft e MITRE raccomandano dalle prime ondate AiTM:
  • Accorciare la durata delle sessioni ed eliminare con regolarità i cookie persistenti — la mitigazione MITRE dice esattamente questo. Le sessioni lunghe del tipo “ricordami” sono la materia prima di questo commercio.
  • Legare le sessioni al contesto del dispositivo o della rete: regole di accesso condizionale che richiedono un dispositivo gestito fanno fallire la riproduzione di un cookie nudo anche quando il cookie è autentico.
  • Prendere la riproduzione: controlli di impossible travel e allarmi su anomalie di sessione beccano la maggior parte dei riutilizzi di cookie.
  • Passare gli account sensibili all'autenticazione resistente al phishing. Le passkeys vincolate all'hardware (FIDO2/WebAuthn) sono legate al dominio a cui si accede, così un proxy AiTM non può ritrasmetterle — è proprio per questo che kit come BigBear cercano di sopprimere quei prompt.
  • Eseguire il logout. Chiudere una sessione lato server invalida il cookie; chiudere la scheda no.

L'aritmetica del darknet

Per gli account dei market darknet l'aritmetica è insolitamente favorevole al ladro. I market proteggono di norma il login con il secondo fattore PGP: il server emette una challenge, l'utente la firma, l'accesso è concesso. Quella porta blindata copre esattamente un momento — il login. Tutto ciò che viene dopo corre su un cookie di sessione, e la sessione di un market è densa: ordini, messaggi dei vendor, pagine di prelievo, dispute. Un infostealer sulla macchina di un acquirente, o una pagina AiTM che fa da proxy al login, trasforma tutto in una riga copiabile — e la cerimonia PGP non viene mai toccata, perché non viene mai raggiunta. Nulla di questo rende obsoleta l'igiene delle password — le credenziali riutilizzate continuano ad alimentare il commercio di log, e le basi sono nel nostro pezzo su login unici e igiene delle password. Ma il muro del login non è più l'unico muro. Le sessioni sopravvivono ai login, ereditano la fiducia che la MFA si è guadagnata, e meritano la stessa gestione deliberata: durate più brevi, un logout esplicito quando il lavoro è fatto, e nessuna illusione che un codice sulla porta protegga ciò che accade nel corridoio.