DLLHijackHunter

Von ProjectMerai

Automatisierte DLL-Hijacking-Erkennung, -Validierung und -Bestätigung
Lokale Fehlkonfigurationen in bewaffnete, bestätigte Angriffspfade verwandeln.

Überblick

DLLHijackHunter ist ein automatisiertes Windows-DLL-Hijacking-Erkennungstool, das über die statische Analyse hinausgeht. Es entdeckt, validiert und bestätigt DLL-Hijacking-Möglichkeiten mithilfe einer mehrphasigen Pipeline:

1. Erkennung — Durchsucht Binärdateien in Diensten, geplanten Aufgaben, Autostart-Elementen, COM-Objekten und AutoElevate-UAC-Bypass-Vektoren
2. Filterung — Eliminiert Fehlalarme durch intelligente harte und weiche Gates
3. Canary-Bestätigung — Setzt eine harmlose Canary-DLL ein und löst die Binärdatei aus, um zu beweisen, dass der Hijack funktioniert
4. Bewertung & Berichterstattung — Ordnet Ergebnisse nach Ausnutzbarkeit mit einem abgestuften Konfidenzsystem ein

Die meisten DLL-Hijacking-Tools stoppen bei „diese DLL könnte hijackbar sein.“ DLLHijackHunter versucht, sie zu validieren, sie mit bekannten Exploit-Intelligenzdaten abzugleichen und reale Ausführungspfade zu bestätigen, wo dies möglich ist.

Architektur

flowchart TB
    subgraph Phase1["Phase 1: Erkennung"]
        SE["Statische Engine<br/>Dienste, Aufgaben, Autostart,<br/>COM, Run-Keys"]
        AE["AutoElevate-Engine<br/>Manifest + COM-UAC-Bypass"]
        PE["PE-Analysator<br/>Import-Tabellen, verzögerte Ladungen,<br/>Manifeste, Exporte"]
        ETW["ETW-Engine<br/>Echtzeit-DLL-Lade-<br/>Überwachung"]
        SO["Suchreihenfolgen-<br/>Rechner"]
    end

    subgraph Phase2["Phase 2: Filter-Pipeline"]
        direction LR
        HG["Harte Gates<br/>(Binär-Kill)"]
        SG["Weiche Gates<br/>(Konfidenz-Anpassung)"]
    end

    subgraph Phase3["Phase 3: Lade-Verifizierung (--verify-load)"]
        LP["LoadProbe<br/>Kindprozess-Ladetest<br/>Probe-DLL platziert &amp; entfernt"]
    end

    subgraph Phase4["Phase 4: Canary"]
        CB["Canary-DLL-Builder"]
        TE["Trigger-Ausführer"]
        VF["Verifizierung"]
    end

    subgraph Phase5["Phase 5: Ausgabe"]
        SC["Abgestufter Bewerter"]
        RC["Konsolenbericht"]
        RJ["JSON-Bericht"]
        RH["HTML-Bericht"]
    end

    SE --> PE --> SO
    AE --> PE
    ETW --> SO
    SO --> Phase2
    HG --> SG
    Phase2 --> Phase3
    Phase3 --> Phase4
    CB --> TE --> VF
    Phase4 --> Phase5

Hauptfunktionen

Hijack-Typ-Abdeckung

IFEO-Debugger-Einträge werden aufgelistet und die referenzierte Binärdatei wird auf DLL-Importe analysiert, aber es gibt keinen dedizierten IFEO/KnownDLL-Bypass-Hijack-Typ — diese werden nicht als eigenständige Erkennungen beworben.

UAC-Bypass-Erkennung

DLLHijackHunter enthält eine dedizierte UAC-Bypass-Erkennung:

