Browser Chromium: cronologia, download, cookie e sessioni

La maggior parte dei computer Windows esaminati esegue almeno un browser basato su Chromium, e il browser è spesso il luogo in cui diventano visibili le intenzioni: che cosa ha cercato l'utente, quale pagina ha aperto, quale file ha scaricato e da dove. Questa lezione tratta il profilo Chromium: dove si trova, quali file SQLite e JSON contiene, come leggere visite, transizioni e download con orari UTC esatti, che cosa implica per un esaminatore la crittografia di cookie e password e come acquisire i database senza perdere i record recenti ed eliminati. La cache e la navigazione privata sono trattate nella Lezione 4.3.

Un formato di profilo, molti browser

Google Chrome, Microsoft Edge, Brave, Opera e Vivaldi condividono il formato di profilo di Chromium, pertanto gli stessi file, tabelle e parser si applicano a tutti. Ogni browser mantiene una cartella User Data, che contiene una cartella per ciascun profilo: Default per il primo profilo, poi Profile 1, Profile 2 e così via.

%LOCALAPPDATA% corrisponde a C:\Users\<user>\AppData\Local, quindi il percorso stesso collega il profilo a un account Windows. Verificare tutte le cartelle dei profili, non soltanto Default: un secondo profilo è un luogo comune per attività che l'utente desiderava mantenere separate.

Local State, situato un livello più in alto in User Data, è un file JSON relativo all'intero browser. In profile.info_cache elenca ogni cartella di profilo con il relativo nome visualizzato in name e, per un profilo con accesso effettuato, l'indirizzo e-mail dell'account in user_name. In os_crypt.encrypted_key contiene la chiave codificata in Base64 che protegge cookie e password salvate. Una volta decodificato, tale valore inizia con il testo ASCII DPAPI, seguito da un blob protetto dalla Windows Data Protection API (DPAPI) per quell'utente.

Il database History

History è un database SQLite. Chromium memorizza gli orari come tempo WebKit: microsecondi trascorsi dal 1601-01-01 UTC (Lezione 3.1). Chrome elimina le visite risalenti a oltre 90 giorni circa, quindi un periodo iniziale vuoto può essere dovuto alla scadenza del periodo di conservazione, non all'inattività.

urls e visits

