DLL-Injection und DLL-Hijacking: Risiken und Erkennung

Alpha-Leitfaden » Spiele » DLL-Injection und DLL-Hijacking: Risiken und Erkennung

Wenn wir über DLL-Injection und DLL-Hijacking in Windows sprechen , geht es nicht nur um eine technische Kuriosität, sondern um eine der beliebtesten Methoden von Angreifern, um in Systeme einzudringen, Daten zu stehlen und mit erhöhten Berechtigungen zu agieren, ohne Verdacht zu erregen. Es handelt sich um eine Gruppe altbekannter Techniken, die nach wie vor hochwirksam sind, da sie etwas so Grundlegendes wie die Art und Weise ausnutzen, wie Windows Bibliotheken in den Speicher lädt.

Haben Sie sich jemals gefragt, warum eine einzige schädliche DLL-Datei ein ganzes Unternehmen lahmlegen kann ? Hier die Antwort: Ein legitimer Prozess muss lediglich eine manipulierte Bibliothek laden, damit der Angreifercode alle Berechtigungen erbt, viele Antivirenprogramme umgeht und im schlimmsten Fall monatelang auf dem System verbleibt. Wir erklären Ihnen im Detail, wie das funktioniert, welche Techniken es gibt, welche Risiken damit verbunden sind und wie Sie die Auswirkungen erkennen und minimieren können.

Was ist eine DLL und warum ist sie für Angreifer so interessant?

Eine DLL (Dynamic-Link Library) ist im Wesentlichen eine gemeinsam genutzte Bibliothek, die Code und Daten enthält, die von mehreren Anwendungen gleichzeitig verwendet werden können. Windows nutzt DLLs häufig, um Code-Duplizierung zu vermeiden und Speicher, Festplattenspeicher und Systemressourcen effizienter zu verwalten.

Aus Nutzersicht ist das Ganze recht unkompliziert: Sie öffnen sich nicht wie ein normales Programm , sondern werden von der jeweiligen Anwendung, die sie benötigt, transparent eingebunden. Für das System hingegen sind sie kritische Komponenten: Sie enthalten Funktionen, Grafikressourcen, Treiber und diverse Routinen, die für das Funktionieren der Software unerlässlich sind.

Die meisten dieser Dateien enden auf .dll , sie können aber auch als .drv-, .drov- oder sogar als .exe-Dateien auftreten, die als Bibliotheken fungieren. Eine einzelne Datei kann von mehreren Prozessen gleichzeitig aufgerufen werden . Das bedeutet, dass ein Angreifer, wenn diese Datei kompromittiert wird, mehrere Anwendungen gleichzeitig infiltrieren kann.

Das ist das Schöne (und das Problem): Wenn es Ihnen gelingt, einen Prozess dazu zu bringen, eine manipulierte DLL zu laden , wird der Code in dieser Bibliothek mit den Berechtigungen dieses Prozesses ausgeführt, egal ob es sich um eine Benutzeranwendung, einen privilegierten Dienst oder sogar um Sicherheitssoftware handelt, die Sie paradoxerweise eigentlich schützen sollte.

DLL-Hijacking: Konzept und Funktionsweise

DLL- Hijacking ist eine Technik, die die Art und Weise ausnutzt, wie manche Windows-Anwendungen nach den benötigten Bibliotheken suchen. Anstatt immer den genauen Pfad zu jeder DLL anzugeben, überlassen viele Programme die Suche dem System.

Das Problem entsteht, wenn eine Anwendung versucht, eine DLL anhand ihres Namens zu laden, ohne den vollständigen Pfad anzugeben und ohne deren Integrität oder Herkunft zu überprüfen. Gelingt es einem Angreifer, eine schädliche Datei mit demselben Namen wie die erwartete DLL in einem zugänglichen Verzeichnis abzulegen, könnte Windows die gefälschte Datei vor der legitimen laden und dem Angreifer so die Kontrolle über den Prozess verschaffen.

Diese Technik ist seit Windows 2000 bekannt und funktioniert noch immer, da sich der grundlegende Suchmechanismus kaum verändert hat: Das System durchsucht mehrere Verzeichnisse in einer bestimmten Reihenfolge, bis es die Datei findet. Genau diese Reihenfolge nutzt ein Angreifer aus, um seine manipulierte Version weiter oben in der Liste einzuschleusen.

