DLL sideloading et detournement : fonctionnement et detection

Le DLL sideloading et le detournement de l'ordre de recherche des DLL comptent parmi les techniques les plus durables d'une intrusion moderne. Ils sont discrets, ils s'appuient sur la reputation des logiciels signes et survivent regulierement aux controles qui ne visent que les binaires manifestement malveillants. Cet article s'adresse aux defenseurs, aux intervenants en incident et aux ingenieurs de plateforme qui doivent comprendre la technique afin de la detecter et de la neutraliser. Nous restons deliberement a un niveau conceptuel : pas de payloads prets a l'emploi ni d'instructions pas a pas pour compromettre des systemes tiers. L'objectif est de batir un modele mental precis de la maniere dont l'abus de confiance se produit sous Windows, puis de traduire ce modele en logs, telemetrie et durcissement deployables des cette semaine.

Ce que sont vraiment le sideloading et le detournement de DLL

Les applications Windows sont rarement livrees sous forme d'un unique executable monolithique. Elles chargent des fonctionnalites a la demande depuis des bibliotheques de liens dynamiques (DLL). Lorsqu'un programme demande au systeme de charger une bibliotheque par son nom, Windows resout ce nom via un ordre de recherche defini : une sequence de repertoires verifies l'un apres l'autre jusqu'a trouver un fichier correspondant. Le detournement de l'ordre de recherche des DLL exploite le fait qu'un attaquant capable de placer un fichier plus tot dans cette sequence obtient le chargement de sa bibliotheque a la place de celle prevue. Le DLL sideloading est une variante tres proche : un executable legitime, souvent signe, est place a cote d'une DLL malveillante qui porte le nom attendu par l'application, de sorte que le processus de confiance charge du code non fiable. Dans les deux cas, le code malveillant herite de l'identite, de la reputation de signature et souvent des privileges du processus hote.

Si ces techniques comptent pour les defenseurs, c'est a cause de l'heritage de confiance. Un binaire signe par un editeur connu franchit sans peine les allowlists naives et les verifications de reputation. Lorsque ce binaire charge une DLL controlee par l'attaquant, la logique malveillante s'execute desormais a l'interieur d'un processus de confiance. Les outils de terminal qui s'appuient sur la reputation du processus, et les analystes qui parcourent un arbre de processus et voient un nom familier, peuvent tous deux etre trompes. C'est precisement pourquoi la technique a une telle longevite, tant dans la criminalite de masse que dans les intrusions ciblees.

Comment cela fonctionne a haut niveau

Conceptuellement, l'abus comporte trois pieces mobiles. D'abord, un chargeur vulnerable : une application qui demande une bibliotheque par un nom ambigu plutot que par un chemin pleinement qualifie et verifie. Ensuite, un emplacement inscriptible plus tot dans l'ordre de recherche que la bibliotheque legitime, souvent le repertoire de travail de l'application. Enfin, une bibliotheque malveillante qui exporte les symboles attendus par l'application, afin que le chargement reussisse et que l'application continue de fonctionner normalement. Quand ces trois elements s'alignent, le processus de confiance charge et execute le code de l'attaquant sans exploiter aucune corruption memoire ; c'est un pur abus du comportement de chargement prevu.

Les variantes sophistiquees ajoutent une couche de proxy pour que l'application ne plante pas et ne se comporte pas anormalement. La DLL malveillante relaie ou reimplemente les fonctions exportees attendues, transmettant les appels legitimes a la vraie bibliotheque tout en executant sa propre logique en parallele. Ce proxy de fonctions preserve l'experience utilisateur, ce qui retarde la decouverte. Du point de vue de la detection, l'idee cruciale est que le module malveillant est charge depuis un chemin inattendu, et cette anomalie de chemin, et non le contenu de la DLL, est souvent le signal le plus fiable.

Le vecteur et la surface d'attaque

La surface d'attaque est la plus large partout ou des repertoires inscriptibles croisent des executables de confiance. Les zones de risque classiques incluent les dossiers d'application par utilisateur, les repertoires temporaires, les dossiers de telechargement d'ou les utilisateurs lancent des installeurs, et tout repertoire d'application ou les utilisateurs standard disposent d'un droit d'ecriture du fait d'ACL laxistes. Les applications portables et les installeurs auto-extractibles sont des hotes frequents car, par conception, ils s'executent depuis des emplacements inscriptibles par l'utilisateur. Un logiciel tiers qui livre de nombreuses DLL auxiliaires agrandit la surface simplement en augmentant le nombre de noms qu'un attaquant pourrait satisfaire.

