biggiesmallsag/nighthawkresponse
Forensik-Framework für Incident Response
Maßgeschneiderte Anwendung zur asynchronen forensischen Datenpräsentation auf einem Elasticsearch-Backend.
Diese Anwendung ist dafür ausgelegt, eine Mandiant Redline "collections"-Datei zu importieren und Flexibilität bei Suche/Stapelung und Tagging zu bieten.
Die Anwendung entstand aus der Unfähigkeit, mehrere Untersuchungen (oder hunderte von Endpunkten) in einem einzigen Fenster zu verwalten.
Um Redline-Audits zu importieren, haben wir nightHawkResponse erstellt, eine vollwertige GOpher-Anwendung, die dieses Framework begleiten soll. Der Quellcode der Anwendung ist in diesem Repository verfügbar, eine Binärdatei wurde kompiliert und läuft innerhalb der ISO, bereit zum Importieren ab dem ersten Start.
Wir entwickeln derzeit eine neue Hauptversion und werden diese bis März 2020 veröffentlichen. Die neue Version zielt darauf ab, Folgendes zu erreichen.
Wir haben erkannt, dass es zu viele bewegliche Teile gab, um das gesamte Repository effektiv zu betreiben, Entitäten einfach zu verwalten und alles auf dem neuesten Stand zu halten. Wir glauben auch, dass die Kerndaten, die in Elastic gespeichert sind, von Kibana effektiver genutzt werden sollten, und so haben wir beschlossen, dies durch die Entwicklung eines Plugins zu verwirklichen, das dies neben Kibanas erstaunlichem Workflow tut.
Installation
API-Dokumentation folgt im Wiki
01/09/2016: Version 1.0.3
Features:
Video-Demonstration: nightHawk Response Platform
Um es den Benutzern von nightHawk einfach zu machen, haben wir eine ISO mit allem, was bereits eingerichtet ist, erstellt. Das bedeutet, Sie erhalten Folgendes;
/opt/nighthawk/etc/nightHawk.json. Systemstart:
Bevor Sie Ihre VM mit der mitgelieferten ISO erstellen, beachten Sie Folgendes;
Ausstehend: Einrichtung des Elastic-Dienstes als duale Knoten mit 1/4 des zugewiesenen Systemspeichers pro Knoten. Das bedeutet, wenn Sie 2 GB RAM zuweisen, hat jeder ES-Knoten 512 MB und dem System verbleibt 1 GB zum Betrieb.
Wenn Sie dies anders einstellen möchten, verbinden Sie sich per SSH mit der Box und konfigurieren Sie es nach Ihren Wünschen.
Es sollte mindestens 20 GB in Betracht gezogen werden. Eine Audit-Datei kann groß sein, daher wird empfohlen, viel Speicherplatz für die Aufnahme vieler Sammlungen bereitzustellen.
Ausstehend: Benutzerbasierte Speichereinrichtung für große Instanzen. Wenn Sie zusätzliche Partitionen einrichten möchten, können Sie dies selbst tun; einige Änderungen können vorgenommen werden, um den ES-Datenspeicher auf Ihre neue Partition zu verweisen.
Installation:
ISO herunterladen: nightHawk v1.0.3
Konfigurieren Sie die Hardware, mounten Sie die ISO in die VM, starten Sie das Installationsskript.
Sobald dies abgeschlossen ist, gehen Sie in Ihrem Browser (Chrome/FireFox) zu https://192.168.42.173.
Melden Sie sich mit 'nighthawk/nighthawk' am System an – klicken Sie auf "goto site", um zur Anwendung zu gelangen
Wenn Sie auf Kibana zugreifen müssen, gehen Sie zu https://192.168.42.173:8443.
Wenn Sie per SSH auf die Box zugreifen müssen, lauten die Anmeldedaten: admin/nightHawk.
Wenn Sie die IP-Adresse ändern möchten (anwendungsweit wirksam): /opt/nighthawk/bin/nighthawkctl set-ip <neue_ipadresse>
Das Redline Audit Collection Script befindet sich im Stammverzeichnis dieses Repos. Verwenden Sie es beim Einsatz des eigenständigen Redline-Collectors, da es die Dokumente zurückgibt, die Sie benötigen, um nightHawk korrekt zu befüllen.
Hochladen:
WICHTIG:
Erstellen einer Audit-Zip-Datei zum Hochladen (Eigenständiger Redline-Collector):
Schritt_1: Navigieren Sie zu Sessions\AnalysisSessionX\Audits<ComputerName>, wobei X die Analysenummer ist, die in den meisten Fällen 1 ist.
Schritt_2: Erstellen Sie ein Zip des Ordners, der die Audit-Dateien enthält, z.B. 20160708085733
Schritt_3: Laden Sie 20160708085733.zip hoch
WICHTIG: Verwendung einer vorhandenen HX-Audit-Datei (HX-Collector): FireEye HX-Audits haben eine Erweiterung, die auf .mans endet. Das Audit von HX unterscheidet sich vom Redline-Collector, da die zurückgegebene .mans-Datei tatsächlich eine Zip-Datei ist. Das bedeutet, es kann direkt hochgeladen werden, im Gegensatz zum Redline-Audit, bei dem Sie die obigen Anweisungen befolgen müssen.
Navigieren Sie zum "Upload"-Symbol in der Navigationsleiste, wählen Sie eine Audit-.zip-Datei (oder mehrere) aus, einen Fallnamen (andernfalls liefert das System einen) und senden Sie es ab. Wenn Sie unser Redline-Audit-Skript zum Erstellen Ihrer Sammlung verwendet haben, befolgen Sie die "Redline Collector"-Anweisungen direkt oben.
Nach der Verarbeitung erscheint der Endpunkt im Baumknoten "Current Investigations". Unter dem Endpunkt werden Ihnen alle für diesen Endpunkt verfügbaren Audit-Typen angezeigt. Die Upload-Funktion dieser Web-App erzeugt pOpen-Unterprozesse, die die GO-Anwendung aufrufen, um das Redline-Audit zu parsen und Daten in Elasticsearch zu pushen. Es gibt 2 Optionen zum Hochladen: eine sequentiell, die andere parallel.
Bitte beachten Sie: Parallele Uploads sind auf 5 gleichzeitig begrenzt und können ressourcenintensiv sein. Wenn Sie eine leistungsschwache Maschine haben, beschränken Sie die Nutzung dieser Funktion auf 2-3.
Tagging:
Sie können auf jede Zeile in einer Tabelle (in der Antwortansicht) klicken, um diese Daten zu taggen. Nach dem Taggen können Sie die Kommentare in der Kommentaransicht anzeigen.
Elasticsearch:
Es gibt benutzerdefinierte Mappings (im Git-Stammverzeichnis bereitgestellt) und Hinweise zu Folgendem;
Dokumente werden über die GO-App als Parent/Child-Beziehung indiziert. Dies wurde gewählt, weil es einen relativ logischen Pfad zur Ansicht von Dokumenten bietet, d.h. der Parent ist der Endpunktname und die Kinder sind Audit-Typen. Auch die Durchführung von Aggregationen auf einem Parent/Child-beziehungsdokument scheint sinnvoll zu sein. Das Stapelungs-Framework baut darauf auf, Parents in einem Array zu erstellen, um dann alle Child-Dokumentaggregationen für bestimmte Audit-Typen zu erhalten.
Elasticsearch-Setups erfordern Tuning und richtiges Designverständnis. Sharding ist wichtig zu verstehen, aufgrund der Art und Weise, wie wir Parent/Child-Dokumente verknüpfen. Das Child wird IMMER zum Parent geroutet, es kann nicht eigenständig existieren. Das bedeutet, dass berücksichtigt werden muss, wie viele Shards sich auf dem Index befinden. Nach unserem Verständnis kann es ratsam sein, ein Setup mit vielen Knoten mit einzelnen Shards zu wählen. Um die Leistung eines solchen Setups zu verbessern, arbeiten wir an Shard-Routed-Suchen.
Wir arbeiten derzeit daran, die bestmögliche Konfiguration für schnelle Suchen zu entwerfen.
Diese Anwendung ist darauf ausgelegt, enorm zu skalieren. Vom ersten Designkonzept an konnten wir sie reibungslos auf einer Single-CPU-2GB-Ubuntu-VM mit 3 ES-Knoten (Macbook Pro) mit etwa 4 Millionen+ Dokumenten (oder 50 aufgenommenen Endpunkten) betreiben. Wenn Sie in Produktion gehen, können Sie mit einem Setup von 64/128 GB RAM und SAS-Speicher eine blitzschnelle Antwortzeit beim Abruf von Dokumenten aufrechterhalten, während viele Analysten gleichzeitig an der Anwendung arbeiten.
Überlegungen:
DataTables gemischte Verarbeitung:
Es gibt mehrere Audit-Typen, die zu groß sind, um alle Dokumente an die Tabelle zurückzugeben. Zum Beispiel können URL-Verlauf und Registrierung 15.000 Dokumente an das DOM zurückgeben, was den Client-Browser belasten würde. Um dem entgegenzuwirken, verwenden wir serverseitige Verarbeitung, um durch die Ergebnisse bestimmter Audit-Typen zu blättern. Das bedeutet, dass Sie auch über Dokumente in Audit-Typen mit Elasticsearch im Backend suchen können.
Tagging:
Derzeit können wir Dokumente taggen und diese Kommentare anzeigen. Wir können sie aktualisieren oder ändern. Der Analyst kann dem Dokument Kontext wie Datum/Analystenname/Kommentar geben.
Abhängigkeiten (alle vorinstalliert):
elasticsearch-dsl.py
django 1.8
python requests
To Do:
Process Handles (in Arbeit).
Zeitauswahl-Schieberegler für zeitbasierte Generatoren (in Arbeit).
Kontextmenü für aktuelle/vorherige Untersuchungen.
Tagging-Kontext. Das Tagging-System wird in eine Websocket-Schleife für Live-Kommentare über Analystenfenster hinweg integriert (in Arbeit).
Anwendungskontext.
Möglichkeit, Endpunkte zwischen beiden Kontexten zu verschieben.
Möglicherweise Neugestaltung des Knotenbaums, um untersuchungsdatumsgesteuert zu sein.
Selektives Stapeln, derzeit ist der Root-Knoten-Selektor aktiviert.
Shard-Routing-Suchen.
Redline Audit-Skriptvorlage.
Umfassendere Integration mit AngularJS (in Arbeit).
Responsive Design. (in Arbeit).
Administrative Steuerseite zur Konfiguration der Kerneinstellungen (in Arbeit).
Autoren & Hinweise:
Wir suchen immer nach Gleichgesinnten, die zu diesem Projekt beitragen möchten. Wir sind keineswegs Webdesign-Gurus. Wenn Sie denken, dass wir etwas besser machen können, fordern Sie bitte einen Pull-Request an, und wenn es uns gefällt, werden wir ihn mergen.
Daniel Eden & Roshan Maskey
Danksagungen:
Mandiant Redline devs, AngularJS, Django devs, Angular-DataTables/DataTables, D3 (Bostock), Elasticsearch/ES-dsl.py, jsTree, qTip, GOlang, Python, Fahad Abdulaal (Logo/Video).
