Con la sigla DFIR (Digital Forensics e Incident Response) si indica il campo della cyber security focalizzato sull’utilizzo delle tecniche di digital forensics nella risposta agli incidenti di sicurezza applicabili grazie a diversi strumenti sia proprietari sia open source come Velociraptor, un tool relativamente nuovo ma dalle grandi potenzialità.
D’altronde, poiché nella risposta agli incidenti di sicurezza il tempo è un fattore critico, la capacità delle aziende di raccogliere e analizzare rapidamente e in maniera automatizzata dati di valore provenienti da una moltitudine di sistemi è fondamentale.
Ciò permette di identificare, isolare e neutralizzare in maniera proattiva ed iterativa le minacce più avanzate, aumentare l’efficacia della risposta minimizzando i danni, ricostruire i comportamenti degli attaccanti, produrre evidenze che permettano eventualmente di perseguire gli autori degli attacchi.
Information security continuous monitoring: le linee guida per una sicurezza “continua”
Indice degli argomenti
Cos’è Velociraptor
Velociraptor, come dicevamo, è un tool DFIR open source prodotto da Velocidex, società creata proprio a questo scopo da Michael Cohen, già noto per aver contribuito a tool come Volatility, e per aver poi guidato, all’interno di Google,i team che hanno creato tool open source piuttosto noti, come Rekall e Google Rapid Response (GRR).
Velociraptor, fortemente influenzato sia dalle precedenti creazioni di Michael Cohen che da OSQuery, è un tool che permette il collezionamento rapido di indicatori di compromissione (IOC) e il rilevamento di intrusioni attraverso migliaia di host. Quando viene rilevato un host sospetto, possono essere effettuate analisi più precise, come ad esempio localizzare e recuperare file o qualsiasi evidenza di interesse, eseguire ricerche mirate e anche lanciare shell interattive.
Il tool è stato progettato con l’obiettivo della flessibilità, ottenuta attraverso l’utilizzo del linguaggio VQL (Velociraptor Query Language), costruito allo scopo.
Velociraptor si affida al linguaggio VQL sia per il collezionamento una tantum di dati dagli endpoint (chiamati anche client) in maniera mirata, per il monitoraggio continuo e la risposta degli endpoint, sia per controllare e gestire il server Velociraptor.
Architettura di Velociraptor
L’architettura di Velociraptor è molto semplice, essendo basata su un unico eseguibile utilizzato da tutte le componenti.
I componenti, come mostrato nella figura sottostante, sono i client (asset), dove è in esecuzione un servizio che riceve query VQL dal server e restituisce al server i risultati della query. Sul server sono presenti un frontend, il quale riceve le connessioni dai client, gestisce le code dei messaggi per i client e processa le risposte provenienti dai client, e una console di amministrazione web, la quale consente di schedulare nuovi flussi, di ispezionarne i risultati e di visualizzare i file system virtuali dei client.
Velociraptor è stato progettato per essere efficiente e scalabile; per questo motivo l’elaborazione viene svolta sui client e il server è progettato per essere veloce e scalabile, gestendo la concorrenza e limitando l’utilizzo della banda di rete.
Il deploy di Velociraptor
Velociraptor può essere scaricato dall’apposito repository GitHub dove, oltre ai sorgenti, è possibile trovare i binari per Linux, Windows, MacOs e FreeBSD. Seguendo il link che porta all’ultima versione, al momento la 0.6.3, potremmo per esempio scaricare l’eseguibile Windows (velociraptor-v0.6.3-windows-amd64.exe) e avviare la GUI in modalità standalone in un sistema Windows attraverso il comando:
velociraptor.exe gui
Oltre che per testare il tool e apprenderne le funzionalità, la modalità standalone può essere utile per il triage di sistemi sospetti nel caso non si abbia un server.
Per il deploy del tool secondo lo schema precedente può essere utile, sia per la versione server che per la versione client, creare un pacchetto di installazione specifico per il sistema in cui verrà installato, comprensivo di file di configurazione.
I file di configurazione, sia la versione server che la versione client, possono essere generati attraverso un wizard lanciato con una qualsiasi versione del solito eseguibile. Durante il wizard verrà scelta la tipologia di sistema di destinazione (server), la tipologia di certificato da utilizzare, almeno un account amministrativo, i path del datastore e dei log, il nome del file di configurazione per il server e per il client.
In questo esempio, in cui abbiamo utilizzato l’eseguibile Linux, intendiamo utilizzare un sistema Linux per la parte server e un certificato self-signed; intendiamo, inoltre, definire un utente amministratore denominato admin (di cui abbiamo il wizard che ci ha permesso di impostare la password).
Ulteriori utenti con altri ruoli possono essere creati successivamente. Per un utilizzo Enterprise sarà opportuno utilizzare un certificato firmato da una CA reale e utilizzare un sistema di SSO per l’autenticazione, tutte opzioni che il wizard ci permette.
Con il certificato self-signed la GUI sarà accessibili in HTTPS sulla porta 8889 solo sull’indirizzo di loopback 127.0.0.1. Al termine del wizard avremo creato un file di configurazione per il server (server.config.yaml) e uno per i client (client.config.yaml).
A questo punto creiamo il pacchetto di installazione per la parte server, supponendo che vogliamo utilizzare a tale scopo una distribuzione derivata da Debian.
Attraverso il comando in figura abbiamo quindi generato un pacchetto .deb che ha inglobato il file di configurazione. Tale pacchetto potrà quindi essere copiato e poi installato sul nostro server, con il comando
dpkg -i velociraptor_0.6.2-1_server.deb
Dopo l’installazione il servizio può essere gestito attraverso il comando systemctl.
Per quel che riguarda l’installazione del client su Windows, sul repository GitHub è presente un pacchetto di installazione .msi che non contiene file di configurazione. Per generare un pacchetto di installazione per Windows che comprenda il file di configurazione è necessario scaricare dal repository GitHub del tool l’eseguibile per Windows e anche i sorgenti del tool.
Dallo ZIP dei sorgenti estrarre il contenuto della directory velociraptor-0.6.3docswix. Qui sono contenuti script e file di configurazione in xml che permettono, a partire dall’eseguibile e dal file di configurazione client, la generazione del pacchetto. Per fare ciò viene utilizzato wixtoolset, che deve essere installato, scaricandolo da qui.
Il seguente esempio mostra i dettagli della generazione del pacchetto msi e della sua installazione.
A questo punto, sul client verrà creato un servizio Windows avviato automaticamente, che si connetterà al server precedentemente avviato. Sulla GUI è quindi possibile verificare la corretta comunicazione con il client.
Di default, una volta instaurata la comunicazione, il server colleziona alcune informazioni di alto livello su endpoint. Tali informazioni possono essere visualizzate facendo clic prima sul Client ID e poi su VQL Drilldown.
Naturalmente, in un ambiente Enterprise, una volta ottenuto il pacchetto msi, tale pacchetto potrà essere distribuito su tutti i client attraverso il tool di software distribution utilizzato aziendalmente.
Il linguaggio VQL
Come detto nell’introduzione, il Velociraptor Query Language (VQL) svolge un ruolo centrale all’interno del tool, tanto che il tool può essere definito essenzialmente come un “VQL evaluator engine”.
La presenza di un linguaggio di interrogazione permette di andare oltre gli schemi predefiniti di analisi, dando la possibilità di costruire analisi ad hoc adatte al contesto di investigazione e di combinare in maniera dinamica i risultati di analisi effettuati su diverse tipologie di artefatti forensi.
Si pensi al caso in cui venga rilasciato un IOC per rilevare una nuova minaccia; attraverso VQL è possibile costruire rapidamente un nuovo artefatto attraverso il quale rilevare segni di compromissione all’interno di tutti gli endpoint.
Il formato di una query VQL è il seguente:
SELECT X,Y,Z FROM plugin(arg=1) WHERE X=1
dove:
- SELECT X,Y,Z: effettua una selezione sulle colonne;
- plugin(arg=1): viene invocato un plugin, ovvero il componente che genera le righe, il quale potrebbe richiedere argomenti obbligatori oppure facoltativi. Si tratta delle principali sorgenti di dati di VQL;
- WHERE X=1: specifica una condizione di filtraggio.
Le query VQL possono essere costruite ed eseguite in modalità interattiva nella GUI del tool, selezionando il client dove si vuole eseguire la query, cliccando sul tasto _Shell e poi selezionando VQL dalla casella a discesa. Supponiamo di voler selezionare il nome, il path e il PID dell’agente velociraptor in esecuzione sul client. La query per ottenere ciò è la seguente:
SELECT Name, PID, Exe from pslist() WHERE Commandline ~= ‘velociraptor.exe’
Dove il ~= rappresenta un’espressione regolare.
All’interno della GUI è possibile utilizzare il punto interrogativo per mostrare la lista delle funzioni, dei plugin e degli argomenti dei plugin.
Naturalmente è possibile procedere per approssimazioni prima di impostare i filtri o le colonne desiderate.
Il risultato finale sarà il seguente:
Il risultato della query può essere esportato in formato json o csv; il json della risposta può essere anche ispezionato all’interno della GUI.
La sintassi della query prevede che le stringhe siano delimitate da “ oppure ‘, che le stringhe su più righe siano delimitate da ‘’’ e che le subquery siano delimitate da {}. Gli array sono delimitati da () o da [].
Poiché VQL non possiede l’operatore JOIN, possiamo combinare più query attraverso il plugin foreach(). Questo plugin permette di eseguire una query (data dall’argomento row) e, per ogni riga generata da tale query, eseguire una nuova query (data dall’argomento query).
Supponiamo per esempio di voler estrarre le socket di rete in ascolto su una porta, utilizzando il plugin netstat(). Potremmo farlo con la query:
select Laddr.IP as IP, Laddr.Port as Port, Pid, FamilyString, TypeString from netstat() where Status = ‘LISTEN’
Il plugin netstat() espone il pid del processo che attiva la socket (Pid), ma non il suo nome. Se volessimo far apparire il nome del processo nel risultato della query potremmo combinare la query appena vista con un’altra query che sfrutti il plugin pslist() appena visto, attraverso il plugin foreach(). La query diventerebbe quindi:
select * FROM
foreach (row = {select Laddr.IP as IP, Laddr.Port as Port, Pid, FamilyString, TypeString from netstat() where Status = ‘LISTEN’},
query = {select IP, Port,FamilyString, TypeString, Exe from pslist(pid=Pid)}
) ORDER BY IP
Il virtual file system
Uno strumento importante per collezionare informazioni su un singolo client ed eventualmente recuperare file dal client è il virtual file system (VFS), raggiungibile dalla GUI, dopo aver selezionato il client da cui vogliamo raccogliere informazioni e avere cliccato su VFS.
Le tipologie di informazioni che possono essere raccolte da questa interfaccia sono:
- File Access: accesso al file system utilizzando le API del sistema operativo;
- NTFS (solo per Windows) accesso al file system a basso livello utilizzando i costrutti del file system NTFS;
- Registry (solo per Windows): accesso al registry di Windows utilizzando le API del registry.
In generale, una volta selezionata la directory, affinché siano effettivamente mostrati i file contenuti, occorre fare un refresh della directory attraverso uno degli appositi tasti: il primo permette il refresh della directory attraverso un sync con il client, il secondo il refresh ricorsivo, il terzo il refresh ricorsivo scaricando sul server i contenuti della directory del client.
Per lo stesso file la vista NTFS rende disponibili maggiori informazioni rispetto a quelle disponibili attraverso la vista File Access, come per esempio le informazioni relative ai timestamp del filename.
Il seguente screenshot mostra come attraverso la vista NTFS siano disponibili anche le informazioni sulla Master File Table (MFT), la principale struttura dati del file system NTFS, ovvero il registro dei metadati di tutti i file del file system.
Dal VFS è possibile scaricare sul server il contenuto dei file, che potrà quindi essere visualizzato attraverso la GUI, come fatto per la MFT nell’esempio seguente.
Il VFS utilizzato per l’accesso al registry mostra le chiavi come directory e i valori come file. Nel caso del registry, poiché i valori sono tipicamente piccoli, non è necessario il refresh della directory.
Il seguente screenshot mostra le chiavi contenute in HKEY_USERS[SID]SOFTWARESysinternals, ossia i tool di Sysinternal presumibilmente utilizzati sul PC (ovvero, per i quali è stata accettata al EULA al primo utilizzo).
Gli artefatti
Abbiamo visto come il linguaggio VQL sia una componente fondamentale di Velociraptor e come attraverso le query VQL sia possibile recuperare informazioni importanti e analizzare interattivamente un client. Potrebbe quindi essere molto utile poter salvare le query definite, aggiungervi dei parametri da impostare in fase di esecuzione, aggiungere descrizioni che ne rendano più chiaro lo scopo e riutilizzarle con altre query VQL.
A tale scopo all’interno di Velociraptor sono presenti gli artefatti, file in formato YAML che contengono una query VQL, una descrizione comprensibile dello scopo, i parametri da impostare in fase di esecuzione. Gli artefatti possono essere eseguiti sugli endpoint e restituiscono dati in formato leggibile.
Nell’installazione di default Velociraptor fornisce un certo numero di artefatti predefiniti, ma è possibile crearne di nuovi, anche a partire da quelli predefiniti e, come avviene spesso nel mondo dell’open source, è possibile rendere pubblici i propri artefatti, così come utilizzare artefatti creati da altri utenti.
Nello screenshot seguente vediamo la definizione dell’artefatto Windows.Forensics.Prefetch, attraverso il quale è possibile estrarre dai client evidenze degli eseguibili lanciati con i relativi timestamp di esecuzione.
Hunt Manager
Il passaggio successivo è l’utilizzo degli artefatti per effettuare il cosiddetto hunting, ovvero recuperare informazioni su tutti gli endpoint gestiti. È attraverso questa funzionalità che Velociraptor dà il meglio di sé. Una volta individuato un pattern seguito dagli avversari, si possono scrivere query VQL mirate all’individuazione di tali pattern, testarle in modalità interattiva, trasformarli in artefatti, utilizzare tali artefatti per operazioni di hunting, analizzare i risultati ed eventualmente rendere le ricerche più mirate ricominciando il ciclo.
Un Hunt è un contenitore logico per diverse collezioni individuali: tutte le collezioni possono essere scaricate contemporaneamente, vedere quanti endpoint partecipano, selezionare gli endpoint che partecipano in base ad alcune condizioni, come etichette o sistema operativo. Gli endpoint che non sono attivi al momento in chi l’hunt viene lanciato verranno raggiunti dall’hunt nel momento in cui si attiveranno. Il risultato dell’hunt cambia quindi di continuo e in questo modo può essere necessario ripetere il download per ottenere la versione aggiornata dei risultati.
Nell’esempio seguente mostriamo un hunt generato a partire dall’artefatto Windows.Forensics.Prefetch mostrato sopra.
I risultati possono essere analizzati filtrandoli nel notebook che mostra i risultati, utilizzando query VQL, utilizzando per esempio il plugin hunt_results. Una volta soddisfatti del risultato è possibile esportare l’intero notebook come html o come file zip (ogni tabella è un json) o esportando le singole tabelle in formato come CSV o json.
Monitoraggio dei client
L’ultimo passo che mostriamo qui è quello di utilizzare gli hunt per il monitoraggio degli endpoint. A tale scopo sono presenti alcuni plugin, chiamati “Event VQL Plugins”, che si mantengono costantemente in esecuzione per un certo periodo di tempo. La query che utilizza tale plugin restituisce quindi dei risultati parziali finché non viene terminata. Esempi di questo tipo di plugin sono wait_evtx(), watch_evtx().
A partire dalle query che utilizzano questo tipo di plugin è quindi possibile definire artefatti che rimangano in esecuzione in attesa di eventi che si verificano sui client, inviandoli al server quando si realizzano.
Infine, attraverso le API esposte da Velociraptor e l’integrazione con prodotti di terze parti, è possibile impostare azioni di risposta.
Il seguente esempio mostra un esempio di monitoraggio delle query DNS effettuate dal client.
Conclusioni
Il vero valore di Velociraptor è la possibilità di combinare gli artefatti predefiniti, utilizzati per raccogliere su larga scala le principali evidenze forensi, con altre query VQL che arricchiscono l’output, in modo da restringere l’ambito delle analisi e ridurre il numero di falsi positivi.
Questo approccio mirato è importante nell’hunting su larga scala, in quanto permette da un lato di automatizzare la raccolta di artefatti e di ridurre dall’altro lato la quantità di dati raccolti, aiutando l’analista a concentrarsi sulle evidenze veramente importanti.
