Nel contesto della DFIR (Digital Forensics and Incident Response) ci si imbatte spesso in scenari in cui i dati di interesse risultano assenti: retention policy troppo stringenti, tecniche di covering tracks attuate dall’attaccante o, più semplicemente, una gestione non ottimale dell’evento possono compromettere la possibilità di ricostruire in modo corretto e completo quanto accaduto, pregiudicando così la possibilità di dare compiuta risposta al quesito iniziale del cliente.
Capita frequentemente, soprattutto nei casi di Incident Response, che venga preclusa anche la possibilità di svolgere un’analisi forense della memoria volatile, spesso a causa di un isolamento non corretto dell’asset compromesso, ad esempio effettuato scollegando subito l’alimentazione elettrica prima di procedere con un’acquisizione a caldo del dato di interesse. Questo impedisce, tra le altre cose, di osservare i comportamenti dinamici del malware, come le comunicazioni con server di comando e controllo (C2) o altre azioni cruciali.
Proprio di recente ci siamo trovati a indagare un caso in cui il detentore dell’asset aveva deliberatamente cancellato registri e tracce digitali potenzialmente utili all’analisi, nel tentativo di non essere ricondotto alle attività fraudolente compiute. In particolare, l’utente aveva disabilitato i log di sistema, svuotato gli eventi di sicurezza di Windows e tentato di cancellare lo storico delle esecuzioni nel registro di sistema. Inoltre, aveva eliminato un account utente compromettente e modificato il timestamp su file sensibili nel tentativo di confondere l’analisi temporale degli eventi.
Eppure, come spesso accade – sia ad attaccanti che a (presunti) esperti di anti-forensics – ci si dimentica dell’esistenza di artefatti meno noti ma estremamente interessanti: uno su tutti, SRUM.
Una delle peculiarità di questo database ESE (Extensible Storage Engine) – tecnologia utilizzata anche da soluzioni come Active Directory, Microsoft Exchange, Microsoft Search e altri – è la capacità di registrare ogni eseguibile (.exe) avviato sul sistema, inclusi quelli successivamente cancellati. Il database conserva, tra le altre informazioni, il percorso completo da cui l’applicazione è stata eseguita e il SID dell’utente che l’ha lanciata, anche se quest’ultimo è stato successivamente eliminato.
Nel nostro caso, questa caratteristica ci ha permesso, all’interno della finestra temporale oggetto di analisi, di ricostruire l’utilizzo degli applicativi da parte dell’utente. In particolare, tali informazioni, incrociate con artefatti forensi come i Prefetch Files – che forniscono un timestamp delle ultime otto esecuzioni di un programma, ma non la durata dell’esecuzione – hanno consentito di tracciare con precisione la timeline dell’utilizzo di alcuni processi, identificando l’utente coinvolto e le attività di rete collegate (download/upload).
Questa preziosa fonte di informazioni tiene infatti anche traccia dell’utilizzo della rete: include il volume di dati inviati e ricevuti da ciascuna applicazione, specificando le connessioni di rete utilizzate (cablate o wireless). In casi come quello descritto, SRUM ha permesso di identificare il volume di dati esfiltrati e il periodo esatto in cui l’attività è avvenuta.
Cos’è SRUM
Nel mondo della DFIR lo SRUM (System Resource Usage Monitor) è un artefatto introdotto a partire da Windows 8, fondamentale per il sistema operativo, ma spesso trascurato nelle analisi forensi. Il suo database SRUDB.dat è archiviato in C:\Windows\System32\sru\ ed è, come dal racconto di cui sopra, una vera e propria miniera d’oro per i dati contenuti al suo interno e per la loro retention, che può arrivare fino a 90 giorni di attività.
Le informazioni vengono scritte nel database SRUM con cadenza oraria e al momento dell’arresto del sistema. Nel frattempo, i dati non ancora trasferiti nel database vengono temporaneamente mantenuti nel registro di sistema. Questo dettaglio è cruciale: a seconda del tempo trascorso tra l’attività analizzata e l’acquisizione forense, è possibile che le informazioni di interesse non siano ancora state salvate nel database e risultino quindi assenti durante l’analisi.
Su un sistema attivo, il file SRUM risulta ovviamente bloccato e non può essere copiato con le normali operazioni di copia/incolla. Tuttavia, in un’attività forense, l’artefatto può essere facilmente estratto operando su un’immagine del sistema acquisita in precedenza.
Uno degli strumenti più utilizzati per l’estrazione live del database SRUM è SRUM-DUMP, sviluppato da Mark Baggett (progetto disponibile su GitHub: https://github.com/MarkBaggett/srum-dump). Per effettuare acquisizioni live, lo strumento richiede privilegi amministrativi e si avvale di f-get.exe per creare una copia del file in uso.
SRUM-DUMP esporta i dati in un modello Excel predefinito, consentendo l’analisi del contenuto del database SRUM all’interno di un foglio di calcolo, utile come riferimento incrociato per validare i risultati ottenuti dagli ulteriori strumenti forensi utilizzati.
Conclusioni: Perché SRUM
Il database SRUM contiene una vasta gamma di artefatti e indicatori che possono rivelarsi estremamente utili durante un’analisi forense.
Attraverso di esso è possibile attribuire l’esecuzione di un processo a uno specifico utente, determinare il volume di dati trasmessi o esfiltrati, e ottenere una traccia delle esecuzioni di file binari, anche nel caso in cui questi siano stati successivamente cancellati dal sistema. Inoltre, SRUM offre una finestra temporale di esecuzione con una precisione di circa un’ora, basata sulle scritture periodiche del database.
Questo elemento può integrarsi con ulteriori evidenze raccolte nel corso dell’indagine, diventando un tassello prezioso a supporto dell’analisi e, in alcuni casi, un indicatore decisivo per la ricostruzione dell’accaduto.
SRUM rappresenta quindi una fonte ricchissima di informazioni, spesso sottovalutata ma capace di fare la differenza.
—
Kokishin DFIR Team
