Impacket-Detektion – Teil II: Erkennung von Impacket-Angriffen mit Trovent MDR

Unser System zur Angriffserkennung kann zum Beispiel NetFlow-Daten von Routern, Sysmon-Logs und Windows-Ereignisse (mittels Verwendung von Winlogbeat) nutzen.

Im Erkennungsprozess …

• normalisiert und reichert Trovent MDR alle empfangenen Logdaten an
• und verarbeitet normalisierte Logdaten mit dem Trovent Stream Processor (TSP).

Das Ziel ist es, sicherheitsrelevante Events nahezu in Echtzeit zu erkennen.

(Zur Info: Der Trovent Stream Processor ist eine Java-Anwendung, welche die Erstellung komplexer Regeln auf der Basis von EPL – ESPER Processing Language– ermöglicht).

Um die regelbasierten Erkennungsfunktionen von Trovent MDR zur Erkennung potenzieller Impacket-Angriffe zu nutzen, gibt es einen einfachen Ansatz:

• Übertragung von Windows Security Events  von Windows-Hosts mittels Winlogbeat an Trovent MDR.
• Verwendung der Windows Security Events zum Auslösen von Erkennungsregeln in Trovent MDR.

In den folgenden Abschnitten werden wir diesen Prozess anhand einiger praktischer Impacket-Beispiele genauer untersuchen.

Die Erkennung von Impacket-Angriffen

Anhand der folgenden Beispiele werden wir die regelbasierten Erkennungsmöglichkeiten von Trovent MDR für Impacket-Angriffe untersuchen:

• secretsdump.py

• changepasswd.py

• addcomputer.py

• smbexec.py

• wmiexec.py

• services.py

• reg.py

Erkennen von secretsdump.py

Secretsdump ist ein potenziell schwerwiegender Angriff, da er die Extraktion von NTLM-Hashes ermöglicht. Diese Hashes lassen sich dann für sogenannte Pass-the-Hash-Angriffe verwenden, die auch von einer Reihe von Impacket-Tools unterstützt werden.

Ein Angriff mit secretsdump löst eine große Anzahl von verschiedenen Events in den Windows Event Logs aus. In diesem spezifischen Beispiel haben wir versucht, eine minimale Anzahl von Regeln zu schreiben, die so wenige Windows-Ereignisse wie möglich verwenden.

Dieser Ansatz hat jedoch einen Nachteil: Dies könnte in einer realen Produktionsumgebung zu einer hohen Anzahl von Fehlalarmen (“false positives”) führen! Mehr dazu später in diesem Artikel.

Um eine geeignete Trovent-MDR-Erkennungsregel zu entwickeln, müssen wir eine “Ereigniskette” auswählen, die das Verhalten von secretsdump hinreichend widerspiegelt. Wir haben hierfür folgende Events gewählt: 5156 -> 5145 -> 5145.

• Das Event 5156 wird von der Windows Filtering Platform erzeugt, die eine Verbindung zugelassen hat. Bei diesem Ereignis können wir DestPort = 445 und NOT SourceAddress.contains('192.168') definieren. Ersteres zeigt an, dass unser Angreifer eine Verbindung zu unserem Zielrechner über Port 445 hergestellt hat, da Impacket secretsdump über das Server Message Block (SMB) Protokoll kommuniziert. Letzteres zeigt an, dass der Verbindungsversuch von einem Rechner außerhalb des lokalen Netzwerks aus erfolgte.

• Event 5145 wird jedes Mal erzeugt, wenn auf ein Network Share Object (Datei oder Ordner) zugegriffen wird (5145(S, F) A network share object was checked to see whether client can be granted desired access. – Windows 10). Secretsdump erzeugt zwei solcher Events mit RelativeTargetName = "svcctl" bzw. RelativeTargetName = "winreg".

