Erläuterung zum DLL-Hijacking
DLL-Hijacking, häufig auch als „Load-Order“- oder „Search-Order“-Hijacking bezeichnet, ist eine gut dokumentierte Technik zur Persistenz von Malware, die sich nach wie vor der Erkennung entzieht und für Ermittler eine erhebliche Herausforderung darstellt. Wer mit dieser Technik noch nicht vertraut ist, braucht keine Angst zu haben! In diesem Beitrag werden wir kurz auf die Hintergründe des „Load Order Hijacking“ eingehen und eine neue Tanium-Funktion zur Erkennung in großem Maßstab vorstellen.
Windows verlangt nicht, dass Anwendungen einen vollständigen Pfad für dynamisch geladene Bibliotheken (DLLs) angeben, die zur Laufzeit geladen werden. Wird kein vollständiger Pfad angegeben, versucht Windows, die DLL zu finden, indem es vorab festgelegte Speicherorte in einer vorhersehbaren Reihenfolge durchsucht. Daher ist es einem Angreifer möglich, diese Reihenfolge zu manipulieren, indem er eine schädliche DLL mit demselben Namen wie die legitime Version an einer Stelle einfügt, die in der Reihenfolge vor der legitimen Bibliothek liegt; dies führt dazu, dass das Betriebssystem versehentlich die schädliche DLL lädt. Wenn eine Anwendung eine DLL (z. B. ntshrui.dll) lediglich anhand ihres Namens lädt, folgt Windows einer öffentlich definierten Reihenfolge, um die erste gefundene Bibliothek mit dem Namen „ntshrui.dll“ zu identifizieren und zu laden.
Sofern der „Sichere DLL-Suchmodus“ aktiviert ist (was standardmäßig der Fall ist), prüft das Betriebssystem zunächst, ob eine DLL mit demselben Namen bereits im Arbeitsspeicher geladen ist oder ob die DLL im Registrierungsschlüssel „KnownDLLs“ (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs) definiert ist. Sollte keine dieser Bedingungen erfüllt sein, lädt Windows die Bibliotheken in der folgenden Reihenfolge:
- Das Verzeichnis, aus dem die Anwendung gestartet wurde
- Das Systemverzeichnis (C:\Windows\System32)
- Das 16-Bit-Systemverzeichnis (C:\Windows\System)
- Das Windows-Verzeichnis
- Das aktuelle Verzeichnis
- In den PATH-Variablen definierte Verzeichnisse
Die Ladereihenfolge wird von Microsoft hier näher erläutert:
Bibliothek „KnownDLLs“
Auf jedem beliebigen Windows-System ist die Angriffsfläche – dargestellt durch die Anzahl der potenziell manipulierbaren Stellen – wesentlich größer, als man vermuten würde. In der Regel gelten Anwendungen, die außerhalb von „C:\Windows\System32” “ ausgeführt werden und eine Bibliothek laden, ohne den vollständigen Pfad anzugeben, als potenzielle Angriffsziele. Hinweis: Die betreffende Bibliothek darf zudem nicht bereits im Arbeitsspeicher vorhanden sein oder im Registrierungswert „KnownDLLs“ aufgeführt sein. Selbst Binärdateien des Kernsystems, insbesondere „explorer.exe“, haben sich als anfällig erwiesen (https://capec.mitre.org/data/definitions/471.html (wird in einem neuen Tab geöffnet)).
Eine sorgfältig entwickelte bösartige Bibliothek kann als „Durchgang“ für die legitime Bibliothek dienen und so die Stabilität der anfälligen Anwendung, die sie lädt, gewährleisten. Das bloße Aufzählen laufender Anwendungen oder gängiger Speicherorte reicht nicht aus, um den Angriff zu erkennen. Insgesamt hat die Vielzahl potenziell ausgenutzter Anwendungen und geladener DLLs viele Ermittler vor eine große Herausforderung gestellt, die versucht haben, diese Technik aufzudecken.
Das Incident-Response-Modul von Tanium (Version 2,3,1)
Die neueste Version des Incident Response Moduls von Tanium (Version 2,3,1) enthält einen neuen Sensor mit dem Namen „DLL Load Order Hijacking Search“. Diese Funktion wurde entwickelt, um Unternehmen dabei zu unterstützen, Manipulationen der DLL-Ladereihenfolge in großem Umfang zu erkennen. Der Sensor überprüft die von laufenden Prozessen geladenen DLLs und wendet verschiedene heuristische Verfahren sowie Filterschritte an, um Situationen zu identifizieren, in denen möglicherweise eine Manipulation stattgefunden hat. Wird ein möglicherweise missbrauchter Prozess identifiziert, liefert der Sensor Informationen über den Prozess und die DLL, um einem Analysten bei der Beurteilung der Legitimität des Treffers zu helfen. Konkret liefert der Sensor folgende Informationen:
- Prozessname und Pfad
- DLL-Pfad
- DLL MD5 -Hash
- Falls die DLL digital signiert ist
- Grund, warum die DLL als schädlich eingestuft wird
Tanium führt diesen gesamten Prozess – von der Suche bis zur Erstellung der Ergebnisse – innerhalb von Sekunden durch, unabhängig vom Umfang der Umgebung.
Der folgende Screenshot zeigt ein Beispiel für die Ausgabe des Sensors „DLL Load Order Hijacking“ in einer kleinen Laborumgebung. Wir haben auf einem einzelnen „infizierten“ System eine inszenierte Erkennung erstellt, bei der „Explorer.exe“ die Datei „ntshrui.dll“ aus dem Verzeichnis „C:\WINDOWS“ statt aus „C:\WINDOWS\system32” “ geladen hat.
In großen Unternehmensumgebungen kann dieser Sensor eine gewisse Anzahl von Fehlalarmen auslösen. Anwendungen laden häufig Kopien legitimer Bibliotheken aus demselben Verzeichnis gemäß der erwarteten DLL-Suchreihenfolge, um sicherzustellen, dass sie auf verschiedenen Windows-Installationen und -Versionen einheitlich ausgeführt werden können. Tanium liefert automatisch in Echtzeit Daten zur Häufigkeit des Auftretens für jedes Ergebnis, sodass Analysten häufige Ergebnisse in Verbindung mit den vom Sensor bereitgestellten Hash- und digitalen Signaturdaten problemlos ausschließen können. Der folgende Screenshot zeigt ein Beispiel für ein falsch-positives Ergebnis, das durch eine Filterung anhand der digitalen Signatur oder der Häufigkeitsdaten hätte ausgeschlossen werden können.
Um die Anzahl der Fehlalarme weiter zu reduzieren, bietet der Sensor den Benutzern zudem die Möglichkeit, eine Whitelist mit bekanntermaßen einwandfreien Bibliotheken zu definieren. Tatsächlich können zusätzliche Tanium-Sensoren problemlos alle geladenen oder auf der Festplatte befindlichen DLLs sowie deren jeweilige Hash-Werte in Gruppen von als sicher eingestuften Systemen abfragen, um Anwendern dabei zu helfen, auf ihre Umgebung zugeschnittene Whitelists zu erstellen und zu pflegen.
Der Sensor „DLL Load Order Hijacking“ ist ein Beispiel für die Bemühungen unseres Endpoint Detection and Response-Teams, die Untersuchung von Vorfällen zu vereinfachen und Unternehmen dabei zu unterstützen, proaktiv nach den „Unbekannten“ in einer Umgebung zu suchen.
In den kommenden Monaten werden wir regelmäßig in unserem Blog über weitere neue Funktionen und Fallstudien berichten.
Bleiben Sie auf dem Laufenden!
Möchten Sie Tanium in Aktion erleben? Vereinbaren Sie unter eine individuelle Vorführung oder nehmen Sie an unserem wöchentlichen Webinar teil. Sprechen Sie mit unseren Tanium-Experten bei unseren bevorstehenden Veranstaltungen im Rahmen der „ “ unter.
