Webmail e account cloud sull'endpoint

Gran parte delle attività odierne di posta elettronica, condivisione di file e messaggistica si svolge in una scheda del browser o in un client desktop leggero, mentre i contenuti rimangono sui server del fornitore. Questa lezione illustra ciò che un esaminatore può comunque ricavare sugli account di webmail, archiviazione cloud, messaggistica e social media dal solo endpoint Windows: quali account esistono, chi li ha utilizzati e quando, nonché frammenti di contenuto. Delinea inoltre il limite oltre il quale l'endpoint non può fornire ulteriori informazioni e occorre ricorrere ai dati del fornitore, ottenuti tramite le procedure legali o con il consenso del titolare.

Cosa può e non può mostrare l'endpoint

Con un client di posta locale, la casella di posta si trova sul disco (Lezione 4.4). Con la webmail non è così: il browser scarica soltanto le parti della casella visualizzate dall'utente, spesso le conserva in memoria o in cache di breve durata e poi le elimina. L'endpoint risponde quindi bene a tre domande: se un account è stato utilizzato su questo computer, da quale utente Windows e profilo del browser e quando. Risponde a una quarta domanda, che cosa, solo parzialmente: oggetti dei messaggi, anteprime, allegati scaricati e frammenti nella cache. Le caselle di posta complete, gli elementi eliminati sul lato del fornitore, gli accessi da altri dispositivi e gli indirizzi IP si trovano presso il fornitore.

Identificazione degli account

Iniziare elencando tutte le identità degli account presenti sul sistema, quindi collegare ciascuna a un profilo utente Windows.

Profili del browser

I browser basati su Chromium (Chrome, Edge, Brave e altri) conservano una cartella per ciascun profilo, come %LOCALAPPDATA%\Google\Chrome\User Data\Default o ...\Microsoft\Edge\User Data\Profile 1 (la Lezione 4.1 ne illustra la struttura).