In der Praxis wurde DLL-Hijacking bei Lieferkettenangriffen eingesetzt , um vertrauenswürdige Lieferanten zu kompromittieren und digital signierte, aber bösartige DLLs zu verbreiten, wie es beispielsweise beim SolarWinds-Vorfall geschah, bei dem eine einfache veränderte Bibliothek einen massiven Angriff auf US-Regierungsbehörden auslöste.

DLL-Suchreihenfolge in Windows und wo die Sicherheitslücke ausgenutzt wird

Windows-Anwendungen verwenden eine standardmäßige DLL-Suchreihenfolge, wenn kein vollständiger Pfad angegeben wird. Dieses Verhalten hängt auch davon ab, ob der „sichere DLL-Suchmodus“ aktiviert ist.

Bei aktivierter sicherer Routensuche priorisiert das System zuverlässigere Routen. Die typische Reihenfolge ist:

• Verzeichnis, aus dem die Anwendung geladen wird.
• Systemverzeichnis (üblicherweise C:\Windows\System32).
• 16-Bit-Systemverzeichnis.
• Windows-Verzeichnis.
• Das aktuelle Arbeitsverzeichnis des Benutzers.
• Verzeichnisse, die in der Umgebungsvariablen definiert sind PATH.

Wenn die sichere Suche deaktiviert ist, rückt das aktuelle Benutzerverzeichnis in der Suchhierarchie nach oben und wird vor bestimmten Systempfaden überprüft. Diese kleine Änderung genügt, damit eine vom Angreifer im Arbeitsverzeichnis platzierte DLL anstelle der Originaldatei geladen wird.

Stellen Sie sich eine Anwendung vor, die eine bestimmte DLL-Datei in C:\Windows\System32 benötigt , deren Code diesen Pfad aber nicht explizit angibt. Das System durchsucht zuerst das Anwendungsverzeichnis und dann (je nach Konfiguration) das aktuelle Verzeichnis oder andere Verzeichnisse, bevor es System32 erreicht. Falls ein Angreifer unterwegs eine modifizierte Kopie hinterlässt , öffnet die Anwendung diese in der Annahme, es handele sich um das Original.

Dies wird als DLL-Suchreihenfolge-Hijacking bezeichnet . Der Angriffsvektor ist einfach: Die schädliche DLL wird in einem Verzeichnis platziert, das Windows vor dem legitimen Verzeichnis durchsucht. Die Methoden, um dies zu erreichen, können vielfältig sein: Social Engineering, Phishing, Schreiben in freigegebene Pfade, Bereitstellung über Anbieter usw.

Häufige Varianten des DLL-Hijackings

Das Grundkonzept (das Einschleusen einer schädlichen DLL in den normalen Programmablauf) führt zu verschiedenen technischen Varianten . Sie alle verfolgen dasselbe Ziel, unterscheiden sich aber in den Details der Einfügung der Bibliothek in den Prozess.

Eine dieser Schwachstellen nutzt KnownDLLs aus , eine Liste bekannter System-DLLs, die in der Windows-Registrierung verwaltet wird. Fordert eine Anwendung eine dieser Bibliotheken an, konsultiert der Loader zunächst diese spezielle Liste. Durch Manipulation der zugehörigen Registrierungsschlüssel kann ein Angreifer den KnownDLLs-Filter umgehen und das System zwingen, den Namen anhand einer eigenen, manipulierten Version aufzulösen.

Eine weitere gängige Technik ist das seitliche Laden von DLLs , das das WinSxS-Verzeichnis (C:\Windows\WinSxS) ausnutzt. Dieses Verzeichnis enthält mehrere Versionen derselben Bibliothek , um Konflikte zwischen Anwendungen zu vermeiden. Ein Programm fragt ein Manifest ab, das angibt, welche Versionen es verwenden darf. Ein Angreifer kann eine gefälschte DLL in dieses Verzeichnis einschleusen, indem er deren Metadaten manipuliert, sodass sie laut Manifest gültig erscheint und somit die entsprechende Version geladen wird.

