Framework forense per la risposta agli incidenti
Applicazione personalizzata per la presentazione asincrona di dati forensi su un backend Elasticsearch.
Questa applicazione è progettata per ingerire un file di "collezioni" Mandiant Redline e offrire flessibilità nella ricerca/stack e nell'etichettatura.
L'applicazione è nata dall'impossibilità di controllare più indagini (o centinaia di endpoint) in un unico pannello di controllo.
Per ingerire gli audit Redline, abbiamo creato nightHawkResponse, un'applicazione GOpher completamente funzionante progettata per accompagnare questo framework. Il codice sorgente dell'applicazione è disponibile in questo repository, un binario è stato compilato ed è in esecuzione all'interno dell'ISO, pronto per l'ingestione dal primo avvio.
Stiamo attualmente sviluppando una nuova versione principale e la rilasceremo entro marzo 2020. La nuova versione mira a realizzare quanto segue.
Ci siamo resi conto che c'erano troppe parti in movimento per operare efficacemente l'intero repository, gestire facilmente le entità e mantenere tutto aggiornato. Riteniamo inoltre che i dati principali residenti in Elastic dovrebbero essere utilizzati più efficacemente da Kibana, e così abbiamo deciso di rendere questa realtà sviluppando un plugin che faccia questo insieme al flusso di lavoro incredibile di Kibana.
Installazione
La documentazione API seguirà nel Wiki
01/09/2016: Version 1.0.3
Funzionalità:
Video dimostrativo: nightHawk Response Platform
Per rendere le cose semplici per gli utenti di nightHawk, abbiamo creato un ISO con tutto già pronto all'uso. Ciò significa che ottieni quanto segue;
/opt/nighthawk/etc/nightHawk.json. Avvio del sistema:
Prima di creare la tua VM con l'ISO fornito, considera quanto segue;
In sospeso: Configurare il servizio Elastic per avere due nodi con 1/4 della memoria di sistema allocata per nodo. Ciò significa che se gli dai 2GB di RAM, ogni nodo ES avrà 512mb e il sistema rimarrà con 1GB per operare.
Se vuoi impostare questo in modo diverso, fai ssh nella macchina e configuralo come desideri.
Un minimo di 20GB dovrebbe essere considerato. Un file di audit può essere grande, quindi è consigliabile allocare molto spazio di archiviazione per gestire l'ingestione di molte collezioni.
In sospeso: Configurazione dello storage basato su utente per istanze su larga scala. Se desideri configurare partizioni extra, puoi farlo da solo, è possibile apportare alcune modifiche per puntare l'archiviazione dati ES alla tua nuova partizione.
Installazione:
Scarica ISO: nightHawk v1.0.3
Configura l'hardware, monta l'ISO nella VM, avvia lo script di installazione.
Una volta completato, nel tuo browser (Chrome/FireFox), vai a; https://192.168.42.173.
Accedi al sistema con 'nighthawk/nighthawk' - clicca "goto site" per entrare nell'applicazione
Se hai bisogno di accedere a Kibana, vai a; https://192.168.42.173:8443.
Se hai bisogno di fare SSH nella macchina, i dettagli di login sono; admin/nightHawk.
Se vuoi cambiare l'indirizzo IP (riflesso a livello di applicazione); /opt/nighthawk/bin/nighthawkctl set-ip <new_ipaddress>
Lo script di raccolta audit Redline si trova nella radice di questo repository. Usalo quando utilizzi il collector Redline standalone perché restituirà i documenti necessari per popolare correttamente nightHawk.
Upload:
IMPORTANTE:
Creazione del file zip di audit da caricare (Collector Redline standalone):
step_1: Navigare a Sessions\AnalysisSessionX\Audits<ComputerName> dove X è il numero dell'analisi che è 1 per la maggior parte dei casi.
step_2: Creare uno zip della cartella contenente i file di audit, ad esempio 20160708085733
step_3: Caricare 20160708085733.zip
IMPORTANTE: Usare il file di audit HX esistente (Collettore HX): Gli audit di FireEye HX hanno un'estensione che termina in .mans. L'audit di HX differisce dal collector Redline perché il .mans che restituisce è in realtà un file zip. Ciò significa che può essere caricato direttamente, a differenza dell'audit Redline per il quale è necessario seguire le istruzioni sopra.
Navigare all'icona "Upload" sulla barra di navigazione, selezionare un .zip di audit (o più), un nome caso (altrimenti il sistema ne fornirà uno) e inviare. Se hai usato il nostro script di audit Redline per costruire la tua collezione, segui le istruzioni "Redline Collector" appena sopra.
Una volta elaborato, l'endpoint apparirà nel nodo ad albero "Current Investigations". Sotto l'endpoint ti verranno presentati tutti i tipi di audit disponibili per quell'endpoint. La funzione di upload di questa web app avvia sottoprocessi pOpen che chiamano l'applicazione GO per analizzare l'audit Redline e inserire i dati in Elasticsearch. Ci sono 2 opzioni per il caricamento: una è sequenziale, l'altra è concorrente.
Nota bene: I caricamenti concorrenti sono limitati a 5 alla volta e possono essere intensivi in termini di risorse; se hai una macchina poco potente, limita l'uso di questa funzionalità a 2-3.
Etichettatura:
Puoi cliccare su qualsiasi riga in qualsiasi tabella (nella vista risposta) per etichettare quei dati. Una volta etichettati, puoi visualizzare i commenti nella vista commenti.
Elasticsearch:
Ci sono mappature personalizzate (fornite nella radice di git) e commenti consultivi su quanto segue;
I documenti vengono indicizzati tramite l'app GO come relazione genitore/figlio. Questa scelta è stata fatta perché è in grado di fornire un percorso relativamente logico per visualizzare i documenti, ad esempio il genitore è il nome dell'endpoint e i figli sono i tipi di audit. Eseguire aggregazioni su un documento relazionale genitore/figlio su larga scala sembra avere senso anche. Il framework di stacking si basa sulla costruzione di genitori in un array per poi ottenere tutte le aggregazioni dei documenti figli per determinati tipi di audit.
Le configurazioni di Elasticsearch richiedono ottimizzazione e un corretto riconoscimento del design. Lo sharding è importante da capire a causa del modo in cui colleghiamo i documenti genitore/figlio. Il figlio è SEMPRE instradato al genitore, non può esistere da solo. Ciò significa che è necessario considerare quanti shard sono presenti sull'indice. Da quello che abbiamo capito, potrebbe essere saggio scegliere una configurazione che incorpori molti nodi con singoli shard. Per ottenere prestazioni da questo tipo di configurazione stiamo lavorando su ricerche instradate per shard.
Stiamo attualmente lavorando per progettare la migliore configurazione possibile per una ricerca veloce.
Questa applicazione è progettata per scalare enormemente. Dal concetto iniziale di design, siamo stati in grado di eseguirla senza problemi su una VM Ubuntu a singola CPU con 2GB di RAM e 3 nodi ES (Macbook Pro), con circa 4 milioni+ di documenti (o 50 endpoint ingeriti). Se si passa alla produzione, eseguendo una configurazione con 64/128GB di RAM e storage SAS, sarebbe possibile mantenere un tempo di risposta fulmineo sul recupero dei documenti con molti analisti che lavorano contemporaneamente sull'applicazione.
Considerazioni:
Elaborazione mista DataTables:
Ci sono diversi tipi di audit ingeriti che sono troppo grandi per restituire tutti i documenti alla tabella. Ad esempio, la cronologia URL e il Registro di sistema possono restituire 15k documenti al DOM, il che metterebbe sotto stress il browser del client. Per contrastare questo, stiamo usando l'elaborazione lato server per impaginare i risultati di determinati tipi di audit. Ciò significa che puoi anche cercare nei documenti in base al tipo di audit utilizzando Elasticsearch nel backend.
Etichettatura:
Attualmente possiamo etichettare i documenti e visualizzare quei commenti. Possiamo aggiornarli o modificarli. L'analista è in grado di fornire contesto come Data/Nome Analista/Commento al documento.
Dipendenze (tutte preinstallate):
elasticsearch-dsl.py
django 1.8
python requests
Da fare:
Gestione degli handle (in corso).
Slider di selezione del tempo per generatori basati sul tempo (in corso).
Menu contestuale per le indagini correnti/precedenti.
Contesto di etichettatura. Il sistema di etichettatura si integrerà in un loop websocket per commenti in tempo reale tra i pannelli degli analisti (in corso).
Contesto dell'applicazione.
Possibilità di spostare gli endpoint tra i due contesti.
Possibile riprogettazione dell'albero dei nodi per essere guidato dalla data dell'indagine.
Stacking selettivo, attualmente il selettore del nodo radice è abilitato.
Ricerche instradate per shard.
Modello di script per audit Redline.
Integrazione più estesa con AngularJS (in corso).
Design responsive. (in corso).
Pagina di controllo amministrativo per la configurazione delle impostazioni core (in corso).
Autori e Note:
Siamo sempre alla ricerca di persone con la stessa mentalità che vogliono contribuire a questo progetto, non siamo affatto guru del web design, se pensi che possiamo fare qualcosa di meglio, per favore richiedi un pull e se ci piace, lo uniremo.
Daniel Eden & Roshan Maskey
Crediti:
Mandiant Redline devs, AngularJS, Django devs, Angular-DataTables/DataTables, D3 (Bostock), Elasticsearch/ES-dsl.py, jsTree, qTip, GOlang, Python, Fahad Abdulaal (Logo/Video).
