Verwenden von stats, eventstats & streamstats für die Bedrohungssuche

Wenn ihr schon einmal Suchen in Splunk durchgeführt habt, dann habt ihr ziemlich sicher mindestens eine Suche mit dem Befehl stats durchgeführt. Lasst es mich kurz machen: stats ist ein entscheidender Befehl beim Threat Hunting, und es wäre eine Schande, in dieser Blog-Reihe nicht darüber zu sprechen.

Wenn man den Fokus auf Datensets von Interesse legt, kann man mit dem Befehl stats ganz leicht Berechnungen mit jedem der zurückgegebenen Feldwerte durchführen, um zusätzliche Informationen zu erhalten. Und wenn ich stats sage, spreche ich eigentlich von drei Befehlen:

• stats
• eventstats
• streamstats

Wie viele Splunk-Befehle sind diese drei Befehle transformativ, d. h. sie verwenden eine Ergebnismenge und führen Funktionen mit den Daten durch.

Am besten sehen wir uns stats näher an.

(Im Rahmen unserer Reihe „Threat Hunting mit Splunk“ wurde dieser Artikel ursprünglich von John Stoner geschrieben. Wir haben ihn vor kurzem überarbeitet, um seinen Nutzen zu maximieren.)

Verwendung des Befehls stats für die Bedrohungssuche

Der Befehl stats ist ein Grundbefehl von Splunk. Er führt beliebig viele statistische Funktionen für ein Feld durch, bei denen es sich um einfache count- oder average-Funktionen oder komplexere Funktionen wie die Berechnung eines Perzentils oder der Standardabweichung handeln kann. 

Wenn man im Befehl stats das Schlüsselwort by angibt, kann man die Statistikberechnung anhand eines oder mehrerer angegebener Felder gruppieren. 

Es folgt ein gutes Beispiel für die Verwendung des Befehls stats beim Threat Hunting. Ich stelle hier jetzt die Hypothese auf, dass die source/destination-Wertpaare mit der höchsten Zahl von Verbindungen, die in einem bestimmten Netzwerkbereich beginnen, genauer untersucht werden sollten.

sourcetype=fgt_traffic src=192.168.225.* NOT (dest=192.168.* OR dest=10.* OR dest=8.8.4.4 OR dest=8.8.8.8 OR dest=224.*)

| stats count by src dest

| where count > 1

| sort – count

Durchsucht werden die Firewall-Daten, die aus dem Netzwerkbereich 192.168.225.0/24 stammen und zu Zielen führen, die nicht intern oder DNS sind. Der Befehl stats ermittelt die Anzahl (count) gruppiert nach Quell- und Zieladresse (src und dest). Sobald die Anzahl ermittelt wurde, kann die Ausgabe bearbeitet werden, um einzelne Events herauszufiltern, und kann anschließend vom höchsten zum kleinsten Wert sortiert werden.

Der Befehl stats kann auch zum Summieren von Werten verwendet werden. Man könnte die Hypothese aufstellen, dass man den Firewall-Traffic untersucht, um zu verstehen, wer am meisten mit externen Hosts kommuniziert, und zwar nicht im Hinblick auf die Zahl der Verbindungen, sondern im Hinblick auf die Anzahl der Bytes. Mit dem Befehl stats können mehrere Felder berechnet, umbenannt und gruppiert werden. 

sourcetype=fgt_traffic src=192.168.225.* NOT (dest=192.168.* OR dest=10.* OR dest=8.8.4.4 OR dest=8.8.8.8 OR dest=224.*) | stats sum(bytes_in) as total_bytes_in sum(bytes_out) as total_bytes_out by src dest | table src dest total_bytes_in total_bytes_out | sort – total_bytes_out

In diesem Beispiel werden dieselben Datensets verwendet, doch dieses Mal wird der Befehl stats eingesetzt, um die Felder bytes_in und bytes_out zu summieren. Wenn ich die Sortierreihenfolge ändere, kann ich problemlos zwischen verschiedenen Werten wechseln, um Folgendes zu untersuchen:

• Die höchste Zahl eingehender Bytes 
• Die wenig kommunizierenden Quellen mit der geringsten Byte-Zahl (auch hierzu ließe sich wieder eine eigene Hypothese aufstellen)