Es gibt auch das sogenannte Phantom-DLL-Hijacking , das alte oder selten verwendete Bibliotheken ausnutzt, die manche Anwendungen beim Start immer noch laden, obwohl sie nicht mehr zwingend erforderlich sind. Erstellt ein Angreifer eine DLL mit diesem „vergessenen“ Namen und platziert sie im korrekten Pfad, kann er unbemerkt Schadcode ausführen, da die Originaldatei oft gar nicht mehr existiert.

In allen Fällen ist das Ziel dasselbe: die gefälschte DLL zur richtigen Zeit am richtigen Ort und unter einem Namen zu platzieren, nach dem der Zielprozess sucht, damit das Betriebssystem den Code des Angreifers innerhalb des legitimen Prozesses lädt und ausführt.

DLL-Injection: Wenn der Angreifer das Laden der DLL in den Speicher erzwingt.

Neben der passiven Manipulation der Suchreihenfolge gibt es auch die aktive DLL-Injektion in Prozesse . Hierbei wartet der Angreifer nicht darauf, dass das Programm den falschen Pfad einschlägt, sondern nutzt die Windows-API, um einen Prozess zum Laden seiner Bibliothek zu zwingen.

Die Idee ist simpel, aber wirkungsvoll: Durch das Einschleusen einer DLL in einen laufenden Prozess erbt die Schadsoftware dessen Berechtigungen und greift auf dessen Speicherbereich zu. Von dort aus kann sie Tastatureingaben protokollieren, Screenshots erstellen, Daten stehlen, Aufrufe von Sicherheitsfunktionen abfangen, weitere Schadsoftware installieren oder das Verhalten der Anwendung verändern.

Die Injection umfasst üblicherweise mehrere Phasen: Vorbereiten der DLL (mit einer DllMain-Funktion , die die Nutzlast beim Laden ausführt), Reservieren von Speicher im Zielprozess zum Speichern des Pfads zu dieser DLL, Schreiben dieses Pfads mit WriteProcessMemory und schließlich Erstellen eines Remote-Threads, der LoadLibraryA innerhalb des Zielprozesses aufruft .

Die eingeschleuste DLL wird im Kontext dieses Prozesses ausgeführt und nutzt dessen Sicherheitstoken und Vertrauensstufe. Dies ermöglicht unter anderem die Umgehung dateibasierter Sicherheitskontrollen , da der Schadcode nur im Speicher existiert, oder die Deaktivierung von Schutzmechanismen innerhalb der eigenen Prozesse.

Unterschiede zwischen der Programmierung bösartiger EXE- und DLL-Dateien

Wenn ein Malware-Entwickler eine ausführbare Datei (.exe) oder eine DLL erstellt, ändern sich Einstiegspunkt und Ausführungsmodell grundlegend. Bei einer typischen EXE ruft das System beim Start des Prozesses eine Hauptfunktion (oder WinMain) auf; bei einer DLL verläuft dieser Ablauf anders.

Dynamische Bibliotheken verwenden eine spezielle Funktion namens DllMain , die als Einstiegspunkt dient, wenn die DLL geladen oder entladen wird oder wenn Threads innerhalb des zugehörigen Prozesses erstellt oder beendet werden. Der Loader startet die DLL nicht als eigenständiges Programm, sondern ruft DllMain bei verschiedenen Ereignissen auf.

Viele legitime DLLs exportieren verschiedene Funktionen zur Verwendung durch andere Module. Im Gegensatz dazu könnte eine bösartige DLL, die ausschließlich für die Einschleusung von Schadcode entwickelt wurde, einfach die Klasse `DllMain` mit dem notwendigen Code implementieren und nichts exportieren, sodass ihre Ausführung unmittelbar nach dem Laden erfolgt, ohne dass weitere explizite Aufrufe erforderlich sind.

Dies bedeutet, dass der Angreifer beim Kompilieren und Verlinken seiner DLL besonders sorgfältig vorgehen muss: welche Abhängigkeiten er hinzufügt, welche Laufzeitoptionen er verwendet und wie er die Kompatibilität zwischen verschiedenen Windows-Versionen oder zwischen 32-Bit- und 64-Bit-Architekturen verwaltet.

