Furto di Credenziali dai Browser: Credentials from Web Browsers (T1555.003)

Il furto di credenziali dai browser è uno degli scenari più replicabili in laboratorio, perché i tool sono pubblici, maturi e multipiattaforma. Il punto di partenza è comprendere dove ciascun browser conserva i propri database e quale meccanismo crittografico li protegge.

LaZagne (open source) è il tool più versatile. Scritto in Python, interroga i credential store di Chrome, Firefox, Opera, Edge e decine di altre applicazioni con un solo comando:

laZagne.exe browsers

Questo flag limita l'estrazione ai soli moduli browser, riducendo il rumore in un engagement mirato. Per un dump completo su tutte le sorgenti supportate, basta usare laZagne.exe all. Su Linux, lo stesso tool funziona invocando python3 laZagne.py browsers previa installazione delle dipendenze tramite pip.

Su Windows, un approccio manuale è altrettanto istruttivo. Chrome conserva le credenziali in un database SQLite. Dopo aver copiato il file Login Data — necessario perché il database è bloccato dal processo del browser — si può interrogare con sqlite3 (open source):

sqlite3 "Login Data_copy" "SELECT action_url, username_value, password_value FROM logins;"

I valori di password_value risulteranno cifrati con DPAPI. Per decrittarli, Mimikatz (open source) offre il modulo dpapi:

mimikatz # dpapi::chrome /in:"Login Data_copy" /unprotect

Questo comando sfrutta il contesto utente corrente per invocare CryptUnprotectData e restituire le password in chiaro. In scenari post-exploitation, se si dispone del master key DPAPI della vittima, è possibile specificarlo manualmente con il flag /masterkey:.

Su macOS, il target privilegiato è il Keychain. Il comando nativo security dump-keychain -d login.keychain-db richiede l'interazione utente per ogni voce — limitazione aggirabile in scenari con accesso fisico o con sessione attiva. Per Firefox su macOS e Linux, i file key4.db e logins.json nella directory del profilo contengono tutto il necessario; tool come firefox_decrypt (open source) li decodificano automaticamente.

Per simulazioni red team più strutturate, SharpChromium (open source) è un assembly .NET eseguibile in-memory tramite execute-assembly in framework C2 come Cobalt Strike o Sliver, evitando di scrivere su disco. In alternativa, Empire (open source) mette a disposizione moduli PowerShell dedicati per l'estrazione da Chrome e Firefox, integrabili in catene d'attacco già avviate.

Un buon esercizio conclusivo: estrarre le credenziali, testarle contro il Domain Controller con CrackMapExec (open source) tramite crackmapexec smb -u -p e dimostrare al cliente come una singola password salvata nel browser possa aprire la strada al dominio.

La detection di questa tecnica si gioca sulla visibilità dei file access ai database delle credenziali e sulle chiamate API crittografiche anomale. Il principio guida è semplice: se un processo che non è un browser legge il file Login Data di Chrome, qualcosa non va.

Sysmon (gratuito) è il pilastro su Windows. L'EventCode 11 (FileCreate) e soprattutto l'EventCode 15 (FileCreateStreamHash) catturano la copia del database, ma la sorgente più chirurgica è l'EventCode 1 (ProcessCreate) correlato al processo che esegue l'operazione. Configura una regola che rilevi accessi ai percorsi critici:

• \AppData\Local\Google\Chrome\User Data\Default\Login Data
• \AppData\Local\Microsoft\Edge\User Data\Default\Login Data
• \AppData\Roaming\Mozilla\Firefox\Profiles\*.default*\logins.json
• Credential Locker di Internet Explorer/Edge Legacy

L'analytic Windows (AN0105) prevede la correlazione tra il file read del database e la successiva chiamata a CryptUnprotectData. Per implementarla, abilita il log delle chiamate DPAPI tramite WinEventLog:Security con l'EventCode 4693 (tentativo di accesso a dati protetti DPAPI) e correla entro una finestra temporale di 5-10 secondi con il file access registrato da Sysmon.

