Iscriviti al webinar gratuito del 12 Maggio per diventare Forensic Analyst! Scopri di più
Corso Ethical Hacker: accedi alla promozione fino al 30 Aprile! Scopri di più
Furto di Sessione Web: Web Session Cookie (T1550.004)
Quando un utente si autentica su un'applicazione web — un portale cloud, una webmail, un pannello SaaS — il server rilascia un cookie di sessione che rappresenta la prova crittografica dell'avvenuta autenticazione. Da quel momento in poi, il browser presenta quel cookie a ogni richiesta successiva, evitando che l'utente debba reinserire credenziali e superare nuovamente l'MFA. È esattamente questo meccanismo che la tecnica Web Session Cookie sfrutta: un avversario che ottiene quel cookie può importarlo in un browser sotto il proprio controllo e operare con i privilegi della vittima, aggirando completamente l'autenticazione multifattore.
La tecnica si colloca in due tattiche distinte. Nella fase di Defense Evasion (TA0005), il riutilizzo di un cookie legittimo evita la generazione di eventi di login anomali, rendendo l'accesso meno visibile ai sistemi di monitoraggio. Nella fase di Lateral Movement (TA0008), l'attaccante sfrutta la sessione rubata per raggiungere risorse cloud, caselle email, repository documentali e sistemi interni esposti via web, senza bisogno di credenziali aggiuntive.
L'impatto è amplificato dalla longevità tipica dei cookie di sessione, spesso validi per ore o giorni anche in assenza di attività. Le campagne documentate confermano 1 gruppo APT, 1 campagna di rilievo globale e una superficie d'attacco che abbraccia IaaS, SaaS e suite Office.
Il cuore di questa tecnica è concettualmente semplice: ottenere un cookie di sessione valido e iniettarlo in un contesto controllato dall'attaccante. In un esercizio red team, il modo più realistico per simularlo è costruire un proxy di phishing che intercetti la sessione durante l'autenticazione legittima della vittima.
Evilginx (open source) è il tool di riferimento. Funziona come un reverse proxy che si posiziona tra la vittima e il sito target, catturando credenziali e cookie di sessione in tempo reale — inclusi i token post-MFA. Dopo l'installazione, si configura un "phishlet" per il servizio target (ad esempio Microsoft 365 o Google Workspace), si registra un dominio simile a quello legittimo e si genera un lure URL da inviare alla vittima.
La sequenza operativa in laboratorio prevede tre passaggi fondamentali. Primo, configurare il dominio e il certificato TLS sul server Evilginx. Secondo, caricare il phishlet appropriato e impostare il redirect post-cattura. Terzo, attendere che la vittima simulata completi l'autenticazione — a quel punto il pannello di Evilginx mostrerà il cookie di sessione catturato.
Una volta ottenuto il cookie, l'iniezione nel browser è banale. In Chrome o Firefox, si apre la console sviluppatore (F12), si naviga nella tab "Application" → "Cookies", e si aggiunge manualmente il cookie con nome, valore, dominio e path corretti. In alternativa, l'estensione Cookie-Editor (open source) per browser Chromium e Firefox semplifica l'import/export in formato JSON.
Per un approccio più automatizzato da riga di comando, si può usare curl con il flag -b per specificare un file cookie in formato Netscape:
curl -b cookies.txt
In contesti di red teaming avanzato, il framework Mangle (open source) consente di manipolare token OAuth e session cookie estratti da browser compromessi, mentre ROADtools (open source) è specificamente progettato per interagire con ambienti Azure AD/Entra ID utilizzando token e cookie rubati.
Un aspetto critico da testare è la persistenza: molti servizi cloud non invalidano il cookie nemmeno dopo un cambio password, a meno che l'amministratore non revochi esplicitamente le sessioni attive. Il red team dovrebbe misurare la finestra di validità reale dei cookie in scope e documentarla nel report.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Scarica la guida gratuita e segui il percorso corretto fin dal primo passo