Furto di Sessione Web: Web Session Cookie (T1550.004)
La tecnica T1550.004 - Web Session Cookie descrive l'abuso di cookie di sessione autenticati per accedere ad applicazioni web e servizi cloud impersonando l'utente legittimo. L'aspetto più insidioso è la capacità di bypassare completamente l'autenticazione multi-fattore: il token di sessione, una volta emesso, rappresenta la prova che l'MFA è già stato superato, quindi importarlo in un browser controllato equivale a scavalcare qualsiasi controllo aggiuntivo.
MITRE ATT&CK colloca questa tecnica in due tattiche complementari. In TA0005 (Defense Evasion) il cookie rubato consente di eludere i controlli di autenticazione senza generare eventi di login classici; in TA0008 (Lateral Movement) permette di pivotare tra servizi cloud, caselle di posta e console amministrative sfruttando le sessioni attive dell'utente compromesso.
I cookie di sessione hanno spesso validità estesa, talvolta settimane, anche in assenza di attività reale dell'utente. Un attaccante che ottiene il cookie tramite Steal Web Session Cookie (T1539) o intercettazione può leggere email, esfiltrare documenti da SharePoint, modificare regole di inoltro, autorizzare applicazioni OAuth e compiere qualsiasi azione consentita all'account vittima. Il fenomeno è amplificato dai proxy AiTM come EvilGinx, usati sia da attori criminali sia da APT statali, e da malware infostealer specializzati nell'esfiltrazione di cookie da browser Chromium e Gecko. Casi documentati includono Star Blizzard (G1033) contro account email di target politici e APT29 durante la SolarWinds Compromise (C0024), con cookie `duo-sid` forgiati per aggirare MFA Duo.
In un ingaggio red team autorizzato, la simulazione di T1550.004 parte tipicamente da una fase AiTM con Evilginx (open source), reverse proxy che intercetta credenziali e cookie di sessione durante un flusso di login reale verso servizi come Microsoft 365 o Google Workspace. Il tool viene configurato con phishlet dedicati e un dominio look-alike, poi avviato in modalità phishlet abilitato e lure generato:
evilginx2 -p ./phishlets
Dall'interno della console si abilitano i phishlet e si genera il lure con lures create o365 e lures get-url
Una volta esfiltrato il cookie, l'importazione in un browser di attacco è banale. Su Chromium-based si usa l'estensione Cookie-Editor (freemium) o EditThisCookie (open source), incollando i valori dei cookie di sessione nel dominio target e ricaricando la pagina: l'applicazione riconosce la sessione come già autenticata, senza richiedere password né MFA.
Per scenari post-exploitation su endpoint compromesso, il furto locale di cookie da Chrome/Edge si simula con SharpChrome dalla suite SharpDPAPI (open source) o con HackBrowserData (open source), che decodifica i cookie store cifrati con DPAPI:
hack-browser-data -b chrome -f json --dir ./output
Su macOS, i cookie di Safari risiedono in ~/Library/Cookies/Cookies.binarycookies e possono essere parsati con BinaryCookieReader (open source). Su Firefox il file cookies.sqlite è leggibile direttamente con sqlite3 una volta chiuso il browser.
Per il riuso contro API cloud, strumenti come TokenTactics (open source) o ROADtools (open source) permettono di scambiare cookie di refresh Azure AD in access token operativi:
Import-Module .\TokenTactics.psd1 Get-AzureToken -Client MSGraph
Su ambienti AWS, il riuso di cookie di console si accoppia con Pacu (open source) per enumerazione IAM. La catena tipica end-to-end da simulare in laboratorio è: phishing AiTM → cattura cookie → import in browser attaccante → accesso a Outlook Web e SharePoint → creazione regola di inoltro (T1114.003) → registrazione app OAuth per persistenza. Documentare tempi, artefatti generati e assenza di prompt MFA è la prova più efficace per il committente.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo
2 minuti · 7 domande
Che professionista cyber sei?
Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.