Daten aus dem Bedrohungsstapel für benutzerdefinierte Analysen exportieren
Threat Stack heißt jetzt F5 Distributed Cloud App Infrastructure Protection (AIP). Beginnen Sie noch heute damit, Distributed Cloud AIP mit Ihrem Team zu verwenden.
Wurde dieser Host kompromittiert? Hat dieser Host das schon immer gemacht?
Jeder, der im Bereich Betrieb/Technik/Sicherheit gearbeitet hat, hatte schon einmal einen oder mehrere Server, die ein unerwartetes Verhalten zeigten. Es führt möglicherweise seltsame Prozesse aus, verbraucht mehr Speicher als erwartet, akzeptiert Anfragen, stellt Verbindungen zu GitHub her usw.
Der erste Schritt zur Priorisierung eines Ereignisses besteht darin, zu wissen, dass Sie eines haben. Es gibt eine Reihe von Datenquellen, die Sie möglicherweise auf einen bestimmten Hostserver verweisen können:
- Überwachungstools, die beispielsweise Festplatten- und Speicherplatz messen
- Sicherheits-Einbruchserkennungssysteme generieren Alarme
- Application zeigen Fehler beim Erreichen bestimmter Hosts an
An diesem Punkt gibt es einen Server, zu dem wir gehen und über den wir weitere Informationen erhalten möchten. Unter der Annahme, dass nicht alle Systemdaten unbedingt in unser SIEM passen, besteht der nächste logische Schritt darin, eine Verbindung mit dem Host herzustellen und das Betriebssystem direkt nach seinen Aktivitäten abzufragen. Abhängig davon, wie gut Sie mit der Umgebung vertraut sind, kann dies so allgemein gehalten sein wie Tools wie uname und vmstat oder so spezifischere Elemente wie ps und lsof. In beiden Fällen wird Ihnen angezeigt, was der Host gerade tut. Hier ist das Problem bei diesem Vorgang: Der aktuelle Zustand interessiert Sie eigentlich nicht, Sie möchten wissen, was sich geändert hat. Ähnlich wie beim Erhalten einer Pull-Anfrage in Git möchten Sie nicht die gesamte Codebasis überprüfen, sondern nur die Teile, die geändert wurden.
Datenportabilität zu Amazon S3
Hier im Threat Stack Cloud SecOps Program℠ haben die Sicherheitsanalysten in unserem SOC eine Lösung entwickelt, die uns hilft, diese Art von Fragen für unsere Kunden zu beantworten. Die Threat Stack Cloud Security Platform® verfügt über diese praktische Funktion, die wir Datenportabilität nennen. Auf einer hohen Ebene ermöglicht uns dies, die von Hosts gesammelten Telemetriedaten (einschließlich ausgeführter ausführbarer Dateien, Benutzer, Befehlszeilenargumente, Verbindungen usw.) in S3-Buckets zu speichern.
Das Tolle an S3-Blobs ist, dass sie eine kostengünstige Möglichkeit darstellen, große Datenmengen zu speichern. Das Problem besteht darin, dass große Mengen nicht indizierter Daten genutzt werden. Zu diesem Zweck haben wir letztendlich Amazon EMR verwendet, um Jupyter PySpark-Notebooks zu erstellen und mithilfe von Apache Spark DataFrames und Python Pandas DataFrames ein leistungsstarkes Tool zum Vergleichen des aktuellen Zustands einer Maschine mit jedem früheren Zustand zu erstellen, den wir gespeichert haben.
ETL (jedermanns Favorit)
Hier sind ein paar Hinweise, bevor Sie sich unsere Codebeispiele ansehen. Die Tabellen und Schemareferenzen werden in AWS Glue gespeichert und entsprechen dem Rohereignisformat von Threat Stack für Linux-Systeme . Sie können diese Daten an Ihren vorhandenen Datensee anhängen. Anschließend wird für den Spark-Cluster eine Einstellung definiert, die ihn anweist, aus Glue zu lesen, um zu ermitteln, welche Tabellen und Spalten verfügbar sind. Wenn dann ein Cluster erstellt wird, können Sie im JupyterLab-Notebook auf die Tabelle verweisen.
Notiz: Der folgende Code ist völlig real; die Situation ist konstruiert. Ein Sicherheitsanalyst wurde gebeten, irgendwann am Valentinstag einen Host zu kompromittieren, auf dem unser Agent ausgeführt wurde. Das Ziel bestand darin, herauszufinden, was getan wurde.
Kommen wir zum Code
Als Erstes müssen wir unsere SparkSession und unseren SparkContext erstellen. Glücklicherweise werden diese bei Verwendung eines PySpark-Notebooks automatisch instanziiert, wenn wir unsere erste Zelle ausführen.
Einrichten unseres PySpark-Notebooks.
Wir haben ein Objekt „Spark“, auf das wir später verweisen werden, und wir haben auch „sc“, unseren Spark-Kontext. Wir können das dann zum Laden in Pandas und Matplotlib verwenden.
Pakete installieren.
Im nächsten Schritt werde ich die Spaltennamen bestätigen, indem ich basierend auf den Glue-Tabellen eine spark.table() erstelle und dann mein geerbtes Schema anzeige.
Lesen der Struktur unserer aus AWS Glue geladenen Spalten.
Großartig, jetzt kann ich sehen, welche Spalten und Typen mir zum Ausführen meiner SQL-Abfragen zur Verfügung stehen. Ich kann jetzt jeden beliebigen Server und jeden beliebigen Zeitraum nehmen und vergleichen. Hier erstelle ich zwei Spark DataFrames und sammle die Daten, die ich für die Untersuchung vor dem Vorfall und die forensische Untersuchung nach dem Vorfall benötige:
SELECT date_key, Zeitstempel, tsEventType, Systemaufruf, Verbindung, Benutzer, Befehl, exe, Argumente FROM compact.audit_v4 WHERE date_key >= '2020-02-05-00' AND date_key < '2020-02-14-00' AND organization_id = '5a8c4a54e11909bd290021ed' AND agent_id = 'b0f6bdb2-9904-11e9-b036-25972ec55a45' GROUP BY date_key, Zeitstempel, tsEventType, Systemaufruf, Verbindung, Benutzer, Befehl, exe, Argumente SELECT date_key, Zeitstempel, tsEventType, Systemaufruf, Verbindung, Benutzer, Befehl, exe, Argumente FROM compact.audit_v4 WHERE date_key >= '2020-02-14-00' UND date_key < '2020-02-17-00' UND organization_id = '5a8c4a54e11909bd290021ed' UND agent_id = 'b0f6bdb2-9904-11e9-b036-25972ec55a45' GRUPPE NACH date_key, Zeitstempel, tsEventType, Systemaufruf, Verbindung, Benutzer, Befehl, exe, Argumente
Gruppierung der Daten rund um unser Kompromissdatum, den 14. Februar. (Einige Notebook-Zellen werden hier zur besseren Lesbarkeit als GitHub Gists angezeigt.)
Nun eine schnelle Plausibilitätsprüfung der von mir gesammelten Datenmenge:
Zählen Sie die Anzahl der Datensätze in beiden Spark-DataFrames, um eine angemessene Menge für die Untersuchung sicherzustellen.
Das scheint richtig zu sein. Ich habe einen viel größeren Zeitbereich für mein preCompromiseDf im Vergleich zu meinem postCompromiseDf . (Das „Df“ soll mir dabei helfen, mich daran zu erinnern, dass es sich um Spark DataFrame-Objekte handelt – es handelt sich lediglich um eine Namenskonvention.)
Apache Spark DataFrames sind praktisch, weil sie den gesamten DataFrame im gesamten Cluster speichern. Dies ist ideal für große Datensätze, in diesem Fall möchte ich jedoch nur eine relativ kleine Anzahl von Datensätzen vergleichen. Zu diesem Zweck führe ich toPandas() aus, um die Daten in den Speicher meines Notebooks zu verschieben, was eine schnellere Berechnung ermöglicht.
Da wir es nicht mit „Big Data“ zu tun haben, ist es in diesem Fall schneller, den Rest unserer Analyse lokal auszuführen.
Beginn unserer Analyse
Jetzt kann ich mit leistungsstarken Funktionen beginnen, z. B. prüfen, welche neuen ausführbaren Dateien seit Mitternacht des 14. Februar auf diesem Server ausgeführt werden.
/tmp/EXCITED_WHILE /usr/bin/wget /tmp/FRONT_RUN /tmp/UNUSUAL_COMB /tmp/SURROUNDING_LOCK /tmp/nmap /usr/bin/scp /tmp/sliver /tmp/sliver2 /tmp/PROUD_THUMB
Eine Liste der ausführbaren Dateien, die in der betreffenden Nacht auf dem Server ausgeführt wurden.
Also, hallo, hier sind einige zufällige ausführbare Namen in Großbuchstaben: nmap, scp, wget und etwas namens sliver. Eine kurze Google-Suche zeigt, dass Sliver höchstwahrscheinlich mit https://github.com/BishopFox/sliver in Verbindung steht und ein Implantat-Framework ist, das Befehle und Kontrolle über mehrere Protokolle unterstützt.
Ich habe den nötigen Beweis, dass mein Server kompromittiert wurde, möchte aber meine Sorgfaltspflicht erfüllen und sehen, was tatsächlich mit diesen ausführbaren Dateien gemacht wurde. Wenn ich meine Liste als Filter für denselben DataFrame verwende, kann ich weitere Details und Indikatoren für eine Kompromittierung (IoC) herausfiltern:
exe-Argumente 80 /tmp/EXCITED_WHILE ./EXCITED_WHILE 162 /usr/bin/wget wget https://github.com/andrew-d/static-binari... 255 /tmp/AUFGEREGT_WÄHREND ./AUFGEREGT_WÄHREND 256 /tmp/VORDERER_LAUF ./VORDERER_LAUF 359 /tmp/UNÜBLICHE_KAMM ./UNÜBLICHE_KAMM 360 /tmp/UMGEBUNGSSPERRE ./UMGEBUNGSSPERRE 464 /tmp/nmap 494 /tmp/UMGEBUNGSSPERRE ./UMGEBUNGSSPERRE 533 /tmp/AUFGEREGT_WÄHREND ./AUFGEREGT_WÄHREND 589 /tmp/VORDERER_LAUF ./VORDERER_LAUF 603 /tmp/AUFGEREGT_WÄHREND ./AUFGEREGT_WÄHREND 658 /tmp/AUFGEREGT_WÄHREND ./AUFGEREGT_WÄHREND 660 /tmp/VORDERER_LAUF ./VORDERER_LAUF 671 /usr/bin/scp scp -t /tmp/ 699 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 738 /tmp/UNUSUAL_COMB ./UNUSUAL_COMB 762 /tmp/sliver ./sliver 816 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 834 /tmp/sliver2 ./sliver2 878 /tmp/nmap /tmp/nmap 909 /tmp/EXCITED_WHILE ./EXCITED_WHILE 937 /tmp/FRONT_RUN ./FRONT_RUN 992 /tmp/FRONT_RUN ./FRONT_RUN 1023 /tmp/FRONT_RUN 1040 /usr/bin/scp scp -t /tmp/ ...
Extrahieren aller zugehörigen Argumente, die mit meiner Liste verdächtiger ausführbarer Dateien verknüpft sind.
Daher wurde scp zum Verschieben von Dateien verwendet, wget hat Code von GitHub heruntergeladen (wenn ich zu dieser Zeile gehe, sehe ich, dass nmap so auf das System gelangt ist) und die Ausführungsdetails dieser anderen Dateien sind in der Datei selbst enthalten, da sie keine Befehlszeilenargumente erhalten haben. An diesem Punkt ist es sinnvoll, einen Host-Snapshot als Beweismittel zu erstellen und die Instanz zu beenden.
Der letzte Schritt besteht darin, zu bestätigen, dass keine anderen Hosts in der Umgebung kompromittiert wurden. Hierzu nehmen wir einige Elemente aus unserer vorherigen IoC-Liste und überprüfen diese auf allen Servern.
SELECT date_key, Zeitstempel, tsEventType, Systemaufruf, Verbindung, Benutzer, Befehl, exe, Argumente, AgentId, tty, Sitzung, cwd FROM compact.audit_v4 WHERE date_key >= '2020-01-01' AND date_key <= '2020-02-29' AND organization_id = '5a8c4a54e11909bd290021ed' AND tsEventType = 'audit' AND syscall = 'execve' GROUP BY date_key, Zeitstempel, tsEventType, Systemaufruf, Verbindung, Benutzer, Befehl, exe, Argumente, AgentId, tty, Sitzung, cwd
52
Diese Abfrage gibt in der gesamten Umgebung 52 Ergebnisse für verdächtige Nmap- und Sliver-Aktivitäten zurück. Wir können diese Ansicht weiter eingrenzen, indem wir in einen Pandas-DataFrame wechseln und die Ergebnisse nach jedem Server gruppieren:
Erste Schritte mit Ihrer eigenen Threat Stack-Analyse
Vielen Dank, dass Sie mir bis zu diesem Beitrag treu geblieben sind. Ich bin total begeistert von den Möglichkeiten, die diese Daten bieten, und davon, neue Wege zu finden, sie zu erkunden. Wenn Sie derzeit die Threat Stack-Plattform nutzen, können Sie Ihre eigene Datenportabilität mithilfe dieser Dokumentation als Leitfaden einrichten. Der Vorteil besteht darin, dass Sie für Ihre eigenen Geschäftsanforderungen die richtige Datenmenge festlegen können, die Sie aufbewahren möchten.
Für Leute, die unseren Dienst „Threat Stack Oversight℠“ nutzen, haben wir 30 Tage Ereignisdaten und arbeiten gerne mit Ihnen zusammen, um mithilfe dieses Toolsets eine gründlichere forensische Analyse Ihrer Umgebung durchzuführen, falls Sie nicht über einen Data Lake verfügen.
Der nächste Schritt für das Threat Stack Security Operations-Team besteht darin, im Rahmen unserer nächsten Analyse mithilfe von Data Science-Notebooks nach weiteren Grafiken und Diagrammen zu suchen, die die visuelle Analyse der Daten erleichtern. Weitere Informationen dazu folgen, aber hier ist ein erster Versuch mit einigen geolokalisierten IPs (die Dichte jedes Kreises gibt die Anzahl der Verbindungen an).
Weitere Analysevisualisierungen folgen in Kürze vom Threat Stack Security-Team!
Threat Stack heißt jetzt F5 Distributed Cloud App Infrastructure Protection (AIP). Beginnen Sie noch heute damit, Distributed Cloud AIP mit Ihrem Team zu verwenden.