Der Befehl WHERE timer:within(10 sec) stellt sicher, dass diese Ereignisse alle innerhalb von zehn Sekunden auftreten. Außerdem wird mit PrimaryIP = a.PrimaryIP überprüft, ob diese Events alle von demselben Rechner stammen.

Die gerade beschriebene Erkennungslogik sieht als Code Snippet in Trovent MDR folgendermaßen aus:

Aufspüren von changepasswd.py

Changepasswd.py ermöglicht es Angreifern, Passwörter für Nutzerkonten zu ändern.

Wir nutzen folgende “Ereigniskette”, um das Verhalten von changepasswd abzubilden: : 5156 -> 4624 -> 4661 -> 4738 -> 4634.

• Event(5156) ist das gleiche Ereignis, das auch im Falle von secretsdump verwendet wird und in der Erkennung der weiteren Impacket-Angriffsszenarien häufig eine Rolle spielt.
• Das Event 4624 wird durch eine Anmeldung ausgelöst (4624(S) An account was successfully logged on – Windows 10 ). LogonType = 3 zeigt an, dass es sich um eine Netzwerkanmeldung handelt, die während eines Impacket-Angriffs erfolgte.
• 4661 zeigt an, dass ein Object Handle angefordert wurde (4661(S, F) A handle to an object was requested. – Windows 10).
• Das Event 4738 wird jedes Mal ausgelöst, wenn ein Benutzerobjekt geändert wurde (4738(S) A user account was changed. – Windows 10), was jedes Mal geschieht, wenn changepasswd aufgerufen wird. SubjectLogonId = c.SubjectLogonId verknüpft es mit der gleichen Anmeldesitzung wie Event(4661), ähnlich wie PrimaryIP es mit dem gleichen Rechner verknüpft.
• Das Event 4634 ist schließlich das Abmeldeereignis (4634(S) An account was logged off. – Windows 10), das immer innerhalb des Zeitfensters von zehn Sekunden auftritt.

Die gerade beschriebene Erkennungslogik sieht als Code Snippet in Trovent MDR folgendermaßen aus:

Erkennung von addcomputer.py

Addcomputer ermöglicht es Angreifern, auf dem Zielsystem Benutzer hinzuzufügen.

Ähnlich wie bei changepasswd nutzen wir folgende “Ereigniskette”, um das Verhalten von addcomputer abzubilden: mit 5156 -> 4624 -> 4661 -> 4741 -> 4724. Die ersten drei Events sind die gleichen wie in den vorherigen Beispielen. Zusätzliche sind für diesen speziellen Erkennungsfall folgende Events erforderlich:

• 4741 ist das Event für ein erstelltes Computerkonto (4741(S) A computer account was created. – Windows 10), das wir wiederum mit der SubjectLogonId und PrimaryIP der vorherigen Ereignisse verknüpfen.

• Event 4724 zeigt an, dass das Kennwort des Kontos zurückgesetzt wurde. Dies ist die effektivste Art, changepasswd auszuführen, da es die Windows-Kennwortrichtlinien umgeht.

Die gerade beschriebene Erkennungslogik sieht als Code Snippet in Trovent MDR folgendermaßen aus:

Detektion von smbexec.py

Dieser Impacket-Angriff bietet eine semi-interaktive Shell, die das SMB-Protokoll (Server Message Block) verwendet.

Die “Ereigniskette” der Windows-Events, die wir verwenden, um das Verhalten von smbexec.py zu identifizieren, lautet: 5156 -> 4672 -> 5140 -> 5145.

• Anstelle von 4624 (Logon) verwenden wir jetzt 4672 (Special Logon).
• Event 5140 zeigt den Dateifreigabezugriff mit dem ShareName.contain('IPC') an.
• 5145 ist das Event, das jedes Mal erzeugt wird, wenn auf ein Network Share Object zugegriffen wird, das wir bereits in früheren Beispielen verwendet haben. In diesem Fall fügten wir RelativeTargetName = 'svcctl' als zusätzliche Bedingung hinzu.

