DLLHijackHunter

Par ProjectMerai

Découverte, validation et confirmation automatisées du détournement de DLL
Transformer les mauvaises configurations locales en chemins d'attaque confirmés et exploitables.

Vue d'ensemble

DLLHijackHunter est un outil automatisé de détection de détournement de DLL sous Windows qui va au-delà de l'analyse statique. Il découvre, valide et confirme les opportunités de détournement de DLL grâce à un pipeline en plusieurs phases :

1. Découverte — Énumère les binaires à travers les services, les tâches planifiées, les éléments de démarrage, les objets COM et les vecteurs de contournement UAC AutoElevate
2. Filtration — Élimine les faux positifs grâce à des portes dures et souples intelligentes
3. Confirmation par canari — Déploie une DLL canari inoffensive et déclenche le binaire pour prouver que le détournement fonctionne
4. Notation et rapport — Classe les résultats par exploitabilité avec un système de confiance par niveaux

La plupart des outils de détournement de DLL s'arrêtent à « cette DLL pourrait être détournable ». DLLHijackHunter tente de la valider, de la recouper avec des renseignements d'exploitation connus et de confirmer les chemins d'exécution réels lorsque c'est possible.

Architecture

flowchart TB
    subgraph Phase1["Phase 1 : Découverte"]
        SE["Moteur statique<br/>Services, tâches, démarrage,<br/>COM, clés Run"]
        AE["Moteur AutoElevate<br/>Manifeste + contournement UAC COM"]
        PE["Analyseur PE<br/>Tables d'imports, chargements différés,<br/>manifestes, exports"]
        ETW["Moteur ETW<br/>Surveillance en temps réel<br/>des chargements de DLL"]
        SO["Calculateur d'ordre<br/>de recherche"]
    end

    subgraph Phase2["Phase 2 : Pipeline de filtrage"]
        direction LR
        HG["Portes dures<br/>(élimination du binaire)"]
        SG["Portes souples<br/>(ajustement de confiance)"]
    end

    subgraph Phase3["Phase 3 : Vérification du chargement (--verify-load)"]
        LP["LoadProbe<br/>Test de chargement en processus enfant<br/>DLL sonde placée et retirée"]
    end

    subgraph Phase4["Phase 4 : Canari"]
        CB["Générateur de DLL canari"]
        TE["Exécuteur de déclenchement"]
        VF["Vérification"]
    end

    subgraph Phase5["Phase 5 : Sortie"]
        SC["Notateur par niveaux"]
        RC["Rapport console"]
        RJ["Rapport JSON"]
        RH["Rapport HTML"]
    end

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

Fonctionnalités clés

Couverture des types de détournement

Les entrées IFEO Debugger sont énumérées et le binaire référencé est analysé pour ses imports de DLL, mais il n'existe pas de type de détournement IFEO/contournement KnownDLL dédié — ceux-ci ne sont pas présentés comme des détections autonomes.

Découverte de contournement UAC

DLLHijackHunter inclut une découverte dédiée des contournements UAC :

• AutoElevate par manifeste — Analyse System32 et SysWOW64 à la recherche d'EXE avec <autoElevate>true</autoElevate> dans les manifestes intégrés
• Autoélévation COM — Analyse HKLM\SOFTWARE\Classes\CLSID à la recherche d'objets COM avec Elevation\Enabled=1
• Simulation de chargement latéral — Pour les binaires AutoElevate qui n'appellent pas SetDllDirectory ou SetDefaultDllDirectories, simule le chemin d'attaque « copier l'EXE dans un dossier inscriptible + déposer la DLL »

Base de connaissances ciblée sur les vulnérabilités

• Cartographie ciblée des vulnérabilités — Recoupe les imports découverts avec un instantané intégré du jeu de données HijackLibs (≈590 entrées de DLL documentées couvrant ≈700 exécutables vulnérables), intégré sous Resources/hijacklibs.json. Une correspondance augmente la confiance et relie le résultat à sa page de référence HijackLibs ; l'absence de correspondance ne signifie rien. Le jeu de données est piloté par les données — actualisez-le en retéléchargeant https://hijacklibs.net/api/hijacklibs.json sur cette ressource (aucune modification de code requise). Jeu de données © le projet HijackLibs et ses contributeurs.
• Exploitation automatisée du PATH — Évalue les dossiers PATH inscriptibles et génère des candidats de détournement pour une carte organisée de services Windows natifs connus pour rechercher des DLL manquantes dans le PATH
• Recherche élargie de DLL fantômes — Recherche une bibliothèque d'opportunités de DLL fantômes à forte valeur dans plusieurs catégories