Kurze Randnotiz hierzu: Angesichts der obigen Ergebnisse könnte ich mich fragen, warum ich viele Hosts aus demselben Subnetz sehe, die alle mit derselben Ziel-IP kommunizieren, und dabei identische Byte-Zahlen aufweisen, sowohl bei der eingehenden als auch der ausgehenden Kommunikation. Der Punkt ist, dass es zahlreiche Möglichkeiten gibt, stats zu verwenden.

Der Befehl eventstats

Nachdem wir diese Grundlagen jetzt geklärt haben, wenden wir diese Konzepte nun auf eventstats an. Ich betrachte eventstats als eine Methode zur Berechnung von „Gesamtsummen“ innerhalb einer Ergebnismenge, die dann zum Manipulieren dieser Summen verwendet werden können, um das Datenset weiter zu untersuchen.

Im Rahmen einer weiteren Hypothese möchte ich nun die Systeme mit den größten, aus dem Netzwerk ausgehenden Byte-Zahlen identifizieren und untersuchen. Für eine effektive Bedrohungssuche sollte ich zwei wichtige Dinge kennen:

• Alle externen Hosts, mit denen sich mein System verbindet 
• Die an jeden Host ausgehende Datenmenge

Wir verwenden dieselben grundlegenden Suchkriterien wie bei der früheren Suche. Diese erweitern wir etwas, um sicherzustellen, dass alle bytes_out nicht Null sind, damit die Ergebnismenge weniger irrelevante Ergebnisse enthält. Eventstats berechnet die Summe der bytes_out, benennt sie in total_bytes_out um und gruppiert sie nach Quell-IP-Adresse. Diese Ausgabe kann dann als Feldwert behandelt und mit zusätzlichen Splunk-Befehlen ausgegeben werden.

sourcetype=fgt_traffic src=192.168.225.* NOT (dest=192.168.* OR dest=10.* OR dest=8.8.4.4 OR dest=8.8.8.8 OR dest=224.*) bytes_out>0

| eventstats sum(bytes_out) AS total_bytes_out by src

| table src dest bytes_out total_bytes_out

| sort src – bytes_out

Die rot markierten Zeilen zeigen die Quell-IP-Adressen mit summierten bytes_out-Werten und der zugehörigen total_bytes_out-Gesamtsumme

Zur Prüfung einer weiteren Hypothese könnte ich eventstats jetzt verwenden, um nach Systemen zu suchen, bei denen mehr als 60 % des Daten-Traffics an ein einziges Ziel gehen. Wenn ein System fast ausschließlich mit einem einzigen externen Host kommuniziert, könnte dies bedenklich sein oder zumindest Anlass zu weiteren Untersuchungen geben.

Dazu könnten wir zum vorherigen Beispiel zurückkehren, bei dem wir große bytes_out-Werte nach Quell- und Ziel-IP-Adressen gesucht haben, und dieses etwas verändern: Wir verwenden eventstats, um den bytes_out-Wert nach Quelle als Prozentwert der Byte-Gesamtmenge zu untersuchen, die an ein bestimmtes Ziel geht.

sourcetype=fgt_traffic src=192.168.225.* NOT (dest=192.168.* OR dest=10.* OR dest=8.8.4.4 OR dest=8.8.8.8 OR dest=224.*)

| eventstats sum(bytes_out) AS total_bytes_out by src

| eval percent_bytes_out = bytes_out/total_bytes_out * 100

| table src dest bytes_in bytes_out total_bytes_out percent_bytes_out

| where percent_bytes_out > 60

| sort - percent_bytes_out dest

Auf der Basis der vorherigen Suchkriterien berechne ich eventstats, indem ich die nach Quell-IP-Adresse gruppierten bytes_out-Werte summiere, um die „Gesamtsumme“ zu erhalten.

Nun wandle ich diese Daten mit Hilfe des Befehls stats um, wie ich es schon zuvor getan habe, und gruppiere sie nach Quell- und Ziel-IP. An diesem Punkt habe ich als Ergebnisse die Summen von bytes_in und bytes_out, die total_bytes_out und die Quell- und Ziel-IP.

