Input-Device-Monitoring bei Windows: Finde die Wanze!

Für moderne Malware, die im Userland agiert, sind forensische Aufspürmethoden für Abhörversuche quasi nicht existent. Ein Forscherteam will Abhilfe schaffen.

In Pocket speichern vorlesen Druckansicht 5 Kommentare lesen

(Bild: JLStock/Shutterstock.com)

Lesezeit: 5 Min.
Von
  • Jochen Schlichting
Inhaltsverzeichnis

Bei der Black Hat 2022 hat der Sicherheitsforscher und Volatility-Core-Developer Andrew Case einen bemerkenswerten Vortrag über das Aufspüren von Malware gehalten, die Input-Devices wie Tastaturen, Mikrofone, Webkameras überwacht und das vollständig im Userland realisiert.

Bestehende forensische Speichermethoden zur Erkennung dieser Techniken beschränken sich weitgehend auf Malware, die im Kernel-Bereich arbeitet. Die Verwendung von Kernel-Rootkits hat in den letzten Jahren jedoch abgenommen, da die Betriebssysteme den Zugriff auf den Kernel-Speicher stark eingeschränkt haben.

Diese Einschränkungen für Kernel-Rootkits haben zusammen mit den einfach zu verwendenden APIs im Userland, die den Zugriff auf Hardware-Geräte ermöglichen, zu vielen Malware-Samples für die Geräteüberwachung geführt, die ausschließlich im Prozessspeicher arbeiten. Diese Input-Devices sind insbesondere für die Angreifer von großem Wert, die darauf abzielen, menschliche Ziele auszuspionieren, um an private sowie sicherheitssensitive Informationen zu gelangen (etwa Messenger, Passwörter im Klartext oder Video- und Audiostreams).

Leider sind die derzeitigen Methoden zur forensischen Erkennung und Analyse solcher Malware in den Hauptspeicherstrukturen bei Windows, Linux und macOS stark veraltet, unvollständig oder nicht existent. Daraus ergibt sich der handfeste Nachteil für Incident Responder, dass Malware und Angriffe, die auf das Überwachen von Input-Devices zielen, kaum aufgespürt werden können.

Typischerweise sucht und findet man Malware in Dateien. Doch Angreifer arbeiten vermehrt mit Memory-Only-Payloads, die sich mit Festplatten-Forensik nicht aufspüren lassen. Hinzu kommt, dass der flüchtige Hauptspeicher der einzige Ort ist, an dem festgestellt werden kann, dass tatsächlich abgehört wird und die eingesetzten Techniken vollständig untersuchbar sind.

Deshalb hat das Forscherteam um Andrew Case grundlegende Abhör-Mechanismen in Windows, Linux und macOS untersucht und evaluiert. Durch Reengineering der Datenstrukturen entwickelten sie allgemeingültige Ansätze, bekannte, wie auch unbekannte Malware aufzuspüren, die Input-Devices überwacht. Sie verfolgten damit einen generalistischen Ansatz, da zwar nicht bekannt ist, wie die Angreiferseite ihre Malware designt. Aber letztlich müssen auch die Angreifer spezifische Funktionen des Betriebssystems nutzen, um den Datenabfluss durchzuführen.

Nachfolgend wird der Forschungsansatz am Beispiel einer Windows-Umgebung dargestellt, das Forschungsteam selbst lieferte aber auch Ergebnisse für Linux und macOS. Das untersuchte und analysierte Umfeld läuft unter Windows 10 mit allen wichtigen Builds von 10563 (2015) bis 22000.556 (März 2022). Die Forscher haben eine Proof-of-Concept-Software entwickelt, die die von realer Malware missbrauchten APIs verwendet. Zum Memory-Dumping der Prozesse wurden Suspended states unter VMware genutzt. Deren Analyse erfolgt mit Volatility, dem Standardwerkzeug für forensische Arbeitsspeicheranalyse.

Die Forschungsarbeit konzentriert sich bei Windows auf die API SetWindowsHookEx, die historisch gesehen die am meisten missbrauchte API von Keyloggern im Userland ist. Die API ermöglicht die Registrierung von Hooks (Callbacks) für Hardware-Ereignisse wie Tastendruck, Mausbewegung und so weiter. Typischerweise wird dazu eine bösartige DLL in alle Prozesse injiziert, die dann die Ereignisse registriert. Das messagehooks-Plug-in des Forensik-Werkzeugs Volatility zielt darauf ab, diesen Missbrauch dieser API aufzudecken, aber es wurde nie richtig für Windows 10 aktualisiert. Außerdem haben Tests gezeigt, dass nicht alle Hook-Varianten unterstützt werden.

Daher haben die Forscher zur Detektion der unterschiedlichen, missbräuchlichen Hook-Nutzungen das messagehooks-Plug-in von Volatility überarbeitet. Es ist nun in der Lage, die vollständigen Informationen aller Message-Hook-Varianten bis zur neuesten Version von Windows 10 wiederherzustellen.

Der Missbrauch der API RegisterRawInputDevices ist die zweite beliebte Methode, die Windows-Userland-Malware zur Überwachung von Input-Devices einsetzt. Viele Samples, die in hochkarätigen Angriffen und von APT-Gruppen (unter anderem APT 27, FIN7) verwendet wurden, haben diese Funktion missbraucht. Die übliche Methode zum Missbrauch dieser API arbeitet mit einem unsichtbaren Fenster, das zum Anhängen der Callback-Funktion der Malware verwendet wird.

Volatility verfügte bisher über kein Plug-in, um die Instanzen der missbräuchlichen Verwendung der RegisterRawInputDevices-API zu ermitteln. Dieses Defizit wurde durch die Entwicklung des neuen rawinputdevicemonitors-Plug-ins behoben. Damit lässt sich herausfinden, welche Abfragen für interessante Input-Devices wie Tastatur und Maus aktuell bestehen. Das Plug-in ermöglicht die diagnostische Ausgabe der Prozess-ID und des Prozessnamens, des Windows Namens sowie der Callback-Adresse der Windows Procedure.

Mit diesen Informationen kann ein Incident Responder sofort mit der statischen Code-Analyse der identifizierten, maliziösen Anwendung (via Prozess-ID) beginnen und feststellen, welche Aktion(en) dieser Anwendungscode bei jedem Tastendruck durchführt.

Die zwei für Volatility überarbeiteten beziehungsweise neu entwickelten Plug-ins messagehooks und rawinputdevicemonitors bringen deutlich mehr Licht ins Dunkel. Insbesondere berücksichtigen sie die jüngsten Angriffsszenarien im Windows-Umfeld.

Die allgemeine Veröffentlichung der Plug-ins wurde auf der Blackhat bereits angekündigt. Es bleibt aber abzuwarten, ob dies tatsächlich passiert. In jedem Fall wurden gute Wege aufgezeigt, um solche Plug-ins gegebenenfalls auch in Eigenarbeit in der Community zu entwickeln, falls dem Research-Paper nicht der Code folgen sollte. Details sind darin und in einer zweiten Veröffentlichung nachzulesen.

(ur)