🚨 Disclosure: DLL-Hijacking in Microsoft PowerToys 🚨 - Raik Schneider

Bereits im Februar 2025 habe ich eine Schwachstelle in den Sysinternals-Tools entdeckt und offengelegt, bei der Anwendungen DLLs unsicher aus dem Arbeitsverzeichnis laden. Die vollständige Analyse und das Disclosure dazu findest du hier.

Mit der Ankündigung im Sysinternals-Blog vom 29. Januar 2025, dass das beliebte Tool ZoomIt künftig Bestandteil der Microsoft PowerToys wird, war es naheliegend zu prüfen, ob diese Schwachstelle in der neuen Umgebung weiterbesteht. Leider hat sich genau das bestätigt.

Seht euch das Video hier an: https://youtu.be/55IVsDigXQ4

🔍 Was ist DLL-Hijacking?

Beim DLL-Hijacking (auch DLL Planting genannt) handelt es sich um eine Sicherheitslücke, bei der ein Angreifer eine präparierte DLL-Datei in das Arbeitsverzeichnis oder ein anderes Ladeverzeichnis der Anwendung platziert. Wird die DLL dann ohne sicheren Pfad geladen, führt das zur Ausführung von Schadcode.

Besonders relevant wird dies, wenn das Programm mit erhöhten Rechten läuft – was etwa bei Systemtools, Installer-Helpern oder Automatisierungswerkzeugen häufig der Fall ist.

⚙️ Die Lücke in PowerToys

In einem Test auf einer Windows 11-VM konnte ich zeigen, dass PowerToys-Tools wie ZoomIt und der Text-Extraktorpräparierte DLLs aus dem Arbeitsverzeichnis laden – ohne Pfadangabe und ohne Signaturprüfung.

Ich platzierte eine angepasste TextShaping.dll in das Installationsverzeichnis der PowerToys, die beim Laden einfach den Taschenrechner (calc.exe) öffnete. Beim Start von ZoomIt oder dem Text-Extraktor wurde dann tatsächlich der Rechner gestartet – ein klarer Beleg für das unsichere DLL-Ladeverhalten.

📁 Installation: Drei Varianten, ein Problem

Das Verhalten hängt stark davon ab, wie PowerToys installiert wurden:

Netzlaufwerk/portable Ausführung: Programme funktionieren auch von Netzlaufwerken – Angriffe dort besonders einfach
Systemweite Installation (Machine-wide): Schreibschutz durch Adminrechte – Angriff schwieriger, aber nicht ausgeschlossen
Benutzerspezifische Installation (Per-User): AppData-Verzeichnis ist voll beschreibbar – einfach ausnutzbar