La persistance est un objectif courant. Comme la DLL malveillante se charge chaque fois que l'application de confiance s'execute, un attaquant qui l'implante dans un programme frequemment lance obtient une execution repetable qui parait routiniere. Voila pourquoi la technique apparait aussi bien dans les chaines d'acces initial que dans les points d'ancrage a long terme. Comprendre la surface permet de prioriser : inventoriez les executables signes de votre parc qui resolvent des bibliotheques depuis des chemins inscriptibles, et vous obtenez une liste classee des chargeurs les plus dignes de surveillance.

Detection : logs, Event IDs et telemetrie

La detection commence par la telemetrie de chargement d'image/module. Sous Windows, Sysmon Event ID 7 (Image Loaded) est la piece maitresse : il enregistre quel processus a charge quel module, depuis quel chemin, ainsi que le statut de signature du module. La regle la plus precieuse est une regle d'anomalie de chemin : un executable signe connu chargeant une DLL au nom connu depuis un repertoire non standard (un profil utilisateur, un dossier temporaire, un chemin de telechargement) plutot que depuis System32 ou le repertoire d'installation de l'editeur. Correlez sur le tuple processus parent, nom de DLL attendu et chemin de chargement reel.

Enrichissez avec des signaux de signature et de provenance. Un processus de confiance chargeant un module non signe ou a signature invalide, ou un module signe par un certificat inattendu, merite un examen. Sysmon Event ID 1 (Process Create) fournit la ligne de commande et le repertoire de travail qui preparent le chargement ; Event ID 11 (File Create) peut saisir la DLL ecrite dans le repertoire du chargeur quelques instants avant l'execution. Les plateformes EDR exposent des evenements equivalents de chargement de module et d'ecriture de fichier, souvent avec une analytique integree des anomalies de chemin de chargement. L'evenement de securite Windows 4688 (avec l'audit de ligne de commande active) et la journalisation des blocs de script PowerShell (4104) aident a reconstruire comment le repertoire de staging a ete peuple.

Des hypotheses de chasse rentables : des binaires signes chargeant des DLL depuis %APPDATA%, %TEMP% ou %USERPROFILE%\Downloads ; le meme nom de DLL present a plusieurs emplacements sur des hotes differents ; un executable legitime copie hors de son repertoire d'installation vers un chemin inscriptible par l'utilisateur ; et des processus chargeant des modules dont l'horodatage de creation n'est que de quelques secondes plus ancien que le processus lui-meme. Etablissez d'abord une reference de ce a quoi ressemblent les chargements de module normaux de vos applications critiques : l'anomalie n'est visible que face a une reference connue comme saine. Associez cela a des balayages de persistance de type autoruns pour saisir les DLL implantees referencees par des taches planifiees ou des elements de demarrage.

Attenuation et durcissement

Le controle le plus durable consiste a supprimer la condition repertoire inscriptible plus binaire de confiance. Imposez des ACL strictes afin que les utilisateurs standard ne puissent ecrire dans aucun repertoire d'ou s'executent des executables de confiance, et ne laissez jamais les repertoires de travail d'application inscriptibles par tous. Pour votre propre logiciel, chargez toujours les bibliotheques via des chemins pleinement qualifies, appelez SetDefaultDllDirectories avec une politique de recherche restrictive et privilegiez LoadLibraryEx avec LOAD_LIBRARY_SEARCH_SYSTEM32 ou des indicateurs de recherche securisee explicites. Ces controles cote developpeur font s'effondrer l'ambiguite dont depend la technique.

Au niveau plateforme, deployez le controle applicatif. Windows Defender Application Control (WDAC) et AppLocker peuvent imposer que seuls des modules approuves et signes se chargent, et les politiques WDAC modernes peuvent valider les DLL, pas seulement les executables, comblant la faille du sideloading. Activez le mode de recherche securisee des DLL (actif par defaut sur les systemes pris en charge, mais verifiez via la valeur de registre SafeDllSearchMode) et envisagez des politiques d'attenuation de processus qui bloquent le chargement de DLL non signees par Microsoft ou distantes pour les processus sensibles. Maintenez les logiciels tiers a jour, car les editeurs corrigent de plus en plus les schemas de chargement vulnerables livres avec leurs applications.