Typische Entwicklungsumgebung für bösartige DLLs

Zum Kompilieren von Test-DLLs oder tatsächlichem Schadcode werden häufig Visual Studio unter Windows (einschließlich Visual Basic-Projekten ) oder plattformübergreifende Tools wie mingw-w64 unter Linux verwendet. Im ersten Fall erstellt man einfach ein C/C++-Projekt und konfiguriert es als dynamische Bibliothek, sodass die IDE automatisch die notwendige Struktur generiert.

In den Build-Optionen ist es üblich, den Abschnitt „Codegenerierung“ anzupassen . Beispielsweise kann man während der Entwicklung „Multithreaded Debug (/MTd)“ auswählen , um Debugging-Informationen einzubinden, und in der finalen Version auf „Multithreaded (/MT)“ umschalten . Dadurch wird die Laufzeitbibliothek direkt in die Binärdatei integriert, was die Ausführung auf mehr Rechnern ohne externe Abhängigkeiten vereinfacht.

Unter Linux können Sie mit x86_64-w64-mingw32-gcc ausführbare Dateien und DLLs für Windows generieren. Üblicherweise werden Optimierungsflags wie -O2 hinzugefügt, die Dateigröße mit -s reduziert und Funktionen sowie Daten (mit -ffunction-sections und -fdata-sections) segmentiert, um toten Code beim Linken zu eliminieren.

Optionen wie `-static-libstdc++` und `-static-libgcc` werden häufig verwendet , um die C- und C++-Standardbibliotheken statisch zu verlinken und so die resultierende Binärdatei in sich geschlossener zu gestalten. Weitere Parameter wie `-fno-exceptions`, `-fmerge-all-constants` und `-fpermissive` helfen, das Compilerverhalten feinabzustimmen und unnötigen Code zu reduzieren.

Remote-DLL-Injection: Eine technische Schritt-für-Schritt-Anleitung

Eine klassische Technik ist die Remote-DLL-Injektion , bei der ein vom Angreifer kontrollierter Prozess eine Bibliothek in einen anderen, legitimen Prozess einschleust. Der allgemeine Ablauf umfasst typischerweise mehrere wichtige Windows-API-Aufrufe.

Zunächst kann der bösartige Prozess die Debugging-Berechtigung SE_DEBUG_PRIVILEGE aktivieren, um die Berechtigung zur Manipulation anderer Prozesse zu erlangen. Anschließend öffnet er mit OpenProcess ein Handle zum Zielprozess und fordert Berechtigungen wie PROCESS_CREATE_THREAD oder PROCESS_VM_WRITE an, um in dessen Speicher zu schreiben und Threads zu erstellen.

Anschließend wird im Zielprozess mithilfe von VirtualAllocEx Speicher reserviert , in dem der vollständige Pfad der einzuschleusenden DLL gespeichert wird. Der Angreifer schreibt diesen Pfad mit WriteProcessMemory in den neu reservierten Bereich , sodass der Zielprozess nun einen Puffer mit dem Pfad der schädlichen DLL in seinem Adressraum besitzt.

Um die DLL zu laden, muss die Funktion LoadLibrary innerhalb des jeweiligen Prozesses aufgerufen werden. Diese Funktion befindet sich in der Datei kernel32.dll, die üblicherweise in allen Prozessen desselben Rechners auf dieselbe Adresse abgebildet ist. Der Angreifer erlangt mithilfe von GetModuleHandle ein Handle für das Modul und ermittelt anschließend mithilfe von GetProcAddress die genaue Adresse von LoadLibrary.

Schließlich wird mit `CreateRemoteThread` ein Remote-Thread erstellt , wobei die Adresse von `LoadLibrary` als Einstiegspunkt und der Zeiger auf den Puffer mit dem DLL-Pfad als Parameter angegeben werden. Sobald der Thread im Zielprozess startet, führt er `LoadLibrary` mit diesem Pfad aus, lädt die schädliche DLL in seinen Speicherbereich und ruft dessen `DllMain`-Methode auf.