• Manifest-AutoElevate — Scannt System32 und SysWOW64 nach EXEs mit <autoElevate>true</autoElevate> in eingebetteten Manifesten
• COM-AutoElevation — Scannt HKLM\SOFTWARE\Classes\CLSID nach COM-Objekten mit Elevation\Enabled=1
• Side-Load-Simulation — Für AutoElevate-Binärdateien, die weder SetDllDirectory noch SetDefaultDllDirectories aufrufen, wird der Angriffspfad „EXE in beschreibbaren Ordner kopieren + DLL ablegen“ simuliert

Gezielte Schwachstellen-Wissensbasis

• Gezielte Schwachstellen-Zuordnung — Gleicht entdeckte Importe mit einem gebündelten Schnappschuss des HijackLibs-Datensatzes ab (≈590 dokumentierte DLL-Einträge, die ≈700 anfällige ausführbare Dateien umfassen), eingebettet als Resources/hijacklibs.json. Ein Treffer erhöht die Konfidenz und verlinkt den Befund auf seine HijackLibs-Referenzseite; das Fehlen eines Treffers bedeutet nichts. Der Datensatz ist datengetrieben — aktualisieren Sie ihn, indem Sie https://hijacklibs.net/api/hijacklibs.json über diese Ressource erneut herunterladen (keine Codeänderungen erforderlich). Datensatz © das HijackLibs-Projekt und seine Mitwirkenden.
• Automatisierte PATH-Ausnutzung — Bewertet beschreibbare PATH-Ordner und generiert Hijack-Kandidaten für eine kuratierte Zuordnung nativer Windows-Dienste, die bekanntermaßen PATH nach fehlenden DLLs durchsuchen
• Erweiterte Phantom-DLL-Suche — Durchsucht eine Bibliothek hochwertiger Phantom-DLL-Möglichkeiten in mehreren Kategorien

Filter-Pipeline

Die Pipeline reduziert Fehlalarme in zwei Stufen:

Harte Gates

• API-Set-Schema-Filterung (api-ms-*, ext-ms-*)
• KnownDLL-Filterung
• Angreifer-relative ACL-Schreibbarkeitsvalidierung — ein Pfad zählt nur dann als beschreibbar, wenn ein unprivilegierter Prinzipal (Users / Authenticated Users / Everyone, plus leckgeschützte Sub-Admin-Dienstkonten wie LOCAL SERVICE/NETWORK SERVICE) effektive Schreibrechte hat. Entscheidend ist, dass dies unabhängig vom Token berechnet wird, unter dem das Tool läuft, sodass ein erhöhter Lauf System32/Program Files nicht als beschreibbar erscheinen lässt. Genau das macht erhöhte Läufe für die LPE-Triage sinnvoll.

Weiche Gates

• WinSxS-Manifest-Strafe
• Privilegien-Delta-Analyse
• LoadLibraryEx-Minderungsprüfungen
• Signaturvalidierungsprüfungen
• Strafen für elegante Fehlerbehandlung

Canary-Bestätigung

Statt zu raten, versucht DLLHijackHunter zu beweisen, dass Hijacks funktionieren:

sequenceDiagram
    participant H as DLLHijackHunter
    participant B as Canary-DLL-Builder
    participant T as Trigger-Ausführer
    participant V as Opfer-Binärdatei

    H->>B: Canary-DLL erstellen
    B->>B: Vorkompilierte Canary extrahieren<br/>(oder Proxy mit MSVC kompilieren)
    B-->>H: canary.dll + Bestätigungsdateipfad
    H->>H: DLL am Hijack-Pfad platzieren
    H->>T: Binärausführung auslösen
    T->>V: Dienst starten / Aufgabe ausführen / COM aktivieren
    V->>V: Lädt Canary-DLL
    V-->>H: Schreibt Bestätigungsdatei<br/>PID, Privileg, Integritätsstufe
    H->>H: Aufzeichnen: BESTÄTIGT
    H->>H: Canary-DLL bereinigen

Die Canary-DLL:

• Wird vorkompiliert für x64 und x86 geliefert, eingebettet im Scanner, sodass zum Scanzeitpunkt kein Compiler erforderlich ist. Die korrekte Architektur wird passend zur Bitness des Opfers ausgewählt und bei Bedarf extrahiert.
• Ist selbstlokalisierend: Sie leitet ihren Bestätigungsdateipfad zur Laufzeit aus ihrem eigenen geladenen Modulpfad ab (%ProgramData%\DLLHijackHunter\canary_<hash>.confirm), sodass eine Binärdatei für jeden Kandidaten dient. Der Scanner berechnet denselben Hash aus dem Bereitstellungspfad und pollt auf diese Datei.
• Verwendet einen dateibasierten Bestätigungsmechanismus
• Erfasst Ausführungsmetadaten wie Benutzer, Integritätsstufe und Privilegienindikatoren
• Enthält keine schädliche Nutzlast; sie ist strikt ein Erkennungs- und Validierungsmechanismus
• Verknüpft die CRT statisch, sodass sie keine Laufzeitabhängigkeit (ucrtbase/vcruntime) auf dem Opfer-Host hat.

Die gebündelten Binärdateien werden aus der prüfbaren Quelle unter src/DLLHijackHunter/Resources/canary_src.c erstellt und können mit Resources/build_canary.bat neu generiert werden (erfordert die MSVC-C++-Toolchain; der Scanner nicht).

Funktions-Proxy-Ausnahme: Wenn ein Suchreihenfolgen-Hijack auf eine DLL abzielt, die existiert und Exporte bereitstellt, erfordert das Halten des Hosts nach der Bestätigung einen Export-Forwarding-Proxy, der pro DLL mit MSVC kompiliert wird (cl.exe, lokalisiert über vswhere/vcvarsall). Wenn keine Toolchain vorhanden ist, wird stattdessen die vorkompilierte Canary verwendet — sie bestätigt den Ladevorgang weiterhin (DllMain feuert), leitet aber keine Exporte weiter, sodass der Hostprozess nach der Aufzeichnung der Bestätigung möglicherweise abstürzt. Phantom-DLL- und andere Kandidaten ohne Exporte benötigen überhaupt keinen Compiler.

Signierung: Die eingebetteten Canaries sind unsigniert. Das Codesignieren (damit sie unter strengeren Richtlinien laden und zurechenbar sind) erfordert ein Signierzertifikat und bleibt ein Schritt zur Release-Zeit für den Maintainer.

Wichtiger Hinweis zum Proxy/Export-Forwarding-Modus

Proxy/Export-Forwarding-Canaries sind experimentell und Best-Effort. Einige Ziele laden möglicherweise nicht korrekt oder verhalten sich unerwartet, abhängig von:

• Nur-Ordinal-Exporten
• dekorierten Exportnamen
• Aufrufkonventions-Konflikten
• Loader-/Laufzeitannahmen im Zielprozess

Das bedeutet, dass eine fehlgeschlagene Proxy-Canary nicht immer bedeutet, dass der zugrunde liegende Hijack-Pfad unmöglich ist.

Lade-Reihenfolge-Verifizierung (--verify-load)

Eine optionale, Standard-Benutzer-Verifizierung, die zwischen der Filter-Pipeline und der Canary-Phase liegt. Für jeden anwendbaren Kandidaten schreibt sie kurzzeitig eine harmlose Probe-DLL an die beschreibbare Hijack-Position und fragt dann den echten Windows-Loader — in einem kurzlebigen Kindprozess — die DLL namentlich aufzulösen. Wo der Loader auflöst, bestimmt das Urteil:

• Verifizierter Gewinn — der Loader wählt die beschreibbare Position. Die Suchreihenfolgen-Behauptung ist bewiesen (diese Bestätigung lässt den Befund die Hohe Stufe erreichen; die Canary-Ausführung bleibt der einzige Weg zu Bestätigt).
• Verliert gegen Geschütztes — der Loader wählt stattdessen eine KnownDLL, die System32-Kopie oder eine SxS-umgeleitete Kopie. Die Position ist mit ziemlicher Sicherheit nicht hijackbar, sodass der Kandidat stark herabgestuft wird. Dies fängt die klassischen Fehlalarme ab, die ein statischer Suchreihenfolgen-Rechner übersieht (z. B. ein .local/Suchreihenfolgen-„Befund“ für ntdll.dll, den KnownDLLs nicht ausnutzbar macht).

Design- und Sicherheitshinweise:

• Läuft in einem Kindprozess, sodass ein bereits in den Scanner geladener Name das Ergebnis nicht kurzschließen kann und alle Lade-Nebeneffekte oder Abstürze isoliert sind. Keine Erhöhung erforderlich.
• Jede Probe wird platziert, aufgelöst und dann entfernt; jede vorhandene Datei wird gesichert und wiederhergestellt.
• Es modelliert die moderne LOAD_LIBRARY_SEARCH-Reihenfolge, sodass es nur auf Phantom-/Suchreihenfolgen-/Side-Load-Kandidaten angewendet wird. .local-, PATH- und AppInit/AppCert-Kandidaten verwenden andere Mechanismen und werden als Übersprungen gemeldet.
• Es schreibt Dateien transient an Kandidatenpositionen (mittlere Auswirkung); lassen Sie es für vollständig passive, schreibgeschützte Triage aus.

# Standard-Benutzer-Triage mit loader-verifizierter Suchreihenfolge (keine Canary, kein ETW)
.\DLLHijackHunter.exe --lpe-only --no-canary --no-etw --verify-load

Vergleich

Verwendung

Voraussetzungen

• Windows 10/11 oder Windows Server 2016+
• .NET 8.0- oder 10.0-Laufzeit (oder einen eigenständigen Build verwenden)
• Administratorrechte empfohlen (erforderlich für ETW, Canary-Bereitstellung und einige Dienst-Trigger)

Build

git clone https://github.com/ghostvectoracademy/DLLHijackHunter.git
cd DLLHijackHunter

# Build (eigenständige Einzeldatei)
dotnet publish src/DLLHijackHunter/DLLHijackHunter.csproj `
    -c Release -r win-x64 --self-contained `
    -p:PublishSingleFile=true -o ./publish

# Oder das Build-Skript verwenden
.\build.ps1

Schnellstart

# Vollständiger aggressiver Scan (empfohlen, erfordert Admin)
.\DLLHijackHunter.exe --profile aggressive

# Sicherer Scan (keine Dateiablagen, keine Trigger)
.\DLLHijackHunter.exe --profile safe

# UAC-Bypass-fokussierter Scan
.\DLLHijackHunter.exe --profile uac-bypass

# Eine bestimmte Binärdatei anvisieren
.\DLLHijackHunter.exe --target "C:\Program Files\MyApp\app.exe"

# Nach Dateinamen anvisieren (Teilübereinstimmung)
.\DLLHijackHunter.exe --target notepad.exe

# Nur bestätigte Befunde
.\DLLHijackHunter.exe --profile redteam --format json -o report.json

CLI-Optionen

DLLHijackHunter — Automatisierte DLL-Hijacking-Erkennung

Optionen:
  -p, --profile <profile>        Scan-Profil [Standard: aggressive]
                                   aggressive | strict | safe | redteam | uac-bypass
  -o, --output <pfad>            Ausgabedateipfad (Format wird automatisch erkannt)
  -f, --format <format>          Ausgabeformat [Standard: console]
                                   console | json | html
  -t, --target <ziel>            Bestimmte Binärdatei, Verzeichnis oder Dateiname anvisieren
      --min-confidence <wert>    Mindest-Konfidenzschwelle 0-100. Wenn weggelassen, gilt die
                                   Schwelle des jeweiligen Profils; die Übergabe überschreibt sie.
      --no-canary                Canary-Bestätigung deaktivieren
      --no-etw                   ETW-Laufzeiterkennung deaktivieren
      --verify-load              Suchreihenfolge mit dem echten Loader verifizieren (siehe unten).
                                   Standard-Benutzer; schreibt transient eine harmlose Probe.
      --confirmed-only           Nur canary-bestätigte Befunde anzeigen
      --lpe-only                 Strikte LPE-Suche: System32/Program Files ignorieren, nur
                                   standard-benutzerbeschreibbare Schwachstellen anzeigen
      --log-file <pfad>          Diagnose-Scanprotokoll in Datei schreiben
  -v, --verbose                  Ausführliche Ausgabe