Pipeline de filtrage

Le pipeline réduit les faux positifs en deux étapes :

Portes dures

• Filtrage du schéma des ensembles d'API (api-ms-*, ext-ms-*)
• Filtrage KnownDLL
• Validation de l'inscriptibilité ACL relative à l'attaquant — un chemin ne compte comme inscriptible que si un principal non privilégié (Users / Authenticated Users / Everyone, plus les comptes de service sous-administrateurs sans fuite comme LOCAL SERVICE/NETWORK SERVICE) dispose de droits d'écriture effectifs. De manière cruciale, ceci est calculé indépendamment du jeton sous lequel l'outil s'exécute, donc une exécution élevée ne rend pas System32/Program Files inscriptibles. C'est ce qui rend les exécutions élevées significatives pour le triage LPE.

Portes souples

• Pénalité de manifeste WinSxS
• Analyse du delta de privilèges
• Vérifications des atténuations LoadLibraryEx
• Vérifications de validation de signature
• Pénalités de gestion d'erreurs gracieuses

Confirmation par canari

Au lieu de deviner, DLLHijackHunter tente de prouver que les détournements fonctionnent :

sequenceDiagram
    participant H as DLLHijackHunter
    participant B as Générateur de DLL canari
    participant T as Exécuteur de déclenchement
    participant V as Binaire victime

    H->>B: Construire la DLL canari
    B->>B: Extraire le canari précompilé<br/>(ou compiler un proxy avec MSVC)
    B-->>H: canary.dll + chemin du fichier de confirmation
    H->>H: Placer la DLL au chemin de détournement
    H->>T: Déclencher l'exécution du binaire
    T->>V: Démarrer le service / exécuter la tâche / activer COM
    V->>V: Charge la DLL canari
    V-->>H: Écrit le fichier de confirmation<br/>PID, privilège, niveau d'intégrité
    H->>H: Enregistrer : CONFIRMÉ
    H->>H: Nettoyer la DLL canari

La DLL canari :

• Est fournie précompilée pour x64 et x86, intégrée dans le scanner, donc aucun compilateur n'est requis au moment de l'analyse. L'architecture correcte est sélectionnée pour correspondre au bitness de la victime et extraite à la demande.
• Est auto-localisante : elle dérive le chemin de son fichier de confirmation à l'exécution depuis son propre chemin de module chargé (%ProgramData%\DLLHijackHunter\canary_<hash>.confirm), donc un seul binaire sert chaque candidat. Le scanner calcule le même hash depuis le chemin de déploiement et interroge ce fichier.
• Utilise un mécanisme de confirmation basé sur un fichier
• Capture des métadonnées d'exécution telles que l'utilisateur, le niveau d'intégrité et les indicateurs de privilège
• Ne contient aucune charge malveillante ; c'est strictement un mécanisme de détection et de validation
• Lie statiquement le CRT, donc aucune dépendance d'exécution (ucrtbase/vcruntime) sur l'hôte victime.

Les binaires intégrés sont construits à partir du code source auditable dans src/DLLHijackHunter/Resources/canary_src.c et peuvent être régénérés avec Resources/build_canary.bat (nécessite la chaîne d'outils MSVC C++ ; le scanner ne l'exige pas).

Exception de proxy fonctionnel : Lorsqu'un détournement d'ordre de recherche cible une DLL qui existe et expose des exports, maintenir l'hôte en vie après confirmation nécessite un proxy de transfert d'exports, compilé par DLL avec MSVC (cl.exe, localisé via vswhere/vcvarsall). Si aucune chaîne d'outils n'est présente, le canari précompilé est utilisé à la place — il confirme toujours le chargement (DllMain se déclenche) mais ne transfère pas les exports, donc le processus hôte peut planter après l'enregistrement de la confirmation. Les candidats DLL fantômes et autres sans exports ne nécessitent aucun compilateur.