Reduisez le rayon d'impact par le moindre privilege et la segmentation : les applications qui s'executent en tant qu'utilisateurs standard limitent ce que le code sideloaded peut atteindre, et la segmentation reseau restreint le mouvement lateral si un point d'ancrage est etabli. Enfin, traitez votre chaine d'approvisionnement logicielle comme une partie de la surface : verifiez l'integrite des installeurs, privilegiez les editeurs qui livrent dans des repertoires proteges et surveillez le schema classique d'une application portable legitime deposee dans un dossier inscriptible par l'utilisateur a cote d'une DLL inattendue.

Pieges courants pour les defenseurs

L'erreur la plus courante est de se fier au nom du processus. Comme le processus qui charge est legitime et signe, les alertes supprimees selon la reputation du signataire manqueront silencieusement le sideloading. Construisez des regles qui inspectent le module charge et son chemin, pas seulement le processus hote. Un deuxieme piege est la fatigue d'alerte due a des regles de chemin bruyantes : beaucoup d'applications legitimes chargent des DLL depuis des repertoires utilisateur, donc l'ajustement face a une reference par application est essentiel avant d'activer le blocage. Un troisieme est de supposer que l'EDR couvre cela par defaut : la detection d'anomalie de chemin de chargement de module doit souvent etre activee ou redigee explicitement.

Les equipes sous-estiment aussi les sosies legitimes. Certains editeurs livrent reellement des DLL vers %APPDATA%, et certains outils de developpement chargent des bibliotheques depuis des repertoires de compilation. Documentez ces exceptions de maniere deliberee plutot que d'elargir la regle jusqu'a l'aveuglement. Enfin, n'oubliez pas les chronologies forensiques : lorsque vous trouvez un module suspect, pivotez sur l'heure de creation du fichier, le processus qui l'a ecrit et tout evenement precedent d'extraction d'archive ou de telechargement pour reconstruire l'arrivee de la DLL.

Une checklist pratique pour les defenseurs

Utilisez ceci comme checklist de travail. 1) Inventoriez les executables signes de votre parc qui resolvent des bibliotheques depuis des chemins inscriptibles. 2) Deployez Sysmon (ou un EDR equivalent) avec la journalisation de chargement de module Event ID 7 et une regle d'anomalie de chemin pour les chargeurs signes lisant des DLL depuis des repertoires inscriptibles par l'utilisateur. 3) Activez l'audit de ligne de commande (4688) et la journalisation des blocs de script PowerShell (4104). 4) Verrouillez les ACL sur les repertoires d'application et de travail. 5) Deployez WDAC ou AppLocker avec des regles de DLL d'abord en mode audit, puis en imposition. 6) Verifiez SafeDllSearchMode et appliquez des politiques d'attenuation de processus aux applications sensibles. 7) Etablissez une reference des chargements de module normaux pour les applications critiques avant d'alerter. 8) Repetez un playbook de reponse a incident qui pivote d'un module suspect vers ses evenements de creation de fichier et de staging.

Foire aux questions

Le DLL sideloading est-il une vulnerabilite a corriger ou une technique ? C'est avant tout une technique qui abuse du comportement de chargement legitime, meme si des applications precises peuvent presenter des bugs de chargement vulnerable corrigibles. La defense est donc a la fois de la configuration (ACL, controle applicatif, politique de recherche) et le correctif des contrevenants individuels a mesure que les editeurs les traitent. Traitez cela comme un controle continu, pas comme un correctif unique.

L'antivirus seul l'arrete-t-il ? Pas de maniere fiable. Comme le code malveillant s'execute dans un processus de confiance et signe, les outils bases sur la signature et la reputation le manquent souvent. Un EDR comportemental avec analytique de chemin de chargement de module, combine au controle applicatif et au durcissement des repertoires, est bien plus efficace que n'importe quel scanner unique.

Conclusion

Le DLL sideloading et le detournement de l'ordre de recherche perdurent parce qu'ils transforment la confiance en arme : un processus signe et familier devient le vehicule du code de l'attaquant. L'avantage du defenseur est que l'abus laisse une empreinte coherente : un binaire de confiance chargeant un module inattendu depuis un chemin inattendu et inscriptible. Instrumentez les chargements de module, etablissez une reference du normal, imposez le controle applicatif jusqu'au niveau des DLL et supprimez la condition repertoire inscriptible plus binaire de confiance partout ou vous le pouvez. Faites cela, et une technique batie sur la confiance heritee devient l'un des comportements les plus fiablement detectables de votre environnement.