Sebbene siano molto diffuse, le estensioni dei browser Web non sono necessariamente sicure. Proprio come qualsiasi altro software che si possa installare sul computer, le estensioni possono contenere codice dannoso progettato per arrecare ingenti danni ai pc dei malcapitati. L’ultima dimostrazione dei potenziali danni delle estensioni arriva sotto forma di un attacco malware proof-of-concept (PoC). I ricercatori di sicurezza hanno sviluppato “Cookie-Bite”, che mostra come le estensioni di Chrome possano dirottare furtivamente i token di sessione.
I threat actor spesso utilizzano gli infostealer per estrarre i token di autenticazione direttamente dal computer della vittima o acquistarli direttamente attraverso i Dark Market, consentendo agli avversari di dirottare le sessioni cloud attive senza attivare l’MFA. Iniettando questi cookie e imitando il sistema operativo, il browser e la rete della vittima, gli aggressori possono eludere le politiche di accesso condizionato (CAP) e mantenere un accesso persistente.
In parole povere, ciò significa che i malintenzionati possono accedere a quasi tutti i siti come impersonando la vittima. Tutto ciò che devono fare è ingannare gli utenti e spingerli ad installare un’estensione del browser apparentemente innocua. Oppure, se hanno ottenuto l’accesso al computer, possono installare l’estensione dannosa senza che gli utenti se ne accorgano. In questo documento verrà rappresentata una PoC di come funziona l’attacco.
Distribuisci i nostri corsi di formazione diventando un nostro Affiliato
Se sei un influencer, gestisci una community, un blog, un profilo social o semplicemente hai tanta voglia di diffondere cultura digitale e cybersecurity, questo è il momento perfetto per collaborare con RHC Academy. Unisciti al nostro Affiliate Program: potrai promuovere i nostri corsi online e guadagnare provvigioni ad ogni corso venduto. Fai parte del cambiamento. Diffondi conoscenza, costruisci fiducia, genera valore.
Contattaci tramite WhatsApp al 375 593 1011 per richiedere ulteriori informazioni oppure scriviti alla casella di posta [email protected]
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
Il malware Infostealer è emerso come un avversario formidabile, abile nel rubare dati sensibili, compresi i cookie di autenticazione. Questi programmi dannosi si infiltrano nei sistemi per esfiltrare le credenziali di accesso, i cookie di sessione e i token di autenticazione che vengono poi inviati a server remoti controllati dai criminali informatici.
Con i cookie rubati, gli aggressori possono dirottare le sessioni attive degli utenti, impersonare utenti legittimi e aggirare completamente l’MFA. Rubano, rubano la nostra identità. La maggior parte dei pirati informatici non utilizza direttamente i dati rubati. Operano invece nell’ambito di un modello di Malware-as-a-Service (MaaS), in cui diversi attori svolgono ruoli specializzati. Questi ruoli possono includere
Operatori di infostealer che sviluppano e distribuiscono malware per infettare il maggior numero possibile di vittime. Tracer (affiliati) che diffondono il malware attraverso tattiche di phishing, annunci malevoli o crack di software. Mercati darknet che fungono da hub in cui i criminali informatici vendono in massa cookie, credenziali e impronte digitali del browser rubati Gli acquirenti (da broker di accesso iniziale e gruppi di ransomware) acquistano queste credenziali per ottenere un accesso non autorizzato a servizi cloud, VPN aziendali e piattaforme sensibili.
Una volta venduti, i cookie di autenticazione rubati consentono agli aggressori di accedere come la vittima, spesso aggirando l’MFA. Questa tecnica, nota come session hijacking, è ampiamente sfruttata per violazioni aziendali, frodi finanziarie e spionaggio.
Le modalità di furto dei cookie
Nel panorama in evoluzione del dirottamento di sessione, gli aggressori utilizzano diverse tecniche per rubare i cookie di autenticazione, consentendo loro di bypassare l’MFA e di impersonare utenti legittimi.
I principali metodi utilizzati per rubare i cookie di autenticazione
Adversary-in-the-Middle
Gli attacchi di phishing AITM vanno oltre il tradizionale furto di credenziali intercettando i token di autenticazione e i cookie di sessione in tempo reale. Gli aggressori utilizzano strumenti di reverse proxy (ad esempio, Evilginx, Modlishka, Muraena) per interporsi tra la vittima e il servizio di autenticazione legittimo (ad esempio, Microsoft 365, Google).
Quando la vittima effettua l’accesso, il proxy cattura le credenziali, i token MFA e i cookie di sessione, consentendo all’aggressore di bypassare l’MFA e dirottare la sessione senza richiedere nuovamente la password dell’utente. Questa tecnica è ampiamente utilizzata per compromettere gli account cloud e aggirare le moderne difese di autenticazione.
Figura 1 AITM Flow
Dumping della memoria del processo del browser
Gli infiltrati sfruttano il fatto che i browser decifrano i cookie durante le sessioni attive, memorizzandoli per un accesso rapido. Il malware può iniettare codice nei processi del browser in esecuzione (ad esempio, chrome.exe, msedge.exe) per leggere questo spazio di memoria ed estrarre i cookie in chiaro. Questo approccio aggira la necessità di decriptare i cookie dal disco, poiché vi accede dopo la decriptazione durante l’uso attivo.
Estensioni del browser dannose
Le estensioni dannose del browser consentono agli aggressori di accedere direttamente ai cookie di autenticazione e ai token di sessione operando nel contesto di sicurezza del browser. Queste estensioni, spesso camuffate da strumenti legittimi, richiedono autorizzazioni eccessive che consentono loro di interagire con le sessioni Web, modificare il contenuto delle pagine ed estrarre i dati di autenticazione memorizzati. Una volta installate, possono accedere all’API di archiviazione del browser, intercettare le richieste di rete o iniettare JavaScript dannoso nelle sessioni attive per rubare i cookie di sessione in tempo reale.
A differenza del malware tradizionale, non è necessaria l’iniezione di processi o la decrittazione del disco, rendendo questa tecnica più difficile da rilevare a livello di endpoint. I token di autenticazione rubati vengono esfiltrati sul server dell’aggressore, dove possono essere riprodotti per aggirare l’MFA e impersonare la vittima.
Di solito, i browser memorizzano le estensioni nel seguente percorso (Chrome):
Le estensioni personalizzate del browser che non sono firmate possono essere caricate in modalità sviluppatore e poi caricate.
Figura 2 Estensione cookie-stealer caricata in Chrome
Decifrare i cookie memorizzati localmente
I browser memorizzano i cookie di autenticazione in database SQLite crittografati per mantenere la persistenza della sessione e proteggere i dati sensibili dell’utente. Tuttavia, gli aggressori possono estrarre e decifrare questi cookie ottenendo sia il database dei cookie memorizzati sia la chiave di crittografia utilizzata per proteggerli.
Il metodo varia a seconda del sistema operativo e del modello di sicurezza del browser: Windows si affida alla crittografia DPAPI, mentre Linux e macOS utilizzano meccanismi di keychain specifici del sistema.
Ad esempio:
I cookie di sessione memorizzati su Mac possono trovarsi in “/Library/Application Support/Google/Chrome/Default/Cookies”, limitati da Transparency, Consent and Control (TCC).
Su Windows, i browser basati su Chromium (Chrome, Edge, Brave, ecc.) memorizzano i cookie di autenticazione in Dati utente/…/Rete/Cookies il database SQLite principale contiene cookie crittografati AESStato locale → Memorizza la chiave di crittografia AES, che è a sua volta crittografata utilizzando WindowsData Protection API (DPAPI)
Poiché DPAPI vincola la crittografia al profilo utente e al computer, gli aggressori non possono decifrare facilmente i cookie al di fuori del sistema della vittima. Per aggirare questo problema, gli infiltrati devono:
Decifrare la chiave AES localmente utilizzando DPAPI (CryptUnprotectData()) all’interno della sessione infetta.
Rubare la chiave master DPAPI (C:\Users\…\AppData\Roaming\Microsoft\Protect) per tentare la decrittazione offline. La chiave master è crittografata con la password dell’utente (utente locale).
la password dell’utente (utente locale o utente AD) oppure
il segreto DPAPI_SYSTEM, nel caso di un sistema integrato.
Figura 3 Decriptare il blob usando DPAPI
Quali sono i cookie più preziosi?
Quando compromettono un dispositivo, gli aggressori danno priorità ai cookie in base al loro potenziale di ulteriore sfruttamento. Il valore dei cookie rubati dipende sia dalle motivazioni degli aggressori sia dalla domanda del mercato. Nella maggior parte dei casi, i cookie più preziosi sono quelli che forniscono un accesso a lungo termine ad account di alto valore o che consentono profonde opportunità di post-sfruttamento.
I cookie di sessione legati agli account dei social media (ad esempio, Facebook, Instagram, Twitter) possono essere redditizi, soprattutto se l’account ha un grande seguito, un’influenza commerciale o l’accesso a conti per la spesa pubblicitaria. Tuttavia, la loro utilità dipende dallo stato dell’account e dal valore di rivendita.
D’altro canto, i cookie delle sessioni cloud aziendali attive, come Microsoft 365, Google Workspace o AWS, sono spesso più interessanti per uno sfruttamento mirato successivo. Una sessione aziendale dirottata può consentire agli aggressori di accedere alle e-mail interne, esfiltrare dati sensibili, aumentare i privilegi o persino spostarsi lateralmente attraverso un’intera rete aziendale, portando potenzialmente a una completa compromissione dell’azienda.
Dirottare l’autenticazione di Azure
Questa ricerca si concentra su ESTSAUTH e ESTSAUTHPERSISTENT, due cookie di autenticazione critici utilizzati da Azure Entra ID (precedentemente AAD). Questi cookie mantengono le sessioni cloud autenticate e consentono l’accesso a Microsoft 365, Azure Portal e altre applicazioni aziendali.
Dirottando questi token di sessione, gli aggressori possono aggirare l’MFA, impersonare gli utenti e spostarsi lateralmente tra gli ambienti cloud, rendendoli uno degli obiettivi più preziosi per i ladri di informazioni e gli attori delle minacce.
Figura 4 Altri fornitori cloud Cookie di autenticazione
Nota: l’articolo si concentra principalmente sui cookie relativi all’autenticazione di Azure, ma le tecniche e gli approcci condivisi possono essere applicati anche ad altre piattaforme e servizi cloud elencati nella tabella precedente. I risultati pratici possono variare a seconda dell’ambiente di destinazione e delle sue difese, poiché ogni servizio ha una propria architettura di cookie, gestione delle sessioni e sicurezza.
Ruolo dei token ESTSAUTH e ESTSAUTHPERSISTENT
Nell’autenticazione web di Azure Entra ID, ESTSAUTH e ESTSAUTHPERSISTENT sono importanti token di sessione memorizzati come cookie del browser che rappresentano la sessione autenticata dell’utente:
ESTSAUTH: è il cookie di sessione principale di Azure Entra ID. “Contiene le informazioni sulla sessione dell’utente per facilitare l’SSO”. Si tratta di un token di sessione transitorio, cioè valido per la durata della sessione del browser. Se l’utente chiude il browser e non ha scelto un login persistente, il cookie ESTSAUTH viene distrutto, richiedendo un nuovo login la volta successiva. Per impostazione predefinita, un cookie ESTSAUTH (sessione non persistente) ha una validità massima di 24 ore, trascorse le quali l’utente dovrà effettuare una nuova autenticazione.
ESTSAUTHPERSISTENT: si tratta di una versione persistente del cookie di sessione Azure Entra ID. Contiene anche informazioni di sessione per l’SSO, ma è memorizzato come cookie persistente che rimane anche dopo la chiusura del browser. Questo cookie viene impostato quando un utente sceglie di “rimanere connesso” o quando viene applicata la funzione “Keep Me Signed In” (KMSI) di Azure Entra ID. Un token di sessione persistente consente all’utente di rimanere connesso anche dopo il riavvio del browser per un periodo prolungato. Per impostazione predefinita, il cookie ESTSAUTHPERSISTENT può rimanere valido per 90 giorni (il periodo di accesso predefinito di Azure Entra ID) o per la durata specificata dal criterio. Ciò significa che se un’utente scegliesse di rimanere connesso, potrebbe non essere richiesto di nuovo di fornire le credenziali o l’MFA per un massimo di 90 giorni su quel dispositivo. Il progetto di Azure Entra ID prevede che non venga richiesta una nuova autenticazione a meno che la sicurezza della sessione non cambi (ad esempio, modifica della password, disconnessione esplicita, modifica dei criteri).
Figura 5 Stay-signed-in
Questi cookie svolgono un ruolo fondamentale nell’equilibrio tra sicurezza e usabilità di Azure Entra ID. Essi contengono una forma di credenziale di sessione che dimostra che l’utente si è recentemente autenticato e, se applicabile, ha soddisfatto i requisiti MFA. Ad esempio, dopo un’autenticazione riuscita, Azure Entra ID può impostare un cookie ESTSAUTHPERSISTENT se l’utente ha fatto clic su “Sì” per rimanere connesso. Nei successivi accessi, la presenza di questo cookie consente ad Azure Entra ID di autenticare istantaneamente l’utente senza un’altra richiesta MFA. In altre parole, il cookie serve a dimostrare che “l’utente ha già eseguito l’MFA su questo browser, quindi non richiede un’altra richiesta” e garantisce l’accesso immediato.
In sintesi, i token ESTSAUTH(PERSISTENT) sono essenzialmente le “chiavi del regno” per quella sessione utente: provano che l’MFA è stato aggirato e consentono l’accesso continuo. Se un utente malintenzionato riesce a ottenere questi token, può impersonare la sessione dell’utente e bypassare l’intero processo di login (compreso l’MFA) perché Azure Entra ID considererà la sua sessione come già autenticata. Le sezioni seguenti analizzano come gli aggressori riescono a ottenere questo risultato e come difendersi da esso.
Figura 6 Cookie salvati in sessione
Questi cookie sono memorizzati localmente nel database SQLite di Chrome, situato all’indirizzo:
Chrome cripta i valori dei cookie utilizzando DPAPI, che lega la crittografia al profilo Windows dell’utente corrente.
Figura 7 Cookie ESTS salvati localmente e valore dei dati binari ESTSAUTH (blob)
Creazione di un cookie stealer personalizzato: In questa proof-of-concept, è stato creato un cookie stealer persistente che estrae i cookie di autenticazione da una sessione attiva del browser e li esfiltra ogni volta che la vittima accede al portale di autenticazione Microsoft. Questo attacco aggira l’MFA sfruttando i cookie di sessione, consentendo l’accesso continuo ai servizi cloud senza richiedere le credenziali dell’utente. Invece di un furto di cookie una tantum, questo metodo garantisce che i cookie di sessione validi vengano estratti ogni volta che l’utente accede, mantenendo l’accesso non autorizzato a lungo termine. Al termine di questa PoC, si avrà:
Un’estensione Chrome personalizzata che monitora gli eventi di autenticazione e cattura i cookie
Uno script di PowerShell che automatizza l’implementazione dell’estensione e ne garantisce la persistenza
Un semplice meccanismo di esfiltrazione per inviare i cookie a un punto di raccolta esterno Un’estensione complementare per iniettare in modo fluido i cookie catturati nel browser dell’attaccante, facilitando un dirottamento di sessione immediato e furtivo
Flow
Il diagramma seguente illustra il flusso end-to-end della Proof of Concept, dimostrando come gli aggressori catturino, esfiltrano e riutilizzino silenziosamente i cookie di autenticazione per dirottare le sessioni cloud delle vittime:
Figura 8 Diagramma della PoC
Fase 1:
Creazione dell’estensione Chrome per l’estrazione dei cookie Innanzitutto, si crea un’estensione Chrome che ascolta gli eventi di autenticazione e ruba i cookie di sessione quando la vittima accede a login.microsoftonline.com.
Configurazione della directory dell’estensione
Creazione una nuova directory chiamata CookieStealer Extension. All’interno di questa directory, si creino due file:
manifest.json (Definisce permessi e comportamenti)
background.js (Gestisce l’estrazione e l’esfiltrazione dei cookie)
Configurazione di manifest.json
Il file manifest definisce il comportamento dell’estensione, i permessi richiesti e gli script in background. Crea manifest.json all’interno della directory dell’estensione:
Figura 9 estensione manifest
Cosa fa:
Concede l’autorizzazione ad accedere a cookie, schede e richieste web. Limita l’esecuzione a login.microsoftonline.com. Carica background.js come servizio in background da eseguire in modo persistente.
Scrittura della logica di estrazione dei cookie (background.js)
L’estensione estrae i cookie ogni volta che la vittima accede al portale di autenticazione di Microsoft. Crea background.js e aggiungi quanto segue:
Figura 10 Estensione cookie durante l’accesso
L’estensione ascolta le richieste di autenticazione su login.microsoftonline.com. Quando si verifica un accesso, estrae i cookie (inclusi ESTSAUTH ed ESTSAUTHPERSISTENT). E’ stato scelto di esfiltrare i cookie in modo silenzioso tramite Moduli Google, direttamente sul Drive personale:
Figura 11Cookie Exfiltration attraverso google forms
Con l’estensione pronta, il passo successivo è automatizzarne la distribuzione. Dopo aver compresso l’estensione in un file CRX e averlo caricato su VirusTotal, il risultato mostra che nessun fornitore di sicurezza la rileva attualmente come dannosa.
Faese2: Automazione della distribuzione con PowerShell
Per automatizzare il caricamento dell’estensione, verrà creato uno script di PowerShell che la caricherà nel profilo utente predefinito di Chrome. Ecco una parte del codice che l’ha eseguita:
Questo script di PowerShell carica l’estensione in un processo di Chrome appena avviato. Tuttavia, l’estensione rimane attiva solo per la durata di questa sessione di Chrome. Una volta chiuso Chrome, l’estensione verrà rimossa automaticamente.
Pertanto, è consigliabile pianificare l’esecuzione periodica di questo script (ad esempio, ogni poche ore o quotidianamente, operazione eseguibile tramite un’attività pianificata o una cartella di avvio). Sebbene esistano metodi per caricare le estensioni in modo persistente, come l’utilizzo di policy basate sul registro o l’iniezione dell’estensione direttamente nel file Secure Preferences di Chrome bypassando il Message Authentication Code (MAC), questi approcci sono più complessi e in genere richiedono privilegi amministrativi.
Le aziende potrebbero limitare l’uso degli script di PowerShell. In questi casi, sarà necessario trovare alternative, come Python, VBScript o macro, per ottenere risultati simili.
Fase 3: Iniezione dei cookie
Dopo aver rubato i cookie di sessione, il passaggio successivo consiste nell’iniettarli nel browser dell’attaccante per ottenere l’accesso desiderato. Per raggiungere questo scopo, è stata utilizzata un’estensione di Chrome chiamata Cookie-Editor (ID: hlkenndednhfkekhgcdicdfddnkalmdm), disponibile sul Chrome Web Store.
Figura 12 Editor di cookie legittimo
Per prima cosa, si copino i dati dei cookie restituiti dal modulo Google, che sono già in formato JSON.
Successivamente verranno importati i dati dei cookie copiati nell’estensione Cookie-Editor.
Infine, si aggiorni la pagina per accedere al portale cloud della vittima di destinazione. E’ stato osservato, nel registro di accesso di Azure, che sono riuscite due autenticazioni con lo stesso ID sessione da posizioni e versioni del browser diverse in un breve lasso di tempo: Il vantaggio di questo approccio è che garantisce una sessione valida all’infrastruttura Azure dell’utente di destinazione. Questa rimane valida indipendentemente dal fatto che la durata della sessione sia scaduta o sia stata revocata, poiché l’estensione persiste e viene attivata ogni volta che viene avviato l’accesso Microsoft.
Conclusioni
Questo PoC dimostra come un aggressore possa creare un ladro di cookie persistente utilizzando solo un’estensione del browser e l’automazione di PowerShell. Sfruttando gli hook degli eventi di autenticazione, l’attacco garantisce che i cookie di sessione validi vengano estratti continuamente, garantendo un accesso non autorizzato a lungo termine.
Questa tecnica non richiede un’infezione da malware, ma un semplice script, rendendola più difficile da rilevare. La persistenza viene ottenuta tramite il browser stesso, evitando modifiche al sistema. Gli aggressori possono aggirare l’MFA rubando i cookie di sessione a ogni tentativo di accesso.
Damiano Capo Mi chiamo Damiano Capo, ho 32 anni e sono Senior Security Consultant.
Mi sono avvicinato alla cybersecurity nel 2018 grazie alla crittografia studiata all’università. Da autodidatta ho approfondito tecniche e strumenti usati dagli attaccanti, per aiutare le aziende a difendersi. Ho svolto tirocini su PT e VA e lavorato come consulente per PA e aziende private, occupandomi di VA, PT, difesa, forensics e malware analysis. Condivido ciò che imparo sul campo attraverso contenuti divulgativi.
PALERMO, 19 GIUGNO 2025 – Dopo le difficoltà operative registrate negli ultimi giorni, l’Azienda Sanitaria Provinciale di Palermo ha confermato ufficialmente di essere stata colpita...
Una vulnerabilità critica è stata scoperta nel driver di offload del canale dati di OpenVPN per Windows, che può essere sfruttata da attaccanti locali per mandare in crash i sistemi. Il...
Durante una RHC Conference, Corrado Giustozzi sottolineò una verità tanto semplice quanto potente: “L’essere umano è, da sempre, un creatore di amplificatori.”. Dal...
Nelle ultime ore, un’ondata massiccia di defacement ha preso di mira almeno una quindicina di siti web italiani. L’attacco è stato rivendicato dal threat actor xNot_RespondinGx (tea...
Nel mezzo degli intensi combattimenti tra Iran e Israele, il cyberspazio è stato coinvolto in una nuova fase di conflitto. Con il lancio dell’operazione israeliana Rising Lion, mirata all&...