La tabella urls contiene una riga per ogni URL distinto: id, url, title, visit_count, typed_count (la frequenza con cui l'URL è stato digitato nella omnibox, la barra combinata degli indirizzi e di ricerca) e last_visit_time. Si tratta di un riepilogo. La tabella visits contiene una riga per ogni visita, ossia ciò che serve a una linea temporale:

• url: il valore urls.id della pagina visitata (una chiave esterna, non testo);
• visit_time: quando è iniziata la visita (tempo WebKit);
• from_visit: il valore visits.id della visita di provenienza, che consente di ricostruire le catene di navigazione;
• transition: come l'utente è arrivato alla pagina;
• visit_duration: per quanto tempo la pagina è rimasta caricata nella propria scheda, in microsecondi, fino alla navigazione della scheda verso un'altra pagina o alla sua chiusura.

Valori di transizione

Il byte meno significativo di transition (transition & 0xFF) rappresenta il tipo di base; i bit più significativi sono qualificatori.

I bit qualificatori includono 0x01000000 (avanti/indietro), 0x02000000 (dalla barra degli indirizzi), 0x10000000 e 0x20000000 (inizio e fine di una catena di reindirizzamenti), 0x40000000 (reindirizzamento client) e 0x80000000 (reindirizzamento server). Pertanto, 805.306.368 = 0x30000000 è un LINK che ha iniziato e concluso una catena, e 838.860.805 = 0x32000005 è GENERATED dalla barra degli indirizzi. Alcuni strumenti visualizzano i valori con il bit più significativo impostato come interi negativi; la maschera restituisce comunque lo stesso tipo di base. Una visita TYPED costituisce un elemento di prova dell'intenzionalità dell'utente più forte rispetto a una visita LINK, che può essere attivata da una pagina o da uno script.

downloads e downloads_url_chains

La tabella downloads contiene una riga per ogni download: target_path (percorso finale), current_path (percorso durante il download, normalmente uguale a target_path al completamento), start_time, end_time, received_bytes, total_bytes, state (1 completato, 2 annullato, 4 interrotto), danger_type (0 significa che non è stato mostrato alcun avviso), tab_url e referrer (la pagina da cui è iniziato il download), mime_type, opened (1 se aperto dall'interfaccia di download del browser) e last_access_time. downloads_url_chains si collega a questa tabella tramite id e contiene una riga per ogni chain_index; l'indice più alto è l'URL da cui il file proviene effettivamente, mentre gli indici inferiori mostrano i reindirizzamenti che vi hanno condotto. Il file sul disco presenta spesso un flusso Zone.Identifier il cui HostUrl dovrebbe corrispondere a quell'URL finale (Lezione 1.4).

keyword_search_terms

keyword_search_terms memorizza i termini di ricerca digitati nella omnibox (term e normalized_term in minuscolo), con url_id che punta alla riga di urls relativa alla pagina dei risultati. Unendola a visits si ottiene l'orario di ogni ricerca.

Altri file del profilo

Non tutti gli orari di Chromium sono espressi in tempo WebKit: date_created e date_last_used nella tabella autofill sono secondi Unix. Verificare l'ordine di grandezza di ogni valore prima di convertirlo.

Sessioni

Le versioni recenti conservano i file Session_<n> e Tabs_<n> nella cartella Sessions, dove <n> è un timestamp WebKit; le versioni precedenti utilizzavano Current Session, Last Session, Current Tabs e Last Tabs nella cartella del profilo. Si tratta di file SNSS: la firma SNSS, una versione a 32 bit e quindi una serie di comandi che registrano finestre, schede e le voci di navigazione di ogni scheda con URL e titoli. Possono mostrare pagine che erano aperte alla chiusura del browser, comprese alcune non più presenti in History.

Cookie e crittografia

A partire da Chrome 96, il database dei cookie è Network\Cookies (in precedenza, Cookies nella cartella del profilo). La tabella cookies contiene creation_utc, host_key, name, path, expires_utc, last_access_utc e il valore in encrypted_value, con tutti gli orari in formato WebKit. A partire da Chrome 80, i valori presentano il prefisso v10 e sono crittografati con AES-256-GCM utilizzando la chiave di Local State, a sua volta protetta da DPAPI. La loro decrittografia offline richiede quindi la chiave master DPAPI dell'utente, in genere recuperata tramite la password dell'utente. A partire da Chrome 127 su Windows, la crittografia vincolata all'applicazione protegge i nuovi cookie (prefisso v20) con una chiave aggiuntiva che soltanto un servizio Chrome in esecuzione come SYSTEM può rilasciare, ed esclusivamente all'applicazione Chrome. La decrittografia offline dei valori v20 da un'acquisizione di triage è molto più difficile e spesso impraticabile. I valori dei cookie sono raramente necessari: l'host, il nome e i tre timestamp mostrano solitamente che un account ha visitato un servizio o vi ha effettuato l'accesso, e quando. Anche le password salvate in Login Data sono crittografate; l'URL, il nome utente e le date sono in chiaro.

Acquisizione e analisi in sicurezza

Acquisire ogni database insieme ai relativi file associati. Un journal di rollback (History-journal) contiene copie delle pagine precedenti a una modifica e può contenere record successivamente sovrascritti. Un database in modalità write-ahead log presenta file -wal e -shm; il WAL contiene modifiche recenti non ancora scritte nel file principale. Acquisire tutti i file esistenti e lavorare su copie: l'apertura di un database WAL può integrare il log nel database e modificare le prove. Chromium compila SQLite con la cancellazione sicura attivata, quindi le righe eliminate vengono normalmente sovrascritte con zeri nel file principale; copie precedenti possono sopravvivere nel journal o nel WAL, nelle copie shadow del volume o nello spazio non allocato, e il loro recupero mediante carving richiede uno strumento di recupero SQLite e una verifica in esadecimale.

DB Browser for SQLite (aperto in sola lettura) è sufficiente per le query manuali. Hindsight (obsidianforensics) analizza un intero profilo Chromium e lo converte in un'unica linea temporale, BrowsingHistoryView di NirSoft legge più browser contemporaneamente e Plaso dispone di plugin Chrome come chrome_27_history (Lezione 3.3). Verificare ogni valore ottenuto dall'analisi confrontandolo con la tabella grezza.

Esempio svolto: le visite di ana e un download

L'acquisizione di triage della Parte B contiene C:\Users\ana\AppData\Local\Google\Chrome\User Data\Default\History e History-journal. In Local State, profile.info_cache elenca soltanto Default, con un indirizzo e-mail in user_name. La query è SELECT v.id, u.url, datetime(v.visit_time/1000000 - 11644473600, 'unixepoch') AS utc, v.transition & 0xFF AS core, v.from_visit, v.visit_duration FROM visits v JOIN urls u ON v.url = u.id ORDER BY v.visit_time;. La divisione intera scarta i microsecondi; scrivere il risultato in formato ISO 8601 con T e Z.

Verificare manualmente la riga principale. visit_time è 13.417.970.987.412.563. Diviso per 1.000.000: 13.417.970.987 s dal 1601. Sottraendo 11.644.473.600: tempo Unix 1.773.497.387. Poiché 1.773.446.400 corrisponde a 2026-03-14T00:00:00Z, i restanti 50.987 s = 14 h (50.400) + 9 min (540) + 47 s, da cui 2026-03-14T14:09:47Z. La durata, 1.275.384.220 µs, è pari a 1.275 s, ossia 21 min 15 s, quindi la pagina è rimasta caricata fino a circa 14:31:02Z, dato coerente con l'intervallo SRUM che termina alle 14:31:09Z (Lezioni 2.8 e 3.4). keyword_search_terms contiene send large files free con url_id uguale al valore urls.id della visita 4180.

La tabella downloads contiene una riga con target_path C:\Users\ana\Downloads\xfer.exe, start_time 13.417.892.317.250.948 ed end_time 13.417.892.320.031.776, received_bytes e total_bytes entrambi pari a 1.482.752, state 1 e danger_type 0. Inizio: 13.417.892.317 − 11.644.473.600 = 1.773.418.717; sottraendo 1.773.360.000 (2026-03-13T00:00:00Z) rimangono 58.717 s = 16 h (57.600) + 18 min (1.080) + 37 s, quindi 2026-03-13T16:18:37Z. Fine: 3 s dopo, 2026-03-13T16:18:40Z. downloads_url_chains riporta all'indice 0 https://files.example.net/get/xfer-latest e all'indice 1 https://cdn.files.example.net/b/7f3a/xfer.exe, l'origine del file. L'orario di fine corrisponde all'orario di modifica $SI e all'orario Shimcache di xfer.exe (Lezione 2.3), la dimensione corrisponde a quella in Amcache e la prima esecuzione alle 16:20:02Z è avvenuta 82 secondi dopo. Il risultato: il profilo Chrome dell'account di ana ha scaricato xfer.exe da cdn.files.example.net tra le 16:18:37Z e le 16:18:40Z.

Focus sull'esame: Occorre saper convertire i tempi WebKit di visits, downloads o cookies in formato ISO 8601 UTC, unire visits.url a urls.id per trovare la pagina associata a una visita e leggere l'URL finale da downloads_url_chains. È necessario conoscere i tipi di base delle transizioni dopo l'applicazione della maschera 0xFF, sapere che visit_duration è espresso in microsecondi e quale file risponde a ciascuna domanda, compreso Local State per profili e account. Ricordare che gli orari di autofill sono secondi Unix, non tempo WebKit.

Punti chiave

• Chrome, Edge, Brave, Opera e Vivaldi condividono un unico formato di profilo in User Data\<Profile>; Local State elenca i profili e contiene la chiave protetta da DPAPI.
• History: urls riepiloga ogni URL; visits registra ogni visita con visit_time, from_visit, transition (tipo di base = byte meno significativo) e visit_duration in microsecondi.
• downloads fornisce percorsi, orari, dimensioni e stato; downloads_url_chains fornisce i reindirizzamenti, con il valore chain_index più alto che identifica l'URL finale del file.
• I valori dei cookie sono crittografati (v10 con la chiave protetta da DPAPI, v20 con vincolo all'applicazione a partire da Chrome 127), ma host, nomi e orari sono in chiaro e solitamente sufficienti.
• Acquisire i file -journal, -wal e -shm insieme a ciascun database e lavorare su copie; la cancellazione sicura riempie di zeri le righe eliminate, quindi cercare copie precedenti nei journal, nei file WAL e nelle copie shadow.