Hinweis: --min-confidence wird nur dann als Überschreibung behandelt, wenn Sie es explizit übergeben. Andernfalls wird die Schwelle des ausgewählten Profils verwendet (z. B. safe = 50 %, strict = 80 %).

Scan-Profile

Bewertung

Jeder Befund erhält Konfidenz- und Auswirkungssignale, die zu einer endgültigen Priorisierungsstufe kombiniert werden.

Typische Auswirkungsüberlegungen umfassen:

• erlangtes Privileg
• Trigger-Zuverlässigkeit
• Tarnung
• Neustart-Persistenz

Bestätigte Canary-Ausführung sollte als das stärkste Validierungssignal behandelt werden.

Stufen-Gating: Die Hohe und Bestätigte Stufe sind Befunden vorbehalten, die durch ein Beweissignal gestützt werden — eine ausgelöste Canary, eine ETW-Laufzeit-Ladebeobachtung oder eine dokumentierte Wissensbasis-Übereinstimmung. Ein rein statischer Suchreihenfolgen-Treffer, so sauber er auch sein mag, ist an der Spitze der Mittleren Stufe gedeckelt und als Nur-statisch annotiert, sodass unverifizierte Heuristiken nie als hochkonfident erscheinen.

Empfohlene Triage-Konfiguration

Da die Schreibbarkeit angreifer-relativ bewertet wird, sind sowohl erhöhte als auch Standard-Benutzer-Läufe aussagekräftig:

• Für die LPE-Triage ist die vertrauenswürdigste Konfiguration ein Standard-Benutzer-Lauf mit --lpe-only (und --no-canary, wenn kein Compiler verfügbar ist) — jeder überlebende Befund ist wirklich von einem unprivilegierten Prinzipal beschreibbar.
• Erhöhte Läufe sind für ETW und Canary-Bestätigung erforderlich und sind jetzt sicher vor der historischen „alles in System32 sieht beschreibbar aus“-Umkehrung.

Sicherheit

DLLHijackHunter ist für defensive Sicherheitsforschung, Laborvalidierung, Audits und Red-Team-Simulationen in autorisierten Umgebungen konzipiert.

Verwenden Sie es nur auf Systemen und Netzwerken, die Sie besitzen oder für deren Bewertung Sie ausdrücklich autorisiert sind.

Betriebshinweise

• Der Canary-Modus schreibt Test-DLLs an Kandidatenpositionen
• Einige Trigger können Dienste/Aufgaben während der Validierung kurzzeitig starten oder stoppen
• Proxy/Export-Forwarding-Canaries können fragile Ziele destabilisieren
• Das Safe-Profil ist der bevorzugte Modus für die Produktionstriage, wenn Dateiablagen und Trigger nicht akzeptabel sind

Ausgabe

DLLHijackHunter unterstützt:

• Konsolenberichterstattung
• JSON-Export
• HTML-Export

Empfohlener Arbeitsablauf:

1. einen breiten Scan ausführen
2. hochkonfidente Befunde überprüfen
3. Canary-Bestätigung selektiv auf hochwertige Pfade anwenden
4. JSON/HTML-Ausgabe für Berichterstattung und Triage aufbewahren

Lizenz

MIT

Danksagungen

Erstellt von ProjectMerai.