Su Linux (AN0106), auditd è lo strumento nativo. Le regole da attivare monitorano i file credential dei browser e l'uso di ptrace/gdb su processi browser:

-w /home/ -p r -k browser_cred_access

Filtra con attenzione: i processi del browser stesso e gli aggiornamenti automatici genereranno accessi legittimi. La whitelist deve includere i binari firmati dei browser e i processi di sincronizzazione profili. Il tuning dell'analytic AN0106 prevede una lista esplicita di debugger autorizzati (gdb, strace in ambienti dev) per ridurre i falsi positivi.

Su macOS (AN0107), i Unified Logs tracciano l'esecuzione di security dump-keychain e l'accesso ai file in ~/Library/Application Support/Google/Chrome/. Correla il processo che accede al Keychain con la sua genealogia: un processo senza firma Apple o con parent sospetto (Terminal da script, python, osascript) merita un alert ad alta priorità.

Per la gestione dei falsi positivi, il pattern più comune sono i password manager legittimi — 1Password, Bitwarden e simili — che accedono ai database dei browser per l'importazione. Inseriscili in whitelist basata su hash del binario, mai sul solo nome processo. Anche i tool di IT management e i browser update possono generare rumore: il tuning deve essere progressivo, partendo da una modalità di sola osservazione per almeno due settimane.

L'analisi forense del furto di credenziali dal browser si basa su artefatti filesystem, tracce di esecuzione e correlazione temporale tra accesso al database e attività di rete successiva. L'obiettivo è ricostruire non solo il momento del dump, ma anche come quelle credenziali sono state utilizzate.

Su Windows, il primo artefatto da cercare è il file Login Data di Chrome — e soprattutto le sue copie. Gli attaccanti raramente leggono il database in-place perché è bloccato dal processo del browser; lo copiano in una directory temporanea. I $MFT e $UsnJrnl del volume NTFS rivelano la creazione di copie con nomi come Login Data.bak, Login Data_copy o nomi randomici in %TEMP%. Usando MFTECmd (open source, di Eric Zimmerman), si possono estrarre i timestamp di creazione e modifica:

MFTECmd.exe -f "$MFT" --csv output_dir

Filtra i risultati per i percorsi noti dei credential store. Un file Login Data copiato in C:\Users\<utente>\AppData\Local\Temp\ con timestamp compatibile con l'intrusione è un indicatore fortissimo.

Le tracce di esecuzione completano il quadro. Prefetch registra l'esecuzione di tool come lazagne.exe, browserghost.exe o sqlite3.exe. Il file .pf corrispondente contiene il timestamp dell'ultima esecuzione e le directory accedute. AmCache e ShimCache confermano la presenza di binari sospetti anche se cancellati. Per i tool .NET come SharpChromium eseguiti in-memory, cerca nei log di .NET CLR (EventCode 187 nel log Microsoft-Windows-DotNETRuntime) tracce di assembly caricati da percorsi inusuali.

L'EventCode 4693 nei Security logs documenta gli accessi DPAPI, cruciali per dimostrare che l'attaccante ha invocato CryptUnprotectData. Correla il timestamp con il SID dell'utente: se l'accesso DPAPI è avvenuto sotto un contesto utente diverso dal proprietario del profilo, hai un'evidenza di impersonation.

Su Linux, auditd — se era attivo — registra i file read su logins.json e key4.db nei log con chiave SYSCALL e PATH. I timestamp dei file .bash_history o .zsh_history possono contenere comandi come sqlite3, python3 o riferimenti diretti ai percorsi di Firefox. Verifica anche i log di gnome-keyring-daemon se il sistema usava un desktop environment.

Su macOS, i Unified Logs filtrati con log show --predicate 'process == "security"' evidenziano le invocazioni al Keychain. Gli FSEvents tracciano l'accesso ai file in ~/Library/Application Support/ con granularità temporale sufficiente per la timeline.

L'ultimo passo è la correlazione: una volta stabilito quando le credenziali sono state estratte, cerca nei log di autenticazione (Domain Controller EventCode 4624/4625, VPN, applicazioni web) tentativi di login con quelle stesse utenze nei minuti o ore successivi. Questo collegamento tra credential theft e lateral movement è spesso l'elemento che trasforma un'indagine tecnica in una narrativa forense completa.