Die gerade beschriebene Erkennungslogik sieht als Code Snippet in Trovent MDR folgendermaßen aus:

Erkennung von wmiexec.py

Ähnlich wie smbexec bietet das Impacket-Skript wmiexec.py eine semi-interaktive Shell, verwendet aber stattdessen Windows Management Instrumentation (WMI).

Die Kette der Windows-Events, auf die wir uns zu Erkennungszwecken konzentrieren: 5156 -> 5145 -> 1.

• 5156 und 5145 wurden bereits bei den vorherigen Impacket-Erkennungsbeispielen als Events verwendet. Darüber hinaus stellt die Regel für diesen speziellen Fall der Erkennung von wmiexec.py sicher, dass das Feld RelativeTargetName gesetzt ist.
• Event 1 ist das Ereignis “Prozess gestartet”, bei dem wir prüfen, ob ParentCommandLine b.RelativeTargetName enthält. Hierbei ist zu beachten, dass Event(1) nicht aus den Windows Security Event Logs stammt, sondern aus dem Windows-Dienst Sysmon. Mit Hilfe des Winlogbeat-Agenten können die Sysmon-Logs jedoch leicht extrahiert und von den überwachten Windows-Hosts versandt werden – neben den regulären Windows Security Event Logs.

Die gerade beschriebene Erkennungslogik sieht als Code Snippet in Trovent MDR folgendermaßen aus:

Detektion von services.py

Das Impacket-Skript services.py führt das Service Control Manager Remote Protocol aus, das es einem Angreifer ermöglicht, die auf dem Rechner des Opfers laufenden Dienste zu manipulieren. Services.py kann somit verwendet werden, um wichtige Dienste zu stoppen oder sogar Dienste zu starten, die nicht laufen sollen.

Die Windows-Event-Sequenz, die wir in diesem Fall für die Erkennung verwenden: 5156 -> 4624 -> 5145 -> 4674.

• Die ersten beiden Events sind die Filterplattform und die Anmeldeereignisse, die bereits in den zuvor beschriebenen Erkennungsszenarien verwendet wurden.
• Event (5145) wird mit einem zusätzlichen Erkennungskriterium versehen: LogonID IS NOT NULL.  Dieses wird verwendet, um die Events 5145 und 4674 mit mehr als nur der PrimaryIP zu verknüpfen.
• Das Event 4674 wird ausgelöst, wenn eine Operation an einem privilegierten Objekt versucht wird (4674(S, F) An operation was attempted on a privileged object. – Windows 10). Zu Erkennungszwecken haben wir die Bedingung hinzugefügt, dass das Feld ObjectTypeauf "SERVICE OBJECT" gesetzt ist.

Die gerade beschriebene Erkennungslogik sieht als Code Snippet in Trovent MDR folgendermaßen aus:

Erkennen von reg.py 

Für unser letztes Beispiel haben wir eine Erkennungsregel für das Skript reg.py von Impacket erstellt. Ähnlich wie reg.exe erlaubt reg.py Angreifern, die Windows-Registry zu manipulieren.

Wie im vorherigen Beispiel für services.py lautet die Abfolge der Windows-Events, nach denen wir suchen: 5156 -> 4624 -> 5145 -> 4674.

Der einzige Unterschied ist, dass wir die BedingungObjectName = 'RemoteRegistry'hinzugefügt haben.

Die gerade beschriebene Erkennungslogik sieht als Code Snippet in Trovent MDR folgendermaßen aus:

Die regelbasierte Erkennung von Impacket-Angriffen funktioniert! Aber…

Was haben wir erreicht? Alle oben genannten Impacket-Angriffe können wir mit der in Trovent MDR integrierten Detection Engine erfolgreich erkennen.

Allerdings gibt es auch einige Nachteile: Wie bei jedem Erkennungsmechanismus sind Fehlalarme (false positives) immer eine Herausforderung!

False-Positive-Ergebnisse aufgrund spärlicher Logdaten