Die Ausnutzung hängt also davon ab ob der Nutzer durch Social-Engineering oder der Angreifer selber entsprechende Dateien in das Arbeitsverzeichnis reinkopieren kann. Auch das potentielle „Rauskopieren“ von Dateien in ein beschreibbaren Verzeichnis (analog dem Szenario „Netzlaufwerk“ ist ein potentieller Angriffsvektor.

🔬 Technische Analyse: Der Fehler im Code

Im offiziellen GitHub-Repository der PowerToys ist die Datei dll.c für das Laden von DLLs verantwortlich. Die Funktion LoadLibrarySafe() prüft, ob erweiterte Ladeflags unterstützt werden – lädt die DLL aber bei fehlender Unterstützung ohne jeden Schutz:

Verwundbarer Codeabschnitt:

//=========================================================================-==
//
// LoadLibrarySafe
//
// Loads a DLL from the system folder in a way that mitigates DLL spoofing /
// side-loading attacks
//
//============================================================================
HMODULE LoadLibrarySafe(LPCTSTR libraryName, DLL_LOAD_LOCATION location)
{
    HMODULE hMod = NULL;

    if (NULL == libraryName || location <= DLL_LOAD_LOCATION_MIN || location >= DLL_LOAD_LOCATION_MAX) {

        SetLastError(ERROR_INVALID_PARAMETER);
        return NULL;
    }

    // LOAD_LIBRARY_SEARCH_SYSTEM32 is only supported on Window 7 or later. On earlier SKUs we could use a fully
    // qualified path to the system folder but specifying a path causes Ldr to skip SxS file redirection. This can 
    // cause the wrong library to be loaded if the application is using a manifest that defines a specific version 
    // of Microsoft.Windows.Common-Controls when loading comctl32.dll
    if (DLL_LOAD_LOCATION_SYSTEM == location) {

        DWORD flags = ExtendedFlagsSupported() ? LOAD_LIBRARY_SEARCH_SYSTEM32 : 0;
        hMod = LoadLibraryEx(libraryName, NULL, flags);
    }

    return hMod;
}

Im ursprünglichen Code wurde abhängig vom Betriebssystem geprüft, ob die erweiterten Sicherheitsflags (LOAD_LIBRARY_SEARCH_SYSTEM32) unterstützt werden. Falls nicht, wurde die DLL ohne jegliche Einschränkungen geladen.

Das bedeutet:

Wenn das Betriebssystem zu alt ist oder der Schutzmechanismus nicht verfügbar ist, wird LoadLibraryEx ohne Flagsaufgerufen. Und genau das ist das Problem:

Ohne zusätzliche Flags greift Windows auf die klassische DLL-Suchreihenfolge zurück – inklusive dem aktuellen Arbeitsverzeichnis, was für DLL-Hijacking oder Planting-Angriffe missbraucht werden kann.

Im neuen Code wird dieses Verhalten konsequent abgesichert. Es wird nur dann geladen, wenn LOAD_LIBRARY_SEARCH_SYSTEM32 verfügbar ist – andernfalls wird die Funktion bewusst mit einem Fehler beendet.

Überarbeiteter Code:

//=========================================================================-==
//
// LoadLibrarySafe
//
// Loads a DLL from the system folder in a way that mitigates DLL spoofing /
// side-loading attacks
//
//============================================================================
HMODULE LoadLibrarySafe(LPCTSTR libraryName, DLL_LOAD_LOCATION location)
{
    HMODULE hMod = NULL;

    // Nur genau definierter Parameter erlaubt
    if (libraryName == NULL || location != DLL_LOAD_LOCATION_SYSTEM) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return NULL;
    }

    // Nur auf unterstützten Systemen DLL sicher aus System32 laden
    if (ExtendedFlagsSupported()) {
        hMod = LoadLibraryEx(libraryName, NULL, LOAD_LIBRARY_SEARCH_SYSTEM32);
    } else {
        // Unsicheres Fallback verhindern
        SetLastError(ERROR_NOT_SUPPORTED);
        hMod = NULL;
    }

    return hMod;
}

Dadurch wird jede unsichere Ausführung unterbunden. Das ist sicherer, weil:

Kein automatischer Fallback auf unsichere Suchpfade.
Nur explizit erlaubte Ladeorte (System32) sind zulässig.
Unklare oder manipulierte Enum-Werte werden ausgeschlossen.

In sicherheitskritischen Komponenten (wie hier in PowerToys oder auch zuvor bei Sysinternals) darf ein Loader niemals unsichere Wege zulassen – selbst “für den Kompatibilitätsfall”. Moderne Systeme unterstützen LOAD_LIBRARY_SEARCH_SYSTEM32, und auf älteren Systemen ist ein kontrollierter Abbruch besser als ein potenzieller Exploit.

🪓 Microsofts Einschätzung

Die Schwachstelle wurde ordnungsgemäß an das Microsoft Security Response Center (MSRC) gemeldet. Die Rückmeldung lautete – wie schon bei der Sysinternals-Schwachstelle – dass kein Sicherheitsrisiko im klassischen Sinne vorliege.

⚖️ Vergleich mit ähnlichen Fällen und Würdigung

Schwachstelle	Tool / Komponente	MSRC-Einstufung
DLL-Hijacking in Sysinternals	ZoomIt, Autoruns etc.	Niedrig
DLL-Hijacking in PowerToys	ZoomIt, Text Extractor	Niedrig
DLL-Lücke im Taschenrechner (calc.exe)	Windows-Bestandteil	Niedrig
RDP Credential Caching Designfehler	Remote Desktop Service	Niedrig

Diese einheitlich niedrige Einstufung zeigt eine Systematik in der Risikoabschätzung, die aus technischer Sicht fragwürdig ist – insbesondere, wenn man die Schwachstellen als Teil einer Angriffskette betrachtet (z. B. nach initialer Code-Ausführung durch Social Engineering).