Andere Prozessinjektionsverfahren und ihre Gefahren

Die Remote-DLL-Injektion ist nur ein Teil des Puzzles. Unter dem Begriff der Prozessinjektion gibt es viele Varianten, die alle dasselbe Ziel verfolgen: einen anderen Prozess dazu zu bringen, beliebigen Code in seinem eigenen Kontext auszuführen.

Eine der häufigsten Methoden ist die direkte Code-Injektion , bei der anstatt einer DLL direkt Shellcode in den Speicher des Zielprozesses geschrieben wird. Der Ablauf ist ähnlich: Der Prozess wird geöffnet, Speicher wird mit VirtualAllocEx reserviert, die Payload wird mit WriteProcessMemory geschrieben und ihre Ausführung mit CreateRemoteThread oder anderen Mechanismen ausgelöst.

Eine weitere Variante ist das Thread-Hijacking , bei dem keine neuen Threads erstellt, sondern ein bestehender Thread übernommen wird. Der Angreifer hält diesen mit `SuspendThread` an, liest dessen Kontext mit `GetThreadContext`, ändert den Befehlszeiger so, dass er auf seinen eigenen Code verweist, und setzt ihn mit `ResumeThread` fort. Auf diese Weise wird der Schadcode getarnt als legitimer Thread ausgeführt.

Die Asynchrone Prozeduraufruf-Injektion (APC-Injektion) verwendet QueueUserAPC, um eine Routine in einem Thread im Wartezustand in die Warteschlange einzureihen. Sobald der Thread seine APC-Warteschlange verarbeitet hat, führt er den injizierten Code aus, ohne dass die Erstellung eines neuen Remote-Threads unmittelbar erkennbar ist.

Die reflexive DLL-Injektion ist besonders schwer zu tarnen , da die DLL selbst einen integrierten Loader enthält, der sich in den Speicher einbinden kann, ohne Daten auf die Festplatte zu schreiben oder den Standardmechanismus LoadLibrary zu verwenden. Dies macht die Erkennung anhand von Dateisystemaktivitäten und Modulladeereignissen extrem schwierig.

Schließlich erzeugt das sogenannte Process Hollowing einen legitimen Prozess im angehaltenen Zustand, löscht dessen ursprünglichen Speicherabbild (mithilfe von Funktionen wie NtUnmapViewOfSection), allokiert neuen Speicher, schreibt den schädlichen PE-Code hinein, passt Header und Relokationen an, korrigiert den Hauptthread-Kontext mit SetThreadContext und setzt die Ausführung fort. Für das System scheint die legitime Anwendung zu laufen, tatsächlich wurde ihr Inhalt jedoch durch den Code des Angreifers ersetzt.

Grundlagen der Speicherverwaltung in Windows

Um zu verstehen, warum diese Techniken funktionieren, ist es unerlässlich, die Struktur des virtuellen Speichers eines Prozesses unter Windows zu verstehen. Jeder Prozess verfügt über einen eigenen, isolierten virtuellen Adressraum, der in 32 Bit ungefähr von 0 bis 0x7FFFFFFF reicht und in 64 Bit deutlich größer ist.

Dieser Speicherbereich ist in verschiedene Regionen unterteilt: den ausführbaren Code des Programms, die geladenen DLLs, Thread-Stacks , Heaps und andere reservierte Bereiche. Der Speichermanager des Systems ist für die Zuordnung dieser virtuellen Adressen zu physischen Speicherbereichen mittels Paging zuständig.

Jeder Region sind Zugriffsschutzmechanismen zugeordnet , die festlegen, was mit ihr geschehen darf: PAGE_READ, PAGE_WRITE, PAGE_EXECUTE, Kombinationen wie PAGE_EXECUTE_READWRITE usw. Versucht ein Prozess, unberechtigt zuzugreifen, generiert Windows eine Zugriffsverletzung.

Injection-Techniken nutzen diese Schutzmechanismen aus, indem sie Speicher mit spezifischen Berechtigungen anfordern, Attribute mit VirtualProtect oder VirtualProtectEx ändern , Daten aus anderen Prozessen mit ReadProcessMemory lesen oder Speicherbereiche mit VirtualFreeEx freigeben. Viele EDR-Erkennungssysteme basieren auf der Beobachtung verdächtiger Zeichenketten dieser prozessübergreifenden Aufrufe.