Signature : Les canaris intégrés ne sont pas signés. Les signer avec un certificat de code (pour qu'ils se chargent sous des politiques plus strictes et soient attribuables) nécessite un certificat de signature et est laissé comme étape au moment de la publication pour le mainteneur.

Note importante sur le mode proxy/transfert d'exports

Les canaris proxy/transfert d'exports sont expérimentaux et au mieux. Certaines cibles peuvent ne pas se charger correctement ou se comporter de manière inattendue selon :

• les exports uniquement par ordinal
• les noms d'exports décorés
• les incompatibilités de conventions d'appel
• les hypothèses du chargeur/exécution dans le processus cible

Cela signifie qu'un canari proxy échoué ne signifie pas toujours que le chemin de détournement sous-jacent est impossible.

Vérification de l'ordre de chargement (--verify-load)

Une vérification optionnelle, pour utilisateur standard, qui se situe entre le pipeline de filtrage et la phase canari. Pour chaque candidat applicable, elle écrit brièvement une DLL sonde bénigne à la position de détournement inscriptible, puis demande au vrai chargeur Windows — dans un processus enfant de courte durée — de résoudre la DLL par nom. Là où le chargeur résout détermine le verdict :

• Victoire vérifiée — le chargeur choisit la position inscriptible. La revendication d'ordre de recherche est prouvée (cette corroboration permet au résultat d'atteindre le niveau Élevé ; l'exécution du canari reste le seul chemin vers Confirmé).
• Perd face au protégé — le chargeur choisit une KnownDLL, la copie System32 ou une copie redirigée SxS à la place. La position n'est presque certainement pas détournable, donc le candidat est fortement rétrogradé. Cela capture les faux positifs classiques qu'un calculateur d'ordre de recherche statique manque (par exemple un « résultat » .local/ordre de recherche pour ntdll.dll que KnownDLLs rend inexploitable).

Notes de conception et de sécurité :

• S'exécute dans un processus enfant afin qu'un nom déjà chargé dans le scanner ne puisse pas court-circuiter le résultat, et que tout effet secondaire de chargement ou crash soit isolé. Aucune élévation requise.
• Chaque sonde est placée, résolue, puis retirée ; tout fichier préexistant est sauvegardé et restauré.
• Il modélise l'ordre moderne LOAD_LIBRARY_SEARCH, donc il n'est appliqué qu'aux candidats Fantôme / Ordre de recherche / Chargement latéral. Les candidats .local, PATH et AppInit/AppCert utilisent des mécanismes différents et sont signalés comme Ignorés.
• Il écrit des fichiers de manière transitoire aux positions candidates (impact moyen) ; désactivez-le pour un triage entièrement passif, en lecture seule.

# Triage utilisateur standard avec ordre de recherche vérifié par le chargeur (pas de canari, pas d'ETW)
.\DLLHijackHunter.exe --lpe-only --no-canary --no-etw --verify-load

Comparaison

Utilisation

Prérequis

• Windows 10/11 ou Windows Server 2016+
• Runtime .NET 8.0 ou 10.0 (ou utilisez une build autonome)
• Privilèges administrateur recommandés (requis pour ETW, le déploiement de canari et certains déclencheurs de services)

Build

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

# Build (fichier unique autonome)
dotnet publish src/DLLHijackHunter/DLLHijackHunter.csproj `
    -c Release -r win-x64 --self-contained `
    -p:PublishSingleFile=true -o ./publish

# Ou utilisez le script de build
.\build.ps1

Démarrage rapide

# Analyse agressive complète (recommandé, nécessite admin)
.\DLLHijackHunter.exe --profile aggressive

# Analyse sûre (aucun dépôt de fichier, aucun déclenchement)
.\DLLHijackHunter.exe --profile safe

# Analyse ciblée sur le contournement UAC
.\DLLHijackHunter.exe --profile uac-bypass

# Cibler un binaire spécifique
.\DLLHijackHunter.exe --target "C:\Program Files\MyApp\app.exe"

# Cibler par nom de fichier (correspondance partielle)
.\DLLHijackHunter.exe --target notepad.exe

# Résultats confirmés uniquement
.\DLLHijackHunter.exe --profile redteam --format json -o report.json

Options CLI

DLLHijackHunter — Détection automatisée de détournement de DLL

Options :
  -p, --profile <profile>        Profil d'analyse [défaut : aggressive]
                                   aggressive | strict | safe | redteam | uac-bypass
  -o, --output <path>            Chemin du fichier de sortie (détection automatique du format)
  -f, --format <format>          Format de sortie [défaut : console]
                                   console | json | html
  -t, --target <target>          Cibler un binaire, un répertoire ou un nom de fichier spécifique
      --min-confidence <value>   Seuil de confiance minimum 0-100. Lorsqu'omis, le seuil de
                                   chaque profil s'applique ; le passer écrase celui-ci.
      --no-canary                Désactiver la confirmation par canari
      --no-etw                   Désactiver la découverte d'exécution ETW
      --verify-load              Vérifier l'ordre de recherche avec le vrai chargeur (voir ci-dessous).
                                   Utilisateur standard ; écrit de manière transitoire une sonde bénigne.
      --confirmed-only           Afficher uniquement les résultats confirmés par canari
      --lpe-only                 Chasse LPE stricte : ignorer System32/Program Files, afficher
                                   uniquement les vulnérabilités inscriptibles par utilisateur standard
      --log-file <path>          Écrire un journal d'analyse de diagnostic dans un fichier
  -v, --verbose                  Sortie verbeuse

Note : --min-confidence n'est traité comme un remplacement que lorsque vous le passez explicitement. Sinon, le seuil du profil sélectionné est utilisé (par ex. safe = 50 %, strict = 80 %).

Profils d'analyse

Notation

Chaque résultat reçoit des signaux de confiance et d'impact qui sont combinés en un niveau de priorisation final.

Les considérations d'impact typiques incluent :

• privilège obtenu
• fiabilité du déclenchement
• furtivité
• persistance au redémarrage

L'exécution confirmée du canari doit être traitée comme le signal de validation le plus fort.

Plafonnement par niveau : les niveaux Élevé et Confirmé sont réservés aux résultats soutenus par un signal de preuve — un canari déclenché, une observation de chargement d'exécution ETW ou une correspondance documentée avec la base de connaissances. Une correspondance d'ordre de recherche purement statique, aussi propre soit-elle, est plafonnée en haut du niveau Moyen et annotée Statique uniquement afin que les heuristiques non vérifiées ne se présentent jamais comme à haute confiance.

Configuration de triage recommandée

Parce que l'inscriptibilité est évaluée relative à l'attaquant, les exécutions élevées et utilisateur standard sont toutes deux significatives :

• Pour le triage LPE, la configuration la plus fiable est une exécution utilisateur standard avec --lpe-only (et --no-canary si un compilateur n'est pas disponible) — chaque résultat survivant est réellement inscriptible par un principal non privilégié.
• Les exécutions élevées sont requises pour ETW et la confirmation par canari, et sont désormais à l'abri de l'inversion historique « tout dans System32 semble inscriptible ».

Sécurité

DLLHijackHunter est conçu pour la recherche en sécurité défensive, la validation en laboratoire, l'audit et la simulation d'équipe rouge dans des environnements autorisés.

Utilisez-le uniquement sur des systèmes et réseaux que vous possédez ou pour lesquels vous êtes explicitement autorisé à évaluer.

Notes opérationnelles

• Le mode canari écrit des DLL de test aux emplacements candidats
• Certains déclencheurs peuvent brièvement démarrer ou arrêter des services/tâches pendant la validation
• Les canaris proxy/transfert d'exports peuvent déstabiliser des cibles fragiles
• Le profil safe est le mode préféré pour le triage en production lorsque les dépôts de fichiers et les déclencheurs ne sont pas acceptables

Sortie

DLLHijackHunter prend en charge :

• les rapports console
• l'export JSON
• l'export HTML

Flux de travail recommandé :

1. exécuter une analyse large
2. examiner les résultats à haute confiance
3. utiliser la confirmation par canari de manière sélective sur les chemins à forte valeur
4. conserver la sortie JSON/HTML pour les rapports et le triage

Licence

MIT

Crédits

Développé par ProjectMerai.