Das ist schon recht gut! Ich muss aber noch nach den Ausreißern filtern, die ich zur Klärung meiner Hypothese benötige.

Mit dem Befehl eval kann ich anhand von bytes_out und total_bytes_out einen Prozentsatz des Gesamt-Traffics berechnen. An diesem Punkt formatiere ich die Daten mit dem Befehl table, filtere dann nach Prozentwerten größer 60 und sortiere die Ausgabe.

Als Ergebnis erhalte ich nun eine Gruppe von Quell-IP-Adressen, die ich in dem Wissen weiter untersuchen kann, dass ein großer Prozentsatz der Daten an ein einzelnes Ziel geht. Und tatsächlich bringt meine Ausgabe eine interessante Erkenntnis: Die ersten 14 Quelladressen in meiner Tabelle kommunizieren alle mit derselben externen IP-Adresse. 

Das allein könnte eine weitere Untersuchung wert sein. Es könnte sich aber auch um ein Ziel handeln, das mit einem Lookup auf die Whitelist gesetzt werden sollte. Dieser Ansatz ermöglicht mir jedoch, meine Suche weiter zu verfeinern und meine Hypothese zu bestärken oder zu widerlegen.

Der Befehl streamstats

Weiter geht's mit streamstats. Der Befehl streamstats basiert auf den Grundlagen von stats, bietet jedoch eine Möglichkeit, Statistiken beim Auftreten eines Events zu erstellen. Dies kann sehr nützlich sein, um z. B. laufende Summen zu berechnen oder Durchschnittswerte zu ermitteln, während Daten zur Ergebnismenge hinzukommen.

Anhand der Ergebnisse unserer früheren Suche könnte ich nun die Hypothese aufstellen, dass die von meinem Host ausgehende Kommunikation in Schüben erfolgt. Dies könnte ich dann mithilfe von streamstats visualisieren, um diese Hypothese zu prüfen.

sourcetype=fgt_traffic src=192.168.225.* NOT (dest=192.168.* OR dest=10.* OR dest=8.8.4.4 OR dest=8.8.8.8 OR dest=224.*) bytes_out>0

| sort date

| streamstats sum(bytes_out) as total_bytes_out by src

| table date bytes_out total_bytes_out

Das vorherige Beispiel zeigt, dass 77 % des Daten-Traffics der Quell-IP-Adresse 192.168.225.80 an ein bestimmtes Ziel gingen. Wir könnten dies nun weiter untersuchen und uns das Datenvolumen über die Zeit ansehen, das von dieser Adresse stammt.

Ich beginne dazu mit einer Suche, die bis auf eine Ausnahme mit den grundlegenden Suchen aus den anderen Beispielen identisch ist: Die Quelle ist nicht mehr ein Adressenbereich, sondern eine bestimmte Adresse.

Da ich die Informationen pro Tag aggregieren möchte, sortiere ich nach dem Datum. Dann verwende ich streamstats, um die Summe von bytes_out, umbenannt in total_bytes_out und nach Quell-IP-Adresse sortiert, zu ermitteln. Abschließend stellen wir die Ausgabe als Tabelle dar, mit Daten für Datum, bytes_out und total_bytes_out.

Die Ausgabe kann in Tabellenformat angezeigt oder visualisiert werden (vorzugsweise als Linien- bzw. Flächendiagramm). Wie ihr der Ausgabe entnehmen könnt, ergibt die Summe der täglichen bytes_out-Wert und der total_bytes_out-Werte des Vortags den heutigen total_bytes_out-Wert.

Weitere Verwendungen von stats, eventstats und streamstats

Stats, eventstats und streamstats sind sehr leistungsstarke Tools, mit denen die Ergebnismenge verfeinert werden kann, um Ausreißer innerhalb der Umgebung zu identifizieren. Bei diesem Blog haben wir uns auf den Netzwerk-Traffic konzentriert und Summen und Zähler verwendet. Es spricht jedoch nichts dagegen, diese Befehle auch für hostbasierte Analysen zu verwenden sowie Statistiken wie Standardabweichungen, Mediane und Perzentile zu nutzen.

Viel Spaß beim Threat Hunting!