• Preferences (un file JSON nella cartella del profilo) contiene un array account_info relativo all'account con cui è stato effettuato l'accesso al profilo del browser. In Chrome, ogni voce contiene email, gaia (l'ID numerico dell'account Google, che non cambia quando cambia l'indirizzo), full_name e i campi correlati.
• Local State (un livello più in alto, in User Data) contiene profile.info_cache, che elenca ogni cartella di profilo con il relativo nome visualizzato e, per i profili con accesso effettuato, il nome utente dell'account.
• Edge utilizza gli stessi file. L'accesso ai suoi profili avviene con un account Microsoft o un account aziendale o dell'istituto di istruzione (Entra ID). Un account Microsoft può utilizzare come nome utente qualsiasi indirizzo email, anche di un altro fornitore; pertanto, un indirizzo in account_info di Edge identifica l'account di accesso al browser, non necessariamente una casella di posta utilizzata in una scheda.

Credenziali di accesso salvate, compilazione automatica e cookie

• Credenziali di accesso salvate. Il file Login Data di Chromium (SQLite, tabella logins) memorizza in chiaro origin_url, username_value, date_created, date_last_used e times_used; soltanto password_value è cifrato (su Windows con una chiave protetta da DPAPI, la Data Protection API che vincola i segreti alle credenziali di accesso dell'utente). Il file logins.json di Firefox conserva hostname in chiaro, ma cifra sia il nome utente sia la password con chiavi contenute in key4.db. In entrambi i casi, l'elenco dei siti con credenziali di accesso salvate è leggibile senza intervenire su alcuna password.
• Compilazione automatica e cronologia dei moduli. Il file Web Data di Chromium (tabella autofill: name, value, count, date_created, date_last_used) e il file formhistory.sqlite di Firefox (tabella moz_formhistory) registrano i valori digitati nei moduli, inclusi gli indirizzi email inseriti nei campi di accesso.
• Cookie per host. Il file Network\Cookies di Chromium e il file cookies.sqlite di Firefox mostrano quali host hanno impostato cookie, i nomi dei cookie e i rispettivi orari di creazione e ultimo accesso. I cookie di autenticazione (spesso chiamati genericamente cookie di sessione, sebbene la maggior parte sia persistente) indicano una sessione autenticata; Google, ad esempio, imposta cookie denominati SID, HSID e SAPISID su .google.com per gli utenti che hanno effettuato l'accesso. Nomi, host e orari sono sufficienti; i valori non servono e non devono essere utilizzati.

Identità a livello di Windows

• Account Microsoft collegato a Windows. Il valore InternetUserName dell'hive SAM fornisce l'indirizzo email (Lezione 2.2).
• Aggiunta a Entra ID. Su un sistema in esecuzione, dsregcmd /status riporta AzureAdJoined, il nome del tenant e l'ID del dispositivo. Nell'analisi offline, l'hive SYSTEM conserva le informazioni sull'aggiunta in ControlSet001\Control\CloudDomainJoin, dove sottochiavi quali JoinInfo e TenantInfo contengono valori che includono l'ID del tenant e, su molti sistemi, l'indirizzo email dell'utente che ha aggiunto il dispositivo.
• Chiavi delle identità Microsoft. HKCU\Software\Microsoft\IdentityCRL, utilizzata dai componenti di accesso agli account Microsoft, presenta spesso sottochiavi denominate con l'indirizzo dell'account. Office memorizza le identità con cui è stato effettuato l'accesso in HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities, con una sottochiave per identità contenente valori quali EmailAddress e ProviderId, che distingue un account Microsoft personale da un account aziendale o dell'istituto di istruzione.
• Gestione credenziali. Le credenziali Windows e web salvate si trovano in %LOCALAPPDATA%\Microsoft\Credentials e %APPDATA%\Microsoft\Credentials (un file protetto da DPAPI per voce) e in %LOCALAPPDATA%\Microsoft\Vault\<GUID>\ (Policy.vpol più file .vcrd). Nell'analisi offline, è possibile vedere che le voci esistono, quando sono stati scritti i file e quale chiave master DPAPI protegge ciascuno di essi; i nomi delle destinazioni e i segreti sono all'interno dei dati protetti. Durante un triage autorizzato su un sistema in esecuzione, cmdkey /list mostra i nomi delle destinazioni. La decifratura del materiale DPAPI richiede la password dell'utente (o materiale crittografico da essa derivato) oppure la chiave di backup DPAPI del dominio e deve essere esplicitamente inclusa nell'autorizzazione.

Tracce della webmail

URL e titoli delle pagine

Gli URL nella cronologia rivelano le azioni. Gmail inserisce la vista nel frammento dell'URL: mail.google.com/mail/u/0/#inbox, #sent, #inbox/<thread id> e ?compose=new quando si apre una finestra di composizione. Il segmento u/N rappresenta la posizione dell'account nella sessione multiaccount di quel browser (0 è il primo account con cui è stato effettuato l'accesso), non una proprietà fissa dell'account. Outlook sul web utilizza percorsi sotto /mail/ che indicano la cartella (ad esempio inbox o sentitems) e /mail/deeplink/compose per un nuovo messaggio, su outlook.live.com (personale) o outlook.office.com (aziendale o dell'istituto di istruzione). I titoli delle pagine nel database della cronologia spesso indicano la cartella o l'oggetto di un messaggio aperto, e i titoli di Gmail hanno comunemente incluso l'indirizzo dell'account. I fornitori modificano questi formati senza preavviso: trattare URL e titoli come indizi da corroborare, non come prove. Una visita alla cartella Posta inviata mostra che la cartella è stata visualizzata, non che sia stato inviato un messaggio.

Cache, download e notifiche

• Cache. Frammenti dei dati JSON e HTML recuperati dall'applicazione web possono rimanere nella cache del browser (Lezione 4.3): oggetti dei messaggi, indirizzi dei mittenti, estratti.
• Allegati scaricati. Gli allegati salvati in Download conservano un flusso Zone.Identifier i cui campi ReferrerUrl e HostUrl registrano la provenienza del file (Lezione 1.4). Gli allegati Gmail vengono distribuiti da mail-attachment.googleusercontent.com e l'URL stesso contiene un segmento u/N. La tabella dei download del browser aggiunge gli orari di inizio e fine.
• Notifiche. Se l'utente ha consentito le notifiche desktop, le notifiche popup di nuova posta vengono registrate in wpndatabase.db (Lezione 2.8), dove il campo XML Payload contiene spesso mittente, oggetto e prima riga, con ArrivalTime in formato FILETIME.

Archiviazione delle applicazioni web

Le applicazioni web conservano dati offline nel profilo: IndexedDB (Chromium: IndexedDB\https_mail.google.com_0.indexeddb.leveldb; Firefox: storage\default\https+++mail.google.com\idb\, SQLite), Local Storage (Local Storage\leveldb) e Service Worker CacheStorage (Service Worker\CacheStorage). IndexedDB e Local Storage di Chromium utilizzano LevelDB, un archivio chiave-valore composto da file .log e .ldb in cui i record sostituiti possono sopravvivere fino alla compattazione. La struttura dei dati è specifica di ciascuna applicazione e cambia tra le versioni; utilizzare quindi un parser compatibile con LevelDB (ad esempio la libreria gratuita ccl_chromium_reader) e leggere i record, anziché aspettarsi una casella di posta. La posta offline, quando abilitata, può lasciare qui molti corpi dei messaggi.

Applicazioni desktop di messaggistica e collaborazione

La maggior parte dei client desktop di messaggistica è costituita da applicazioni web all'interno di un contenitore (Electron o WebView2) e lascia gli stessi tipi di archivi. Slack conserva un profilo in stile Chromium in %APPDATA%\Slack, con IndexedDB, Local Storage (LevelDB) e una cache. Il nuovo client Microsoft Teams è un'applicazione in pacchetto i cui dati si trovano in %LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe, incluso un profilo WebView2 il cui IndexedDB utilizza LevelDB; il client classico utilizzava %APPDATA%\Microsoft\Teams. Anche WhatsApp Desktop è ora un'applicazione in pacchetto sotto %LOCALAPPDATA%\Packages, con database locali e cache multimediali; i suoi formati cambiano tra le versioni e possono essere cifrati. In tutti i casi, occorre aspettarsi una cronologia parziale conservata nella cache, non un archivio completo.

Il limite legale ed etico

Password, cookie e token salvati possono consentire l'accesso a un account attivo. Utilizzarli per accedere, o riutilizzare un cookie in un altro browser, è al di fuori dell'ambito di un esame dell'endpoint, a meno che l'autorizzazione non lo includa esplicitamente. Questa operazione accede a dati conservati sui server di altri soggetti, può modificarli (indicatori di lettura, registrazioni dell'ultimo accesso, avvisi di sicurezza) e può rendere inammissibili le prove. Invece:

• Documentare ciò che mostra l'endpoint: identità, host, orari, percorsi dei file, hash e schermate dei record analizzati, in linea con i requisiti di documentazione della norma ISO/IEC 27037.
• Inviare tempestivamente una richiesta di conservazione al fornitore, affinché i dati dell'account vengano mantenuti mentre si predispone la procedura formale.
• Ottenere la comunicazione dei dati da parte del fornitore tramite le procedure legali: dati dell'intestatario e dell'account, indirizzi IP e orari di accesso, dispositivi e contenuti.
• Con il consenso del titolare, far eseguire al titolare un'esportazione con Google Takeout o dell'account Microsoft in propria presenza; registrare i passaggi, quindi calcolare l'hash dell'archivio e conservarlo.

Esempio svolto: la webmail personale di ana

Una raccolta di triage include C:\Users\ana\AppData\Local\Microsoft\Edge\User Data\Default.

1. Identità. Preferences → account_info[0].email = ana.costa.personal@gmail.example. Poiché si tratta di Edge, questo è il nome di accesso al browser; suggerisce, ma non dimostra, l'utilizzo dell'account webmail con lo stesso indirizzo.
2. Cronologia. Le tabelle urls e visits mostrano https://mail.google.com/mail/u/1/#inbox?compose=new con visit_time 13417797340000000 e https://mail.google.com/mail/u/1/#sent con visit_time 13417797487000000, con il titolo "Posta inviata - ana.costa.personal@gmail.example - Gmail". I tempi di Chromium sono espressi in microsecondi dal 1601-01-01 UTC: 13417797487000000 ÷ 1.000.000 = 13.417.797.487 s; meno 11.644.473.600 = 1.773.323.887 secondi Unix = 2026-03-12T13:58:07Z. La visita alla finestra di composizione si converte allo stesso modo in 13:55:40Z, 2 min 27 s prima. Il titolo collega u/1 all'indirizzo in questa sessione.
3. Download. C:\Users\ana\Downloads\price-list-2026.xlsx presenta ZoneId=3, ReferrerUrl=https://mail.google.com/ e HostUrl=https://mail-attachment.googleusercontent.com/attachment/u/1/?…. La tabella dei download indica un orario di fine di 14:02:13Z, 4 min 6 s dopo la visualizzazione della Posta inviata. Il segmento u/1 corrisponde alla stessa posizione dell'account.
4. Notifica. wpndatabase.db contiene una notifica popup di Edge il cui payload riporta "Marco Ruiz · Re: listino prezzi · Grazie, ricevuto". ArrivalTime = 134177980110000000 (unità da 100 ns dal 1601): ÷ 10.000.000 = 13.417.798.011 s; meno 11.644.473.600 = 1.773.324.411 = 2026-03-12T14:06:51Z.

Quadro dell'account. L'utente Windows ana, con il profilo Edge Default, ha utilizzato l'account Gmail ana.costa.personal@gmail.example (secondo account nella sessione) tra le 13:55:40Z e almeno le 14:06:51Z del 12 marzo 2026: è stata aperta una finestra di composizione, è stata visualizzata la cartella Posta inviata, è stato scaricato un allegato ed è arrivata una notifica simile a una risposta. Dal fornitore occorrono il messaggio inviato vero e proprio (destinatari, contenuto, allegato, intestazioni), l'intera conversazione con Marco Ruiz, gli indirizzi IP di accesso e i dispositivi di quel giorno, i dati dell'intestatario e di recupero che dimostrino chi controlla l'account e l'identità dell'account u/0.

Focus sull'esame: È necessario saper indicare il file e il campo che identificano l'account con cui è stato effettuato l'accesso al browser (account_info in Preferences), convertire un valore Chromium o FILETIME in UTC e leggere il campo HostUrl di un flusso Zone.Identifier per stabilire che un allegato proviene dalla webmail. Occorre sapere a quali domande può rispondere soltanto il fornitore, in particolare riguardo agli indirizzi IP di accesso e ai contenuti completi, e che accedere con credenziali o cookie recuperati esula dall'esame dell'endpoint, salvo esplicita autorizzazione.

Punti chiave

• L'endpoint mostra che un account è stato utilizzato, da quale profilo Windows e del browser e quando; il contenuto è parziale e i dati sul lato del fornitore rimangono presso il fornitore.
• Identificare gli account tramite account_info di Preferences, Local State, origini delle credenziali di accesso salvate, compilazione automatica, host dei cookie, InternetUserName di SAM, CloudDomainJoin e chiavi Identity di Office.
• Gli URL della webmail, le posizioni u/N e i titoli delle pagine sono indizi da corroborare con download, Zone.Identifier e notifiche popup; i formati cambiano senza preavviso.
• IndexedDB e Local Storage nei browser basati su Chromium e nelle applicazioni Electron o WebView2 utilizzano LevelDB con strutture specifiche per ciascuna applicazione.
• Non utilizzare mai credenziali o cookie salvati per accedere a un account attivo senza un'autorizzazione esplicita; conservare, documentare e richiedere i dati al fornitore.