Zusammenfassend lässt sich sagen, dass das über die API verwaltete isolierte Speichermodell es einem Prozess leicht macht, auf den Speicher eines anderen Prozesses zuzugreifen, sofern er die entsprechenden Berechtigungen erhält. Dies nutzt Malware gerne aus, während sie versucht, sich vor den Abwehrmechanismen zu verstecken.

Persistenz mithilfe von AppInit_DLLs und damit verbundene Risiken

Abgesehen von einmaligen Schadsoftwareangriffen missbraucht manche Malware Windows-Mechanismen, um bei jedem Systemstart oder beim Ausführen bestimmter Anwendungen persistent zu bleiben . Ein klassisches Beispiel hierfür ist die Verwendung des Registrierungsschlüssels AppInit_DLLs.

Durch die Modifizierung dieses Schlüssels veranlasst der Angreifer das Laden einer bestimmten DLL in praktisch jedem Prozess, der user32.dll verwendet – also in fast allen Anwendungen mit grafischer Benutzeroberfläche. Dies führt dazu, dass die schädliche DLL bei jedem Programmstart automatisch eingeschleust wird, bevor die Anwendung ihre normale Ausführung beginnt.

Ein typisches Muster, das in realen Beispielen beobachtet wird, besteht darin, dass eine schädliche ausführbare Datei eine weitere Datei (z. B. eine neue .exe-Datei) erstellt und deren regelmäßige Ausführung mithilfe der Windows-Aufgabenplanung plant . Diese Aufgabe wird bei jedem Systemstart ausgeführt, und die zweite Binärdatei schreibt die schädliche DLL auf die Festplatte und konfiguriert AppInit_DLLs so, dass sie darauf verweist.

Ab diesem Zeitpunkt trägt jeder Grafikprozess die DLL mit sich , die erkennen kann, welche Anwendung geladen wird, und entscheiden kann, ob sie aktiv wird oder sich unauffällig aus dem Speicher entfernt, um nicht entdeckt zu werden. Beispielsweise könnte sie Prozesse wie den Taschenrechner ignorieren, aber in Browsern oder E-Mail-Clients verbleiben, um Anmeldeinformationen und sensible Daten zu stehlen.

Diese Art von Persistenz führt dazu, dass bösartiger Code ausgeführt wird, lange bevor der Benutzer überhaupt mit der Anwendung interagieren kann. Dadurch ist er auf den ersten Blick schwer zu erkennen und ermöglicht Angreifern eine recht tiefgreifende Kontrolle über die Benutzerumgebung.

Erkennung von DLL-Hijacking und -Injection

Die Erkennung dieser Techniken ist nicht trivial, da der Schadcode in vielen Fällen nur im Speicher existiert und innerhalb legitimer Prozesse ausgeführt wird . Mehrere Ansätze bieten jedoch in Kombination eine gute Chance, anomales Verhalten aufzudecken.

Eine der direktesten Methoden ist die Analyse der DLL-Ladeaktivität mithilfe von Tools wie Process Monitor oder Process Explorer. Durch Filtern nach Operationen im Zusammenhang mit Dateien, die auf .dll enden und Ergebnisse wie „Datei nicht gefunden“ liefern, lässt sich erkennen, wann ein Prozess versucht, Bibliotheken außerhalb der erwarteten Systemverzeichnisse zu finden.

Durch Anwenden zusätzlicher Filter auf den Ladepfad (z. B. das Anwendungsverzeichnis anstelle von System32) lassen sich externe DLLs identifizieren, die außerhalb des zulässigen Pfads geladen werden. Diese Dateiliste ist ein guter Ausgangspunkt für die Suche nach manipulierten Bibliotheken.

Andererseits überwachen viele moderne EDR-Lösungen verdächtige API-Muster : Sequenzen wie OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread oder massive Aufrufe von QueueUserAPC und SetThreadContext lösen Verhaltensregeln aus.

