Vidar ha trovato un modo per aggirare una delle difese più importanti di Google Chrome. Per gli utenti e per i team IT, il messaggio è semplice: aggiornare i controlli di sicurezza e monitorare comportamenti anomali del browser è oggi più utile che cercare solo indicatori statici. Il problema riguarda cookie e credenziali memorizzati nel browser, quindi la protezione non dipende soltanto dalla forza della crittografia, ma anche da come il malware riesce a lavorare dentro il processo corretto.
Cosa sta succedendo
Le nuove varianti di Vidar infostealer stanno usando una tecnica avanzata per superare Application-Bound Encryption (ABE) di Google Chrome, il sistema introdotto nel 2024 per proteggere cookie e credenziali salvati nel browser. In pratica, il malware non si limita a cercare dati su disco: punta alla memoria viva del browser e sfrutta meccanismi legittimi di Windows per estrarre la chiave necessaria alla decifratura.
Secondo le analisi più recenti, Vidar combina più passaggi: crea processi figlio, analizza la memoria, individua il punto in cui Chrome conserva la chiave master e poi usa APC injection per eseguire codice nel contesto giusto. Il risultato è una tecnica più discreta rispetto all’iniezione classica e, per questo, più difficile da intercettare con alcuni strumenti di difesa.
Perché questa minaccia è importante
Chrome usa ABE per legare i dati sensibili all’applicazione che li ha creati, rendendo più complicato il furto di informazioni salvate localmente. Il bersaglio principale di un infostealer moderno è la v20_master_key, cioè la chiave che consente di decifrare dati protetti come cookie e credenziali.
Su disco, questa chiave è protetta da due livelli di CryptProtectData. In memoria, invece, Chrome la tutela con CryptProtectMemory e il flag CRYPTPROTECTMEMORY_SAME_PROCESS. Questo significa che non basta copiare la chiave cifrata e provare a decifrarla altrove: la chiave può essere ottenuta solo nel contesto del processo browser attivo.
Come funziona il metodo di Vidar
Vidar evita l’approccio tradizionale e agisce direttamente sulla memoria del browser. Quando Chrome è già in esecuzione, il malware apre un handle con permessi di lettura e richiama NtCreateProcessEx con un section handle nullo. Questo crea una sorta di fork silenzioso del browser, una copia memoria in modalità copy-on-write, senza avviare nuova esecuzione visibile e senza attirare subito l’attenzione dei sistemi di difesa.
Se Chrome non è attivo, il malware può avviare una finestra nascosta usando CreateDesktopA, creare un desktop denominato nel formato v20_%d e lanciare il browser con parametri come –no-first-run, –disable-gpu e about:blank. L’obiettivo è sempre lo stesso: ottenere un ambiente controllato in cui il browser sia presente e ispezionabile.
Una volta ottenuta la copia del processo, Vidar esamina la memoria virtuale con NtQueryVirtualMemory e impiega fino a 64 thread di lavoro paralleli per cercare regioni di memoria committed e leggibili. Il malware cerca una sequenza di 32 byte che decodifica nella stringa ASCII v20\x00, un riferimento collegato a una struttura interna di Chromium chiamata Encryptor::KeyRing.
Questa struttura è fondamentale perché conserva le chiavi usate da ABE. Quando il malware trova il puntatore giusto, può arrivare alla chiave master cifrata e verificare i candidati con un meccanismo di majority voting, utile per ridurre i falsi positivi generati da blocchi di memoria pieni di zeri.
Perché APC injection rende l’attacco più efficace
Trovare la chiave non basta. Per decifrarla, Vidar deve eseguire CryptUnprotectMemory dall’interno del processo browser vivo. Qui entra in gioco l’APC injection. In questo caso, il malware usa due strategie diverse in base all’ambiente rilevato.
- Metodo classico: viene attivato quando vengono individuate soluzioni di sicurezza come ESET o Bitdefender. Il malware crea un thread remoto sospeso, accoda un APC e poi riprende il thread per eseguire la routine.
- Metodo speciale: è l’approccio predefinito. Vidar trova un thread già esistente del browser e inserisce un APC utente che può partire subito, senza richiedere necessariamente uno stato di attesa alertable.
Il vantaggio per l’attaccante è evidente: invece di usare un’iniezione di codice tradizionale, spesso più visibile, sfrutta un meccanismo legittimo di Windows che non sempre viene monitorato con la stessa attenzione.
Cosa accade dopo la decifratura
Una volta che CryptUnprotectMemory ha decifrato i dati in memoria, Vidar crea un secondo fork del processo per leggere in sicurezza la chiave tramite NtReadVirtualMemory. Poi prova a verificare se la chiave ottenuta funziona davvero, usando una decifratura AES-256-GCM dei dati protetti da ABE con BCryptDecrypt.
Se il tentativo ha successo, il malware ha ottenuto la chiave utile per accedere a cookie e credenziali. Per ridurre le tracce forensi, inserisce subito un altro APC per ri-cifrare la chiave in memoria e riportare il browser allo stato iniziale. Se nessun candidato produce un risultato valido, Vidar può persino terminare tutte le istanze del browser e riavviare l’intero ciclo di estrazione.
Impatto per la difesa
Questo comportamento cambia il modo in cui i team di sicurezza devono osservare il browser. La minaccia non dipende soltanto dal file malware, ma da una catena di azioni che coinvolge processi, memoria e thread. Per questo, controlli basati solo su firme statiche o su una scansione del disco possono non essere sufficienti.
I difensori dovrebbero prestare attenzione a:
- chiamate sospette a NtCreateProcessEx con section handle nullo;
- APC inseriti in thread attivi del browser;
- pattern di scansione memoria ad alta intensità;
- riavvii anomali di istanze di Chrome;
- tentativi di accesso a strutture interne del browser legate alla gestione delle chiavi.
In ambienti aziendali, è utile anche correlare questi segnali con eventi di processo anomali, creazione di desktop nascosti e uso insolito di API di memoria protetta.
Cosa devono fare utenti e aziende
Per gli utenti finali, la priorità è mantenere Chrome aggiornato, usare password manager affidabili e ridurre la permanenza di credenziali sensibili nel browser quando non necessario. Per le aziende, il punto centrale è rafforzare il monitoraggio comportamentale sugli endpoint e verificare che i prodotti EDR rilevino correttamente fork sospetti, APC inattesi e accessi non usuali alla memoria del browser.
Anche la formazione resta importante: quando un infostealer punta al browser, un singolo account compromesso può diventare il punto di ingresso per furti di sessione, accessi laterali e ulteriori compromissioni dell’ambiente.
Technical Deep Dive
Vidar mira alla catena di protezione di Chrome partendo dalla chiave v20_master_key, che è centrale per la decifratura dei dati ABE. Il punto critico non è il recupero della chiave su disco, perché lì il materiale è già protetto da più livelli di CryptProtectData; il vero obiettivo è ottenere la chiave dopo che Chrome l’ha caricata e protetta in memoria con CryptProtectMemory e CRYPTPROTECTMEMORY_SAME_PROCESS.
Il flusso osservato nelle varianti recenti comprende tre elementi tecnici chiave: process forking, memory pattern scanning e APC injection. Il fork creato con NtCreateProcessEx e section handle nullo produce una copia copy-on-write del browser che consente l’analisi della memoria senza alterare l’esecuzione principale. Questo approccio riduce il rumore operativo e complica la telemetria basata solo su nuove esecuzioni di processo.
La scansione di memoria avviene con NtQueryVirtualMemory su regioni committed e leggibili, distribuita su più worker thread per velocizzare la ricerca della firma associata a v20\x00. La corrispondenza porta a un nodo della struttura Encryptor::KeyRing, da cui il malware risale alla chiave master memorizzata. L’uso di majority voting sui candidati serve a filtrare blocchi omogenei o zero-filled e a limitare i falsi positivi.
La parte più delicata è l’esecuzione di CryptUnprotectMemory nel contesto del processo browser vivo. Poiché il flag CRYPTPROTECTMEMORY_SAME_PROCESS vincola la decifratura al processo originario, Vidar deve inserire il codice nel thread corretto. Da qui la scelta dell’APC injection, che può avvenire tramite thread sospeso oppure tramite un thread già attivo del browser. Una volta decifrata la chiave, il malware la legge con NtReadVirtualMemory, la verifica con una prova di AES-256-GCM e poi richiama un APC di pulizia per ricifrare il valore e ridurre i residui in memoria.
Dal punto di vista difensivo, i segnali più interessanti sono la combinazione tra NtCreateProcessEx con handle nullo, la scansione intensiva della memoria del browser e il queuing di APC verso thread di Chrome. Questi eventi, se correlati, indicano una catena d’attacco costruita per estrarre segreti dal contesto di esecuzione legittimo invece di puntare a una semplice esfiltrazione da file.
Fonte: https://gbhackers.com/vidar-infostealer-google-chromes-abe-encryption/