Einige der in der Impacket-Suite verfügbaren Tools weisen ein Verhalten auf, das nur sehr wenige sicherheitsrelevante Ereignisse/Logs erzeugt. Mit anderen Worten: Für einige der Impacket-Anwendungen ist es sehr schwierig (oder unmöglich), eine Kette von Windows-Events zu definieren, die zur zuverlässigen Erkennung von bösartigem Verhalten verwendet werden kann, ohne gleichzeitig in einer Flut von Fehlalarmen unterzugehen.

Bei den in diesem Artikel beschriebenen Beispielen ist dies in der Regel nicht der Fall. Andere Impacket-Tools wie getArch, smbclient oder rdp_dump erzeugen jedoch keine ausreichend aussagekräftigen Logdaten bzw. Events für Erkennungszwecke.

Jede Erkennungsregel, die für diese Tools geschrieben wird,…

• ist viel zu generisch.
• basiert auf Events, die in der Windows-Infrastruktur häufig auftreten.

Infolgedessen werden solche Erkennungsregeln unzählige Events erzeugen, die sehr oft kein bösartiges Verhalten darstellen.

Mehrere Erkennungsregeln, die für ein Impacket-Skript ausgelöst werden

Um festzustellen, welcher Impacket-Angriff durchgeführt wurde, müssen wir sicher sein, dass diese Ereignisketten nicht auch in ungefährlichen, gutartigen Szenarien auftreten. Zudem müssen wir eindeutige Event-Ketten haben.

Andernfalls haben wir das Problem, dass mehr als eine Erkennungsregel für nur einen Impacket-Angriff ausgelöst wird. Dieses Dilemma lässt sich sehr gut anhand von services.py und reg.py veranschaulichen:

• Beide verursachen die gleiche Abfolge von Windows-Events (5156 -> 4624 -> 5145 -> 4674). Mit dem einzigen Unterschied, dass reg.py auch ObjectName = 'RemoteRegistry' enthält.
• In der Praxis bedeutet dies, dass nur eine Regel bei einem Angriff mit Impacket services.py ausgelöst wird, während beide Regeln bei einem Angriff mit Impacket reg.py anschlagen. Das heißt, dass wir nicht in der Lage sind, das Auslösen der jeweiligen Regeln einem bestimmten Angriff zuzuordnen.

Wäre dieses Beispiel der einzige Fall, könnten wir wahrscheinlich argumentieren, dass es nicht so wichtig ist, zwischen diesen beiden Angriffen unterscheiden zu können. Dieses Problem wird jedoch bei Tools verschärft, bei denen es ohnehin schon an aussagekräftigen und sicherheitsrelevanten Logdaten/Events mangelt (Beispiel: getArch oder smbclient).

Was kommt als Nächstes? Präzisere Erkennung durch Deep Tracing mit YAETWi

Um das Problem der Fehlalarme durch natürlich auftretende (nicht bösartige!) Event-Ketten und mehrere Erkennungsregeln, die für einen Angriffstyp ausgelöst werden, zu lösen, benötigen wir Deep-Tracing-Funktionen.

Unter Verwendung von Deep Tracing kann das Verhalten bösartiger Prozesse auf granularer Ebene analysiert werden. Und folglich kann die für die Erkennung erforderliche Kette von Windows-Events erweitert und genauer definiert werden.

An dieser Stelle kurz zur Erinnerung, im ersten Artikel dieser Serie sind wir auf folgendes eingegangen:

• Warum unser Trovent Security Research Team sein eigenes ETW-Tracing-Tool YAETWi entwickelt hat.
• Wie YAETWi das Leben von Malware-Analysten und Pentesting-Experten erleichtert.

Im dritten und letzten Teil dieser Artikelserie werden wir untersuchen, wie die Erkennungsgenauigkeit durch den Einsatz dieses speziell entwickelten Tracing-Tools erheblich verbessert werden kann. Bleiben Sie dran!