Der Scan analysiert außerdem ausführbare Speicherbereiche innerhalb jedes Prozesses und sucht nach Seiten mit Ausführungsberechtigungen, deren Inhalt jedoch nicht dem erwarteten Code der ursprünglichen Binärdatei entspricht. Speicherscanner können ungewöhnliche Sprünge, seltsame Speicherverschiebungen oder Blöcke von Shellcode erkennen, die dort nicht vorhanden sein sollten.

In der forensischen Analyse liefert die Untersuchung von Speicherabbildern und der Vergleich der digitalen Signaturen geladener DLLs mit ihren entsprechenden Datenträgerversionen eindeutige Hinweise auf Manipulationen. Weicht eine Bibliothek im Speicher von ihrer signierten Datenträgerversion ab, deutet dies stark auf mögliche Schadsoftware-Einschleusung oder -Patching hin.

Präventions- und Härtungsmaßnahmen gegen DLL-Injection

Ein System vollständig vor DLL-Injection und Bibliotheks-Hijacking zu schützen, ist kompliziert, aber es können Barrieren errichtet werden, die es dem Angreifer deutlich erschweren und die Auswirkungen verringern, falls er doch eindringen kann.

Die erste Herausforderung liegt bei den Softwareentwicklern: Anwendungen müssen unbedingt absolute Pfade angeben, wenn sie kritische DLLs laden, und dürfen sich nicht auf die Suchreihenfolge des Systems verlassen, um den Dateispeicherort zu bestimmen. Darüber hinaus empfiehlt es sich, die digitalen Signaturen von Bibliotheken vor deren Verwendung zu überprüfen.

Systemseitig ermöglichen Tools wie AppLocker oder Windows Defender Application Control (WDAC) die Einschränkung, welche ausführbaren Dateien und DLLs geladen werden dürfen. In Kombination mit Codeintegritätsrichtlinien blockieren sie unsignierte Module oder Module mit nicht vertrauenswürdigen Signaturen und verhindern so viele Hijacking-Versuche.

Wir dürfen Speicherschutzmaßnahmen wie DEP (Data Execution Prevention), die die Ausführung von Code aus Bereichen verhindert, die nur als Daten gekennzeichnet sind, oder ASLR (Address Space Layout Randomization), die es erschwert, die genauen Adressen von Modulen zu ermitteln und die Zuverlässigkeit einiger Exploits verringert, nicht vergessen.

Zusätzliche Schutzmechanismen wie Control Flow Guard (CFG) gewährleisten, dass indirekte Codeaufrufe nicht zu beliebigen Stellen springen, und geschützte Prozessmechanismen (PPL) beschränken, welche Prozesse Handler für andere öffnen können, wodurch die Angriffsfläche für prozessübergreifende Injections verringert wird.

Schließlich ist es auf Organisationsebene unerlässlich, Antivirensoftware und EDR auf dem neuesten Stand zu halten , regelmäßig die Schreibberechtigungen in Verzeichnissen zu überprüfen, in denen sich ausführbare Dateien und DLLs befinden, und die Mitarbeiter darin zu schulen, die anfänglichen Vektoren (Phishing, Anhänge, Downloads aus zweifelhaften Quellen) zu minimieren, die es ermöglichen, die erste schädliche DLL im System zu platzieren.

DLL-Injection, Bibliotheks-Hijacking und Prozess-Injection stellen im Allgemeinen ein altbewährtes, aber äußerst effektives Arsenal für Angreifer dar. Sie können Details des Modulladens in Windows ausnutzen, um Code in vertrauenswürdigen Prozessen zu verbergen , Berechtigungen zu erweitern und herkömmliche Sicherheitsvorkehrungen zu umgehen. Ein umfassendes Verständnis der Funktionsweise von DLLs, der Suchmethoden von Anwendungen, der verwendeten APIs zur Manipulation von Speicher und Prozessen sowie der verfügbaren Präventions- und Überwachungsmechanismen ist entscheidend dafür, ob eine einzelne manipulierte DLL ungehindert Schaden anrichten kann oder ob jeder Infiltrationsversuch eine deutliche Spur hinterlässt, die von den Verteidigungssystemen rechtzeitig erkannt und gestoppt werden kann.