Was ist DLL-Hijacking und warum Ihr neues KI-Plugin der einfachste Einstieg sein könnte

Ich habe dieses Jahr viel Zeit damit verbracht, zu beobachten, wie Organisationen AI in Werkzeuge integrieren, die nie dafür gebaut wurden. Die meisten Risiken werden in Bezug auf Datenexposition oder Modellverhalten diskutiert. Weniger Aufmerksamkeit erhält etwas Grundlegenderes: der Installationsprozess selbst. Wenn ein Team ein AI-Plugin an eine Legacy-Desktop-Anwendung anfügt, fügen sie oft eine neue ausführbare Datei, eine neue Reihe von Abhängigkeiten und einen neuen Satz von Ordnern hinzu, die Windows durchsucht, wenn die Anwendung eine DLL laden will. Das ist eine vertraute Konstellation für jeden, der DLL-Hijacking über die Jahre verfolgt hat, und sie wird immer häufiger.

Was ist DLL-Hijacking

Windows-Anwendungen laden ihre DLLs nicht immer von einem festen, vertrauenswürdigen Ort. Wenn eine Anwendung eine DLL nach Namen statt nach vollständigem Pfad anfordert, durchsucht Windows eine festgelegte Reihenfolge von Verzeichnissen, um sie zu finden. Wenn ein Angreifer eine bösartige DLL mit dem richtigen Dateinamen irgendwo früher in dieser Suchreihenfolge platzieren kann, lädt die Anwendung den Code des Angreifers anstelle der legitimen Bibliothek und zwar mit den Rechten, die die Anwendung bereits besitzt.

Dies ist keine neue Technik. Sie ist seit Jahren als Schwachstelle dokumentiert und funktioniert weiterhin, weil viele Desktop-Anwendungen, insbesondere ältere oder schlecht gestaltete, DLLs noch immer nach Namen statt nach vollständigem Pfad laden. Was sich geändert hat, ist die Angriffsfläche. Jedes Plugin, Add-on oder KI-gestützte Erweiterung, die in eine Legacy-App installiert wird, bietet eine neue Gelegenheit für einen schlecht kontrollierten Ordner, eine nicht signierte Abhängigkeit oder ein beschreibbares Verzeichnis im Suchpfad.

Beispiel für DLL-Hijacking

Stellen Sie sich ein Ingenieurteam vor, das eine seit einem Jahrzehnt eingesetzte CAD-Anwendung betreibt. Die IT fügt ein KI-Plugin hinzu, das den Benutzern eine intelligente Such- und Zusammenfassungsebene über ihre Zeichnungen bietet. Wie viele Software in dieser Kategorie lädt die CAD-App eine ihrer Hilfs-DLLs nach Namen statt nach vollständigem Pfad, eine Designentscheidung, die niemand hinterfragte, da sie nie ein sichtbares Problem verursachte.

Ein Angreifer mit auch nur begrenztem Zugriff auf diese Maschine, etwa durch Phishing, ein kompromittiertes Konto oder einen anderen Zugangspunkt, muss das AI-Plugin selbst nicht knacken. Er muss nur eine DLL mit demselben Dateinamen in einen Ordner legen, der in der Suchreihenfolge der App weiter vorne liegt. Beim nächsten Start der App lädt diese stattdessen die DLL des Angreifers, und der schädliche Code läuft mit denselben Rechten wie die CAD-Anwendung. Kein Exploit gegen das AI-Plugin nötig. Das Plugin hat dem Angreifer einfach einen neuen Ordner zum Arbeiten bereitgestellt.

So erkennen Sie DLL-Hijacking

Die Erkennung besteht meist darin, Verhaltensweisen zu beobachten, die nicht dem entsprechen, was eine legitime DLL tun sollte:

• Anwendungen, die DLLs nach Namen aus ungewöhnlichen oder vom Benutzer beschreibbaren Verzeichnissen laden, anstatt aus einem vollständig qualifizierten, vertrauenswürdigen Pfad
• Nicht signierte DLLs, die über Dienstprogramme wie rundll32.exe gestartet werden, ein häufiges Hijacking-Muster
• Dateiintegritätsüberwachung kennzeichnet Änderungen an DLLs, die zwischen Patch-Zyklen nicht geändert werden sollten
• Endpoint-Protokolle, die einen legitimen übergeordneten Prozess zeigen, gefolgt von einem unerwarteten oder nicht signierten DLL-Ladevorgang

Eine weitere Möglichkeit ist, die Dateiintegrität jeder DLL im Suchpfad (tatsächlich aller Dateien) zu überprüfen, indem deren Hashwerte mit einer bekannten guten Quelle verglichen werden.

Nichts davon ist exotisch. Es ist dieselbe Disziplin, die Sicherheitsteams bereits auf die Dateiintegrität und Prozessüberwachung anwenden, gezielt auf die Ordner gerichtet, in denen Drittanbieter-Plugins und Legacy-Apps typischerweise schwaches Ladeverhalten verursachen.

So verhindern Sie DLL-Hijacking

Prävention fällt im Allgemeinen in zwei Kategorien: die Anwendungen zu beheben und zu kontrollieren, was auf dem Endpoint ausgeführt werden darf.

Die Behebung der Anwendung bedeutet, vollständig qualifizierte Pfade für DLL-Ladevorgänge zu verwenden, die Ordnerberechtigungen so zu verschärfen, dass Standardbenutzer nicht in Verzeichnisse schreiben können, die die Anwendung durchsucht, und die Software des Anbieters auf dem neuesten Stand zu halten. Das ist die richtige langfristige Lösung, aber sie hängt davon ab, dass jeder Anbieter die Arbeit macht, und viele der Anwendungen, die diesem Problem am meisten ausgesetzt sind, sind genau die, die am wenigsten wahrscheinlich schnell gepatcht werden.

Die Kontrolle des Endpunkts bedeutet, nicht auf den Anbieter warten zu müssen. PolicyPakDLL Hijack Protection von PolicyPak, Teil von Least Privilege Manager, läuft in drei Modi: Audit, das riskante DLL-Ladevorgänge protokolliert, ohne sie zu blockieren, damit Teams die Gefährdung zuerst bewerten können; Safe Elevated, das riskantes DLL-Laden für erhöhte Prozesse blockiert; und Anti-Hijack, das diese Blockierung auf reguläre Prozesse ausdehnt, die von geschützten Orten wie Program Files ausgeführt werden. Es stoppt direkt die zwei häufigsten Hijack-Muster: eine Anwendung, die eine DLL mit einem unqualifizierten Namen statt eines vollständigen Pfads lädt, und eine unsignierte DLL, die über ein Dienstprogramm wie rundll32.exe gestartet wird. Wenn eine legitime DLL versehentlich blockiert wird, können Administratoren sie per Dateipfad, digitaler Signatur oder Dateihash zulassen, ohne den Schutz vollständig auszuschalten.

Wenn Ihr Team KI-Funktionen in Anwendungen einführt, die vor dieser Diskussion entstanden sind, verdient DLL-Hijacking einen Platz im Risikoregister, nicht als hypothetisches Szenario, sondern als kurzfristige Folge der Art und Weise, wie diese Plugins installiert werden.