Inhaltsverzeichnis
Einleitung
Meine erste SIEM-Rule ist nicht mehr alleine. Zwischenzeitlich habe ich etliche Rules aus dem Katalog dazu genommen. Damit häufen sich nun natürlich auch die Meldungen durch False Positives. Diese gehören nun bearbeitet. Aber auch die verdächtigen Alerts müssen bearbeitet werden. Hier können Cases hilfreich sein.
Der Artikel gehört zu meiner Serie „Bereitstellung eines Elastic SIEM„.
Mein aktuelles Ruleset
Ich habe nun schon 63 Rules aktiv, die meine Events durchsuchen:
Das macht sich auch in der MITRE ATT&CK coverage bemerkbar:
Aber auch im Alerts-Dashboard spüre ich die Arbeit der Rules: Neben einigen Tests, die ich selber in der Rolle eines Hackers durchgeführt habe, gibt es auch einige Falschmeldungen zu sehen. Insgesamt werden die Meldungen aber übersichtlich dargestellt. Hier seht ihr die Seite auf meinem großen Monitor:
Auch die Trendanalysen wirken gelungen:
Die Alerts mit dem kleinen Würfel-Symbol haben eine erweiterte Eventanalyse dabei. Sie wird über die Aktion gestartet:
Und das liefert der Analyzer nach einigen Sekunden. Das hat schon Ähnlichkeit mit einer EDR!
Insgesamt gefällt mir die Aufbereitung der Informationen sehr.
Ausnahmen für False Positives anlegen
Mein Smarthome basiert auf einer Sammlung von PowerShell-Scripten, mit denen ich meine Smarthome-Devices auslese und steuere. Dabei nutze ich teilweise auch .net-Elemente im Code der Scripte. Und diese scheinen einer der Rules im Elastic nicht zu gefallen. In den Details einer Meldung der Rule sehe ich, was bemängelt wird:
Die Rule selber ist sinnvoll. Aber mein Script wird auf dem Server immer wieder gestartet werden. Daher benötige ich eine Ausnahme für dieses Event. Dafür gibt es einen passenden Einstiegspunkt:
Der Filter wird automatisch aufgebaut. Ich muss nur noch einen Namen vergeben. Den beginne ich mit dem Datum, an dem die Ausnahme erstellt wurde:
Sinnvolle Felder sind in dem Wizzard weiter unten zu finden: vielleicht wird die Ausnahme nur vorübergehend benötigt? Und die anderen Meldungen sollen vielleicht auch gleich mit geschlossen werden? Das kann man hier angeben:
Alternativ können Alerts aber auch so geschlossen werden:
Verdächtige Events zu einem Case zusammenfassen
Erstellen eines neuen Cases
Wenn die Meldung kein False Positive ist, dann muss sie analysiert werden. Eventuell liegt ja wirklich ein Sicherheitsproblem vor! Auch auf meinem Domain Controller hat die Rule „.net Reflection via Powershell“ gestern Nacht angeschlagen! Der Overview liefert leider nicht viel dazu. Also wechsle ich in den Details des ersten Events in die Ansicht „Table“ und durchsuche die Properties. PowerShell-Codes werden in einem speziellen Eventlog als Scriptblöcke gespeichert und bei richtiger Konfiguration zum Elastic transportiert. Die Rule interessiert sich für den Code. Also sollte ich mir den hier mal ansehen. Ich finde eine passende Spalte und darin höchst befremdlichen Powershell-Code!
Ein Angriff besteht aber selten nur aus einem einzelnen Event. Also nehme ich das gefundene Event in einen neuen Case auf:
Im neuen Case sind einige Angaben zu tätigen. Den Schweregrad stelle ich auf high um, da der Code auf meinem Domain Controller gefunden wurde:
Mehr gebe ich nicht an. Der Case ist nun angelegt.
Weitere Alerts dem Case zuordnen
Das andere Event gehört auch dazu. Also nutze ich die Mehrfachaktion und füge beide dem bestehenden Case zu:
Die Auswahl ist einfach bedienbar. Man kann im Elastic gut mehrere Cases parallel verwalten:
Ausweiten der Suche
Nun möchte ich aber noch prüfen, welche anderen Events außerhalb dieser Rule dazu gehören. Also entferne ich den Rule-Filter und filtere nach dem Domain Controller:
Jetzt sehe ich, dass hier noch mehr Rules ausgelöst haben. Und deren Events stehen alle in einem zeitlichen Zusammenhang!
Ich füge sie alle dem Case zu und nutze dafür wieder die Mehrfachauswahl. Elastic hat dabei kein Problem damit, wenn ein Event bereits dem Case zugewiesen ist.
Arbeiten mit dem Case
Dann möchte ich mir den offenen Case genauer ansehen und wechsle dafür auf die Cases. Hier kann ich den Case über einen Klick auf seinen Namen öffnen. Ebenso kann ich aber auch einen Bearbeiter zuweisen:
Die Events der Bearbeitung werden im Case in einer zeitlichen Abfolge angezeigt
Nach dem Wechsel auf „Alerts“ werden die eigentlichen Events wieder angezeigt:
Gehört noch mehr zu dem Case?
Jetzt muss ich aber noch einen Bezug auf andere Systeme herstellen. Dafür nutze ich eine Search, die ich speziell auf die Alerts anwende. Diese könnt ihr euch am Ende des Beitrags herunterladen. Sie zeigt mir offene Alerts und die üblichen Attribute „Username“, „Hostname“, „Source IP“ und „Destination IP“. Hier sehe ich nun einfach, dass mein Account „Stephan-T0“ auf meinem Domain Controller die PowerShell gestartet hat. Und ebenso, dass mein Account „Stephan“ auf „WS-CL11a“ ebenso Events zu der Zeit des Angriffs angezeigt hat:
Hier könnte man nun einen Zusammenhang zwischen Standardkennung „Stephan“ und Adminkennung „Stephan-T0“ erkennen! Also suche ich nach Alerts vom Computer „WS-CL11a“ bzw. den beiden Benutzerkonten. Ich wechsle zurück in das Alerts-Dashboard und nutze dort den KQL-Filter für meine Suche. Und diese hat Treffer!
Die 10 Alerts weise ich ebenfalls dem Case zu.
Zusätzliche Events ohne Alerts zum Case finden
Jetzt fehlt mir nur noch der Zusammenhang zwischen den beiden Hosts und den beiden Benutzerkonten. Da ohne Prozess-Starts im Windows-Umfeld nichts läuft, filtere ich meine „Sysmon-01-processcreate“-Search (Diese könnt ihr euch in meinem gitlab herunterladen: https://gitlab.ws-its.de/stephan/elasticsiem). Hier zeichnet sich über die Zeitachse eine Häufung der Events gegen 18:00 ab. Die bisherigen Alerts stammen aus der Zeit ab 01:00:
Ich suche nach mstsc.exe und finde hier in den Details heraus, dass der Benutzer vom Client aus einen Remote-RDM (Remote Desktop Manager) gestartet hat. Das ist mein Jumpserver, der dann auch die Verbindung zu den Servern herstellen kann. Damit haben die Events eine Verbindung zueinander:
Zusammenfassung
Natürlich war das kein echter Angriff. Ich habe gestern Nacht verschiedene Rules im Elastic aktiviert und natürlich auch ausprobiert. Aber im Nachgang kann ich nun vieles rekonstruieren. Und genau das ist eine der Aufgaben eines SIEMs.
Den Case kann ich nun abschließen:
Damit werden auch automatisch die Alerts bestätigt:
Stay tuned!
Weitere Artikel findet ihr in meiner Serie „Bereitstellung eines Elastic SIEM„.