Windows s’appuie massivement sur des bibliothèques partagées (DLL) pour exécuter du code efficacement. Lorsqu’une application demande une DLL sans spécifier son chemin d’accès absolu, le système d’exploitation Windows initie un processus de recherche prévisible pour localiser le fichier.
Les acteurs de la menace abusent de ce mécanisme. Si un attaquant parvient à placer une DLL malveillante dans un répertoire qui est fouillé avant l’emplacement de la DLL légitime, l’application chargera et exécutera aveuglément la charge utile de l’attaquant au sein de son propre espace mémoire. Parce que le processus parent est souvent un binaire Microsoft légitime et signé (ex: svchost.exe, calc.exe, teams.exe), les plateformes de protection des terminaux (EPP/Antivirus) échouent fréquemment à bloquer l’exécution.
Pour comprendre l’attaque, les analystes doivent comprendre la défense. Par défaut, les systèmes Windows modernes emploient le SafeDllSearchMode. Lorsqu’un programme appelle LoadLibrary() ou LoadLibraryEx() sans chemin absolu, Windows recherche la DLL dans l’ordre exact suivant :
C:\Windows\System32\.C:\Windows\System\.C:\Windows\.PATH du système et de l’utilisateur.Le “DLL Hijacking” (détournement de DLL) est un terme générique. Les intervenants sur incident doivent différencier les variations opérationnelles spécifiques utilisées par les adversaires.
1. Détournement de l'ordre de recherche
L’attaque classique (Search Order Hijacking). L’attaquant place une DLL malveillante (portant le même nom qu’une DLL légitime) plus haut dans l’ordre de recherche. Par exemple, déposer une fausse version.dll dans le répertoire racine de l’application. Au lancement, l’application trouve la fausse DLL à l’Étape 1 et arrête sa recherche, ignorant la vraie DLL dans System32.
2. Sideloading de DLL
Contrairement au détournement classique, où l’attaquant cible une application existante sur la machine de la victime, le Sideloading implique que l’attaquant apporte à la fois l’exécutable signé vulnérable et la DLL malveillante sur le système. Il les dépose dans le même dossier (ex: C:\Users\Public\) et exécute le binaire signé pour servir de proxy à la charge utile.
3. DLL Fantômes (Phantom DLLs)
De nombreuses applications Windows anciennes tentent de charger des DLL obsolètes qui n’existent plus dans les versions modernes de Windows (ex: fxsst.dll). La vraie DLL étant totalement absente, l’OS fouillera l’intégralité du PATH. Les attaquants peuvent déposer leur charge utile dans n’importe quel répertoire inscriptible listé dans le PATH pour obtenir l’exécution.
Les adversaires, des affiliés de ransomwares aux groupes APT sophistiqués, utilisent des outils comme Process Monitor (ProcMon) de Sysinternals lors de la phase de reconnaissance pour identifier les résultats NAME NOT FOUND lorsque les applications tentent de charger des bibliothèques.
Une fois une application vulnérable identifiée, l’attaquant compile une DLL malveillante. Cette DLL exporte souvent exactement les mêmes noms de fonctions que la bibliothèque légitime (technique de “DLL Proxying” ou “Forwarding”) pour garantir que l’application hôte ne plante pas, gardant la compromission totalement silencieuse. La charge utile est généralement exécutée à l’intérieur de la fonction DllMain, se déclenchant immédiatement lors du chargement.
Détecter rétrospectivement un détournement de DLL est complexe car l’exécution malveillante se produit dans l’espace mémoire d’un processus légitime. L’Événement 4688 (Création de processus) est à lui seul insuffisant, car il ne consigne que le lancement de l’exécutable parent inoffensif.
Les analystes DFIR doivent pivoter vers la télémétrie de chargement d’image (Image Load).
L’Événement 7 de Sysmon est l’artefact ultime pour détecter cette TTP. Il consigne chaque DLL chargée par chaque processus.
C:\Windows\System32\) qui chargent des DLL non signées, en particulier si ces DLL sont chargées depuis des répertoires inscriptibles par l’utilisateur (ex: C:\Users\*\AppData\Local\, C:\ProgramData\, ou C:\Temp\)..dll dans des répertoires où ils ne devraient pas se trouver (ex: une .dll posée à côté d’un exécutable autonome dans le dossier Téléchargements).// Détecte les binaires Microsoft signés chargeant des DLL non signées depuis des chemins suspectsDeviceImageLoadEvents// Se concentrer sur les DLL chargées depuis des répertoires utilisateurs très abusés| where FolderPath has_any ("\\AppData\\Local", "\\AppData\\Roaming", "\\ProgramData", "\\Users\\Public")// S'assurer que la DLL elle-même n'est pas signée| where isempty(SignatureInfo) or SignatureState != "Valid"// Le processus parent est un binaire Windows légitime| where InitiatingProcessFolderPath startswith "c:\\windows\\system32" or InitiatingProcessFolderPath startswith "c:\\windows\\syswow64"| project TimeGenerated, DeviceName, InitiatingProcessFileName, FolderPath, FileName, SHA256| sort by TimeGenerated desctitle: Détournement potentiel de DLL Fantôme (Sysmon Event 7)id: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6dstatus: experimentaldescription: Détecte le chargement de DLL Windows manquantes/fantômes connues (comme fxsst.dll, wlbsctrl.dll) en dehors du répertoire System32.logsource: category: image_load product: windowsdetection: selection: ImageLoaded|endswith: - '\fxsst.dll' - '\wlbsctrl.dll' - '\ntshrui.dll' - '\profapi.dll' filter_legit: ImageLoaded|startswith: 'C:\Windows\System32\' condition: selection and not filter_legitlevel: hightags: - attack.defense_evasion - attack.t1574.001C:\Program Files\App\lib.dll) plutôt que de chemins relatifs lors de l’appel à LoadLibrary().CWDIllegalInDllSearch pour supprimer globalement ou pour des applications spécifiques le répertoire de travail actuel (CWD) de l’ordre de recherche des DLL.