Il furto di credenziali dai browser è una delle tecniche più democratiche nel panorama delle minacce: la utilizzano tanto gli infostealer venduti a pochi dollari nei forum underground quanto le unità di intelligence più sofisticate del pianeta. Proprio questa trasversalità rende l'analisi dei profili APT particolarmente istruttiva.

APT29, protagonista della campagna SolarWinds Compromise (C0024, 2019-2021), ha sottratto password salvate in Chrome durante una delle operazioni di supply chain più complesse mai documentate. Il dato è significativo: anche un gruppo con capacità di compromissione della build pipeline di un vendor software ricorre al banale dump delle credenziali browser quando serve espandere l'accesso laterale. Il pattern suggerisce che le credenziali browser vengono raccolte come attività opportunistica in fase post-exploitation, non come obiettivo primario.

OilRig (G0049) mostra un approccio più specializzato. Nella campagna Juicy Mix (C0044, 2022), il gruppo ha impiegato tool dedicati — CDumper per Chrome e EDumper per Edge — anziché strumenti generici. Questa specializzazione per browser riflette un'evoluzione tattica: quando LaZagne o tool multipurpose vengono rilevati dalle soluzioni EDR, lo sviluppo di dumper custom riduce la firma. OilRig ha anche utilizzato PICKPOCKET, un ulteriore tool proprietario per il dump delle password browser, confermando l'investimento sistematico su questa tecnica.

Volt Typhoon (G1017) rappresenta il caso più insidioso: il gruppo ha preso di mira specificamente i dati browser degli amministratori di rete, inclusa la cronologia di navigazione oltre alle credenziali salvate. Questo targeting selettivo — non il dump massivo, ma la raccolta mirata su account di rete — è coerente con il profilo living-off-the-land del gruppo e con il suo obiettivo di persistenza silenziosa nelle infrastrutture critiche.

Sul versante finanziariamente motivato, LAPSUS$ (G1004) ha utilizzato RedLine Stealer per ottenere password e token di sessione. È un pattern ricorrente nei gruppi che operano con modelli ibridi tra hacktivismo e profitto: acquistano infostealer commodity, li distribuiscono su larga scala e selezionano poi i risultati più interessanti. TA505 (G0092) e FIN6 (G0037) seguono logiche simili, con malware rispettivamente personalizzato e Stealer One per colpire i browser delle vittime in campagne a sfondo finanziario.

I pattern geografici sono netti. I gruppi medio-orientali — OilRig, MuddyWater (G0069), HEXANE (G1001), APT33 (G0064) — convergono tutti sull'uso di questa tecnica, spesso tramite LaZagne o tool PowerShell personalizzati. I gruppi nordcoreani Kimsuky (G0094) e APT37 (G0067) la affiancano a malware dedicato come ZUMKONG e a tool NirSoft. Il cluster cinese — APT3 (G0022), APT41 (G0096), APT42 (G1044) — preferisce tool custom come BrowserGhost o malware integrato.

La tendenza emergente è lo spostamento da tool generici (LaZagne, Mimikatz) verso moduli integrati nel malware stesso: dei 62 software catalogati, la grande maggioranza sono malware con funzionalità browser-stealing nativa — da Emotet a QakBot, da Agent Tesla a Lumma Stealer. Per il threat intelligence, questo implica che la detection non può basarsi sulla firma del tool, ma deve concentrarsi sull'artefatto comportamentale: l'accesso anomalo al database delle credenziali.

Framework MITRE ATT&CK v16 — T1555.003 (Credentials from Web Browsers), TA0006. Campagne: C0024 (SolarWinds Compromise), C0044 (Juicy Mix). Detection: Sysmon (EventCode 1, 11, 15), Windows Security (EventCode 4693), auditd (Linux), Unified Logs (macOS). Tool di detection e analisi: MFTECmd, Sysmon, auditd. Integrato con conoscenza professionale per tool e procedure operative.