Forgiatura Cookie: Web Cookies (T1606.001)

La forgiatura di cookie web rappresenta una tecnica di Credential Access (TA0006) in cui l'attaccante genera ex-novo token di sessione validi anziché sottrarli a un utente legittimo. La differenza è sostanziale: mentre il furto di cookie richiede accesso al browser della vittima, la forgiatura richiede il possesso dei segreti crittografici con cui l'applicazione firma o cifra i propri cookie — chiavi HMAC, private key SAML, machine key di ASP.NET, seed OAuth.

Una volta ottenuti questi segreti, l'attaccante può generare cookie arbitrari che l'applicazione considererà indistinguibili da quelli legittimi, bypassando MFA, controlli di rischio adattivo e policy di conditional access. È esattamente lo scenario osservato nella campagna SolarWinds Compromise (C0024), dove APT29 ha aggirato l'autenticazione multi-fattore su account Outlook Web Access generando cookie a partire da una chiave segreta precedentemente esfiltrata.

L'impatto operativo è severo perché il vettore opera fuori banda rispetto agli endpoint della vittima: non c'è malware sul client, non c'è phishing, non c'è login anomalo. L'unico segnale è una sessione autenticata che appare senza il corrispondente evento di autenticazione. Le mitigazioni MITRE censite sono due — M1047 Audit e M1054 Software Configuration — e riflettono la natura del problema: si difende attraverso rotazione dei segreti, hardening delle applicazioni e correlazione dei log, non con controlli endpoint tradizionali.

L'esercizio red team su T1606.001 parte dall'identificazione dei segreti che firmano i cookie. Su applicazioni ASP.NET classiche il target è la machineKey (validationKey e decryptionKey) presente in web.config o nel machine-level machine.config. Con questi valori si possono forgiare __VIEWSTATE, .ASPXAUTH e cookie di forms authentication. Il tool di riferimento è ysoserial.net (open source), utilizzato per generare payload ViewState firmati:

ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "comando" --path="/page.aspx" --apppath="/" --validationkey=... --validationalg=HMACSHA256

Per applicazioni che usano JWT il vettore è la chiave HMAC (algoritmi HS256/HS384/HS512) o la private key RSA/ECDSA per algoritmi asimmetrici. jwt_tool (open source) permette sia il tampering che il brute-force di chiavi HMAC deboli:

python3 jwt_tool.py -C -d wordlist.txt

Su ambienti Microsoft 365 / ADFS — lo scenario APT29 — il target sono le chiavi di firma dei token SAML sul server ADFS. Estratte con AADInternals (open source), permettono di generare Golden SAML con arbitrarie claim, incluso il MFA-satisfied flag:

Export-AADIntADFSSigningCertificate New-AADIntSAMLToken -ImmutableID -Issuer -PfxFileName cert.pfx

Per applicazioni Flask (Python) la chiave è SECRET_KEY; flask-unsign (open source) automatizza estrazione e forgiatura:

flask-unsign --unsign --cookie '' --wordlist wordlist.txt flask-unsign --sign --cookie "{'user':'admin'}" --secret 'chiave'

Per Rails la chiave è secret_key_base; rails-doubletap e script custom in Ruby permettono la generazione di cookie di sessione firmati.

In ambito lab-safe la catena tipica è: (1) enumerazione dell'applicazione per identificare il framework, (2) ricerca dei segreti tramite LFI, path traversal, backup file o accesso al filesystem (post-exploitation), (3) generazione offline del cookie forgiato, (4) invio del cookie con Burp Suite (freemium) o curl -b "cookiename=valore". La forgiatura è particolarmente potente contro le applicazioni interne dove la rotazione dei segreti è rara e la chiave iniziale, generata anni prima, non è mai stata cambiata anche dopo turnover di personale con accesso privilegiato.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo

TEST GRATUITO
2 minuti · 7 domande Che professionista cyber sei? Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.