Trovent hat sein eigenes ETW-Tracing-Tool entwickelt. Wir zeigen Ihnen, wie YAETWi das Leben von IT-Sicherheitsspezialisten, Malware-Analysten und Pentesting-Experten erleichtert.
Gründe für die Entwicklung unseres eigenen ETW-Tracing-Tools
Als Security-Analyst arbeiten Sie möglicherweise an der Entwicklung von Erkennungsregeln für eine bestimmte Schadsoftware oder einen bösartigen Prozess unter Verwendung von Windows-Logdaten und -Protokollen. In der Praxis ist es jedoch oft recht mühsam, den Prozess mit den korrekten, vom Betriebssystem erzeugten Logdaten zu korrelieren – vor allem, wenn es sich um einen Remote-Prozess handelt.
Außerdem reichen die Standardwerkzeuge nur bedingt aus. Normale Windows-Logs haben erhebliche Einschränkungen: Es fehlen ihnen nicht nur wichtige Informationen, um einen bestimmten Prozess aufspüren zu können, sondern es fehlen häufig auch die Details, die für die Erkennung (und Verringerung) von Fehlalarmen (false positives) relevant sind.
Wenn es um die Reduzierung von Fehlalarmen geht, ist der Analyseansatz mit Standard-Windows-Logdaten in der Praxis keine wirklich Alternative mehr. Wir kamen also zu dem Schluss, dass wir es besser machen können. Wir beschlossen, eine Lösung zu entwickeln, mit der wir den Prozess der Malware-Erkennung vereinfachen und beschleunigen können.
YAETWi – von Trovent entwickelt und Open Source verfügbar
Unser Trovent Security Research Team hat ein Open-Source-Tool mit dem Namen YAETWi entwickelt. Es nutzt die ETW-Schnittstelle und bietet umfassende Tracing-Funktionen, die dem Security-/Malware-Analysten/Pentester helfen, die zu analysierenden Prozesse sowohl im User- als auch im Kernel-Bereich zu beleuchten. Vor allem ermöglicht es eine einfache Korrelation dieser Prozesse – sowohl lokal als auch remote – mit den relevanten Systemereignissen.
Außerdem haben wir ein unterstützendes Tool namens YAETWix entwickelt. Sein Hauptzweck ist es, dem Security-/Malware-Analysten zu helfen, jeden zu analysierenden lokalen Prozess einfach zu verwalten.
YAETWix ermöglicht:
- das Starten von Prozessen in “suspended mode”, um ihre PID zu identifizieren;
- die Übergabe der PID als Parameter an YAETWi.exe;
- die Prozessausführung fortzusetzen und YAETWi den Rest der Arbeit zu überlassen, indem der Prozess (PID) mit den relevanten Betriebssystemereignissen korreliert wird.
Korrelation von Prozessen und Systemereignissen: eingeschränkte Möglichkeiten!
Die Durchführung von Malware-Analysen zum Zwecke der Festlegung von Erkennungsregeln kann ein schwieriges und zeitaufwändiges Unterfangen sein, da die Korrelation zwischen dem zu analysierenden Prozess und den Logdaten auf der Grundlage sehr spärlicher Informationsartefakte erfolgt. Diese sind:
- Zeitstempel – der manuell mit den Systemprotokollen korreliert werden muss
- PID (Prozess-ID) – die bei kurzlebigen Prozessen häufig schwer zu ermitteln ist
- Externe IP-Adresse – als Indikator für externe Verbindungen, die nicht immer leicht mit dem zu analysierenden Prozess zu korrelieren sind
Der Zeitstempel ist im Allgemeinen ein guter Indikator, aber die Notwendigkeit, diesen manuell mit den Systemlogs zu korrelieren, ist eine Herausforderung. Die manuelle Korrelation verlangsamt nicht nur den gesamten Analyseprozess, sondern auch die Menge an Logs, die pro Sekunde in einer realen Umgebung erzeugt werden, kann den Analysevorgang erheblich beeinträchtigen – oder ihn nahezu unmöglich machen.
Eine Prozess-ID ist ein weiterer wichtiger Indikator, der jedoch bei kurzlebigen Prozessen nur schwer zu erkennen ist, wenn kein Mechanismus zum Anhalten des Prozesses beim Prozessstart zur Verfügung steht.
Bei externen Verbindungen kann eine externe IP-Adresse ein wertvoller Indikator sein. Die meisten Verbindungen unter Windows werden jedoch vom svchost-Dienst verwaltet. Daher ist es sehr schwierig, sich allein auf die Prozess-ID zu verlassen, um die Ausführung eines bestimmten Befehls von außen zu verfolgen, da der svchost-Prozess auch von anderen Prozessen verwendet werden kann.
Verbessertes Tracing und Erkennung mit YAETWi
Aufgrund der oben beschriebenen Einschränkungen hat unser Trovent Security Research Team beschlossen, ein eigenes Tracing-Tool zu entwickeln. Unter Verwendung der ETW-API bietet YAETWi einen zeitsparenden, produktivitätssteigernden und zuverlässigen Ansatz für die Analyse des Verhaltens von bösartigen Prozessen.
YAETWi bietet eine schlanke und einfach zu bedienende Oberfläche, die dem Malware-/Security-Analysten so viele Informationen liefert, wie er/sie benötigt, um anschließend effektive Erkennungsregeln für bösartige Prozesse und ihre zugehörigen IOCs (Indicators of Compromise) zu definieren.
Wie funktioniert’s?
Durch die Angabe einer externen IP als Parameter beginnt die YAETWi-Anwendung mit dem Überwachen externer Verbindungen, die von der angegebenen IP stammen, und mit der Protokollierung von Ereignissen für die spezifische(n) PID(s), die der/den Verbindung(en) zugewiesen wurde(n).
Wie oben erläutert, werden die meisten externen Verbindungen an svchost.exe und seine gemeinsamen Ressourcen delegiert. Daher ist die Korrelation von Prozessen und Systemereignissen äußerst schwierig. Durch die Verwendung der ETW-Schnittstelle und die Nutzung der Ergebnisse ungewöhnlicher ETW-Provider können wir jedoch einen detaillierten Blick auf Ereignisse im Kernel- und Benutzerbereich werfen, um die Indikatoren bösartiger Prozesse zu identifizieren.
In den folgenden Beispielen beschreiben wir einige praktische Anwendungsfälle eines verbesserten Prozess-Tracings mit YAETWi, indem wir eine Auswahl von Tools aus der bekannten Impacket-Suite analysieren, die sowohl bei Security-Analysten als auch bei bösartigen Akteuren bzw. Angreifern beliebt ist:
- rpd_check.py
- wmiexec.py
- getArch.py
Erkennung von Impacket-Angriffen: rdp_check.py
rdp_check.py der Impacket Suite ist ein Tool, das häufig von Angreifern verwendet wird. Es ermöglicht die Überprüfung, ob bestimmte Anmeldeinformationen für einen RDP-Dienst gültig sind.
Um das Verhalten von rdp_check auf granularer Ebene zu verstehen, haben wir YAETWi verwendet, um Prozesse zu tracen, die von rdp_check.py auf dem betroffenen Host ausgelöst werden.
Folgendes haben wir gemacht:
- Vom Kali-Linux-Terminal haben wir rdp_check.py mit Dummy-Anmeldeinformationen auf dem Host 192.168.200.4 ausgeführt (Screenshot 1).
- Im PowerShell-Fenster wurde unser YAETWi-Tool im Voraus gestartet, um auf die eingehenden Verbindungen von der IP-Adresse des Kali Linux zu lauschen (Screenshot 1).
- Nach dem Ausführen von rdp_check.py wurde die Verbindung automatisch erkannt und YAETWi hat damit begonnen, die von der PID 788 ausgelösten ETW-Ereignisse zu sammeln, die dem svchost-Dienst auf der von rdp_check.py hergestellten RDP-Verbindung (3389/tcp) zugewiesen wurden (Screenshot 1).
- Mit dem Kommando ‘d’ konnte analysiert werden, welche ETW-Ereignisse für PID 788 ausgelöst wurden (Screenshot 1).
- Screenshot 2: Mit ‘r’ und der Eingabe des Namens des ETW-Providers konnten wir anschließend eine eingehende Analyse der mit dem ETW-Provider Microsoft-Windows-RemoteDesktopServices-RdpCoreTS verbundenen Ereignisse durchführen.
(1) Eine externe Verbindung wird von YAETWi erkannt und das Tracing der zugeordneten PID wird gestartet
(2) In der Ausgabe des ETW-Providers Microsoft-Windows-RemoteDesktopServices-RdpCoreTS lässt sich ein Muster erkennen
Erkennung von Impacket-Angriffen: wmiexec.py
wmiexec.py aus der Impacket Suite ist ein weiterer “Favorit” der Angreifer, der häufig in freier Wildbahn anzutreffen ist.
wmiexec.py bietet einem Angreifer eine semi-interaktive Shell, die einen ähnlichen Ansatz wie smbexec verfolgt, aber Befehle über die Windows Management Instrumentation (WMI) ausführt.
Um das Verhalten von wmiexec.py auf granularer Ebene zu verstehen, haben wir wie im vorherigen Abschnitt YAETWi verwendet, um Prozesse zu tracen, die von wmiexec.py auf dem betroffenen Host ausgelöst werden. Wir haben folgendes gemacht:
- Vom Kali Linux Terminal aus haben wir wmixec.py ausgeführt (Screenshot 1).
- Im PowerShell-Fenster wurde unser YAETWi-Tool vorab gestartet und konnte einige mit dem Angriff verbundene Verbindungen erkennen (Screenshot 1).
- Mit dem Befehl ‘d’ haben wir alle ETW-Provider aufgelistet, die mit den PIDs in Verbindung stehen (Screenshot 1).
- Durch Eingabe von ‘r’ und dem Namen des ETW-Providers konnten wir das Angriffsmuster beobachten (Screenshot 2), d.h. die mit dem ETW-Provider Microsoft-Windows-WMI-Activity assoziierten Ereignisse.
(1) Drei Verbindungen werden von YAETWi erkannt und drei verschiedene PIDs werden entsprechend zugewiesen. Die Ausgabe der ETW-Provider gibt auch Aufschluss über die entsprechend zugeordneten PIDs.
(2) In der Ausgabe des ETW-Providers Microsoft-Windows-WMI-Activity lässt sich ein Muster erkennen
Erkennung von Impacket-Angriffen: getArch.py
getArch.py ist ein weiteres Impacket-Tool, das häufig von Angreifern und Offensive Security Experten verwendet wird.
getArch.py ermöglicht die Aufzählung des Zielsystems/der Zielumgebung und wird typischerweise in der Reconnaissance-Phase der Cyber-Kill-Chain verwendet.
Das Skript getArch.py stellt über das DCE-RPC-Protokoll eine Verbindung zum Zielsystem her, um den Betriebssystemtyp zu ermitteln. Diese Informationen können von einem Angreifer genutzt werden, um geeignete Malware für das Zielsystem vorzubereiten.
Insgesamt verursacht getArch.py einen sehr kleinen Fußabdruck. Mit anderen Worten, es wird oft unter dem Radar der Standard-Erkennungsmechanismen fliegen, da es die in den RPC-Headern enthaltenen Informationen nutzt. Im Allgemeinen ist die Verwendung von getArch.py daher schwer zu erkennen.
Die folgenden Screenshots veranschaulichen, wie getArch.py verwendet wird, um die zugrundeliegende Architektur des Zielsystems zu identifizieren:
Die Informationen zur Zielsystemarchitektur sind in einem der RPC-Header enthalten
Unzulänglichkeiten der Standard-Windows-Logs für Erkennungszwecke
Wenn wir uns auf die Standard-Windows-Logs verlassen würden, würde in den Security Events nur ein einziges Ereignis mit allgemeinen Informationen über die externe Verbindung protokolliert werden. Das reicht bei weitem nicht aus, um eine wirksame Erkennung zu starten.
Ein protokolliertes Ereignis für getArch.py in den Windows Security Event Logs
Verbesserte Sichtbarkeit und Erkennung mit YAETWi von Trovent
Wie bei den anderen Impacket-Tools (rdp_check.py, wmiexec.py) haben wir YAETWi verwendet, um das Verhalten von getArch.py auf granularer Ebene zu analysieren und zu verstehen, d.h. um Prozesse zu tracen, die von getArch.py auf dem Zielsystem ausgelöst werden.
Was wir gemacht haben:
- Ausführen von getArch.py über das Kali Linux-Terminal.
- Im PowerShell-Fenster wurde unser YAETWi-Tool vorab gestartet und konnte die externe Verbindung erkennen, indem es diese dem svchost-Dienst mit der PID 920 zugewiesen hat.
- Mit dem Tastendruck ‘d’ konnten wir alle ETW-Provider, die mit dieser PID verbunden sind, auslesen.
- Mit “r” und der Eingabe des Namens des ETW-Providers Microsoft-Windows-RPC konnten wir schließlich die mit diesem Provider und der PID 920 verbundenen Ereignisse ausgeben.
Das Endergebnis ist, dass wir mit YAETWi einen ETW-Provider namens Microsoft-Windows-RPC erkennen. Und wir können beobachten, dass eine RPC-Verbindung innerhalb einer Sekunde gestartet und geschlossen wird. Dies ist das Maß an Transparenz und Einblick, das für die Entwicklung wirksamer Erkennungsfunktionen erforderlich ist.
Beobachtung des Verhaltens von getArch.py mit YAETWi
Starten lokaler Prozesse im “suspended mode”
Bei der Analyse lokaler Prozesse gibt es noch ein Problem: Nach dem Start eines lokalen Prozesses sollte dessen PID an YAETWi oder ein anderes Debugging-Tool übergeben werden, um die Erkennung zu ermöglichen. Der Analyseprozess sollte jedoch von Anfang an gestartet werden, damit die Erkennung vollständig ist, und nicht erst, wenn der analysierte Prozess bereits gestartet worden ist.
Eine Möglichkeit, Prozesse mit den Standard-Windows-Tools anzuhalten, besteht darin, einen Prozess mit einem Debugger wie WinDBG zu starten. Dies kann jedoch sehr zeitaufwendig sein.
Unser Trovent Security Research Team war der Meinung, dass wir eine effektivere Lösung entwickeln können. Daher haben wir uns entschlossen, YAETWix als unterstützendes Werkzeug zu entwickeln. YAETWix ermöglicht das Starten eines beliebigen Prozesses im angehaltenen Modus (suspended mode), indem es nicht gemanagten Code (unmanaged code) auslöst, seine PID abruft und seine Ausführung fortsetzt, nachdem die abgerufene PID als Parameter an YAETWi übergeben wurde.
YAETWix macht das Leben für Malware-Analysten einfacher
Zur Veranschaulichung seiner Einfachheit haben wir hier einen Code Snippet von YAETWix eingefügt. Die einfache, aber leistungsfähige Implementierung basiert auf der Verwendung von nicht gemanagtem C# Code, um das Hauptziel der Prozessverwaltung auf der Windows-Plattform zu erreichen.
YAETWix verwendet die folgenden Funktionen aus der “kernell32.dll” Bibliothek:
Genau das, was wir brauchen, um die Applikation zur Laufzeit vollständig zu kontrollieren!
YAETWix ist extrem einfach zu bedienen:
Beim Start wird der Applikation nur ein einziges Argument übergeben, nämlich der zu analysierende Prozess mit seinen erforderlichen Argumenten. Nachdem der Prozess gestartet wurde, wird er automatisch in den Suspend-Modus versetzt und seine PID wird ausgegeben.
Diese PID kann im Anschluss an YAETWi oder ein anderes Debugging-Tool weitergegeben werden. Der Prozess kann dann durch Eingabe von ‘r’ wieder aufgenommen werden.
Sowohl YAETWi als auch YAETWix verwenden
Im folgenden Beispiel zeigen wir das Tracen von nc64.exe unter Verwendung von YAETWi und YAETWix. Netcat, auch nc genannt, ist ein einfaches Werkzeug, um Daten über Netzwerkverbindungen zu transportieren. Im Kontext eines Angriffs wird es häufig von Angreifern verwendet, um eine Reverse Shell zurück zum Kontrollserver zu erstellen, da es von einigen Antivirenprodukten nicht immer als potentiell bösartiges Tool erkannt wird.
Um das Verhalten von nc64.exe auf granularer Ebene sichtbar zu machen, d. h. um Prozesse zu verfolgen, die auf dem Zielsystem ausgelöst werden, sind wir wie folgt vorgegangen:
- Ausführung von netcat (nc64.exe), um eine Reverse Shell zurück zum Kali-Linux-Rechner (10.11.14.3) auf Port 80 zu erstellen.
- Der Prozess wurde sofort angehalten und seine PID ausgegeben.
- Die ermittelte PID wurde anschließend als Argument (/pids=) für YAETWi.exe verwendet.
- Nach dem Start von YAETWi, Fortsetzung des Netcat-Prozesses durch Eingabe von ‘r’.
Die folgenden Screenshots veranschaulichen den Vorgang:
Analyse der Netcat-Reverse-Shell mit YAETWi und YAETWix
Letztendlich ermöglichte uns YAETWi – mit der Unterstützung von YAETWix – die Analyse eines lokalen Prozesses ohne großen Aufwand und mit nur wenigen zusätzlichen Schritten im Vergleich zum Testen eines externen Prozesses. Es spart Zeit, erfordert nicht die Installation zusätzlicher Tools wie WinDBG und kann sogar als PowerShell-Skript ausgeführt werden.
Was haben wir erreicht? Verbesserte Analyse und Erkennung von bösartigen Prozessen
In diesem Artikel haben wir die Schwierigkeiten der Malware-Analyse auf der Grundlage eines rein manuellen Ansatzes auf Basis von Standard-Windows-Logs erläutert. Dieser Ansatz ist sowohl zeitaufwändig als auch oft sehr fehleranfällig.
Diese Unzulänglichkeiten haben uns dazu bewogen, unser eigenes Tracing-Tool zu entwickeln. YAETWi nutzt die ETW-API und ermöglicht tiefgehendes, halbautomatisches Tracing von Prozessen.
Durch den Einsatz des YAETWi-Tools, das automatisch alle auf dem Zielsystem verfügbaren ETW-Provider aktiviert, waren wir in der Lage:
- eine gründliche Analyse verschiedener Tools der Impacket-Suite durchzuführen;
- und externe Prozesse korrekt mit den entsprechenden Windows-Events zu korrelieren.
Dies bietet uns die Grundlage, um effektive und zuverlässige Erkennungsregeln für unsere eigene Erkennungsplattform zu entwickeln: Trovent MDR – Managed Detection and Response. Details dazu verraten wir in unserem nächsten Artikel 😉
Was kommt als Nächstes? Erkennung von Impacket-Angriffen mit Trovent MDR – Managed Detection and Response
In den nächsten Ausgaben dieser Artikelserie werden wir folgende Themen behandeln:
- Wie man Erkennungsregeln für Impacket-Tools unter Verwendung der Erkennungsplattform Trovent MDR – Managed Detection and Response erstellt. Den Beitrag können Sie hier bereits hier lesen!
- Wie man die Anzahl der False Positives durch Deep Tracing mit YAETWi reduzieren kann.
Sind Sie auf der Suche nach einem Angriffserkennungssystem oder einer Managed Detection & Response-Lösung? Oder möchten Sie wissen, wie die Context Engine von Trovent funktioniert? Nehmen Sie Kontakt mit uns auf! Wir freuen uns auf ein Gespräch mit Ihnen und demonstrieren Ihnen unsere Lösungen.
Bilder: Freepik, Trovent