Viele Menschen, auch in der Sicherheitscommunity, fragen sich, ob diese Schwachstelle wirklich als kritisch eingestuft werden sollte – und ich möchte auf einige der Argumente eingehen, die hier aufgekommen sind.

Einige Stimmen behaupten:

“Es ist ein theoretischer Angriff, weil der Angreifer Zugriff auf das lokale System haben muss.”
“In modernen Installationen sind Programme im normalen Nutzerverzeichnis geschützt.”
“Die Ausnutzung dieser Lücke erfordert den physischen Zugriff auf das System oder Administratorrechte.”

Auf den ersten Blick scheint das berechtigt zu sein – schließlich wird die Schwachstelle im Arbeitsverzeichnisausgenutzt, was in vielen Fällen ein geschützter Bereich ist. Doch das stellt sich bei genauerer Betrachtung als zu kurz gedacht heraus:

Der Zugriff auf das Arbeitsverzeichnis ist oft keine Hürde für Angreifer. In Szenarien wie AppData-Installationen oder auf Netzlaufwerken sind Programme nicht vor manipulierten DLLs geschützt. Selbst der User kann problemlos Dateien im Programmverzeichnis ablegen und diese ausführen lassen.
Manipulierte DLLs sind ein bekanntes Angriffsszenario. Auch wenn der Angreifer nicht direkt aus der Ferne zugreifen kann, ermöglicht die Schwachstelle in Verbindung mit anderen Schwachstellen eine Erhöhung der Privilegien oder das Einführen von Malware in das System. Das macht die Lücke sehr wohl relevant.

Ich habe gezeigt, wie man durch die Platzierung einer manipulierten DLL (beispielsweise die TextShaping.dll) im Programmverzeichnis den Windows-Taschenrechner starten kann. Dieser Proof-of-Concept beweist, dass das Szenario in der Praxis ausgenutzt werden kann – und zwar auch ohne Administratorrechte.

Es ist zu beachten, dass Microsofts Risikoeinschätzungen oft konservative Schätzungen sind, die die Wahrscheinlichkeit einer Ausnutzung in Betracht ziehen. Doch die Realität der Bedrohungslage sieht häufig anders aus. Eine Schwachstelle in einem DLL-Loader, die Manipulationen durch ungeschützte Arbeitsverzeichnisse zulässt, ist immer noch ein relevantes Ziel für Angreifer, insbesondere in Kombination mit anderen Exploits. In Umgebunden wo z.B. mittels Härtung die Ausführung von Anwendungen außerhalb einer Whitelist unterbunden wird kann hier der eigene Code über die DLL im Kontext einer vertrauenswürdigen, geprüften Anwendung ausgeführt werden.

Die Kritikalität ist in diesem Fall nicht nur aus technischer Sicht zu beurteilen, sondern auch aus der Perspektive, wie diese Lücke somit in Angriffsketten verwendet werden kann. In vielen modernen Angriffen sind solche Schwachstellen der erste Schritt in eine eskalierende Kompromittierung eines Systems.

🧵 Fazit

Diese Schwachstelle zeigt: Selbst moderne Open-Source-Projekte wie PowerToys tragen jahrzehntealte Altlasten mit sich herum – oder übernehmen sie direkt aus Sysinternals. Obwohl Microsoft das Risiko herunterspielt, bleibt die Realität: Eine einfache DLL im richtigen Verzeichnis reicht, um beliebigen Code auszuführen – selbst bei gehärteten Systemen die eine Ausführung von nicht gewhitelisteten Anwendungen aktiv unterbinden.

Support

Ich habe für die Meldung der Sicherheitslücke keine Bug-Bounty erhalten, da sich Microsoft hinsichtlich Scope und Klassifizierung wieder einmal aus der Affäre zieht. Ich bin dankbar wenn sich Unterstützer meiner Arbeit in Form einer kleinen Spende erkenntlich zeigen würden:

💰Paypal: paypal.me/Einstein2150
💰ETH: 0xB25575423852AD370bD22B91C3683Dc80885C5fa
💰BTC: bc1q6pdev09mpp8ngn52gv8v9y6ygjzck3ksnc3y5x

👉 Folgt mir und abonniert meinen YouTube-Kanal, um sicherzustellen, dass ihr aktuelle Security-Tutorials und News im Bereich der IT-Security nicht verpasst!

🎥 Youtube: https://www.youtube.com/@rsfotovideoit