Qu'est-ce que le détournement de DLL et pourquoi votre nouveau plugin IA pourrait être la voie d'entrée la plus facile

J’ai passé beaucoup de temps cette année à observer comment les organisations intègrent AI dans des outils qui n’ont jamais été conçus pour la gérer. La plupart des risques sont discutés en termes d’exposition des données ou de comportement du modèle. Moins d’attention est portée à quelque chose de plus basique : le processus d’installation lui-même. Lorsqu’une équipe ajoute un plugin AI à une application de bureau héritée, elle ajoute souvent un nouvel exécutable, un nouvel ensemble de dépendances et un nouvel ensemble de dossiers que Windows recherchera lorsque cette application tentera de charger une DLL. C’est une configuration familière pour quiconque a suivi le détournement de DLL au fil des ans, et cela devient de plus en plus courant.

Qu'est-ce que le détournement de DLL

Les applications Windows ne chargent pas toujours leurs DLL depuis un emplacement fixe et fiable. Lorsqu'une application demande une DLL par son nom plutôt que par son chemin complet, Windows recherche dans un ordre défini de répertoires pour la trouver. Si un attaquant peut placer une DLL malveillante avec le bon nom de fichier quelque part plus tôt dans cet ordre de recherche, l'application charge le code de l'attaquant au lieu de la bibliothèque légitime, et ce avec les privilèges dont dispose déjà l'application.

Ce n’est pas une nouvelle technique. C’est une faiblesse documentée depuis des années, et elle continue de fonctionner car de nombreuses applications de bureau, en particulier les plus anciennes ou mal conçues, chargent encore les DLL par nom au lieu du chemin complet. Ce qui a changé, c’est la surface d’attaque. Chaque plugin, extension ou module alimenté par l’IA installé dans une application héritée est une nouvelle opportunité pour un dossier peu contrôlé, une dépendance non signée ou un répertoire modifiable dans le chemin de recherche.

Exemple de détournement de DLL

Imaginez une équipe d'ingénierie utilisant une application CAD en place depuis une décennie. L'informatique ajoute un plugin IA qui offre aux utilisateurs une couche intelligente de recherche et de synthèse sur leurs dessins. Comme beaucoup de logiciels dans cette catégorie, l'application CAD charge l'une de ses DLL auxiliaires par nom plutôt que par chemin complet, une décision de conception que personne n'a remise en question car elle n'a jamais causé de problème visible.

Un attaquant ayant même un accès limité à cette machine, via phishing, un compte compromis ou un autre point d’ancrage, n’a pas besoin de casser le plugin AI lui-même. Il lui suffit de déposer un DLL portant le même nom de fichier dans un dossier qui se trouve plus tôt dans l’ordre de recherche de l’application. La prochaine fois qu’un utilisateur lance l’application, elle charge le DLL de l’attaquant à la place, et le code malveillant s’exécute avec les mêmes privilèges que l’application CAD. Aucun exploit contre le plugin AI n’est nécessaire. Le plugin a simplement fourni à l’attaquant un nouveau dossier pour agir.

Comment détecter le détournement de DLL

La détection consiste généralement à surveiller un comportement qui ne correspond pas à ce qu’une DLL légitime devrait faire :

• Applications chargeant des DLL par nom depuis des répertoires inhabituels ou modifiables par l’utilisateur au lieu d’un chemin complet et fiable
• DLL non signées lancées via des utilitaires comme rundll32.exe, un schéma courant de détournement
• Surveillance de l'intégrité des fichiers signalant les modifications des DLL qui ne devraient pas changer entre les cycles de correctifs
• Journaux d’Endpoint montrant un processus parent légitime suivi d’un chargement DLL inattendu ou non signé

Une autre méthode consiste à vérifier l'intégrité de n'importe quelle DLL dans le chemin de recherche (en fait l'intégrité de tous les fichiers) en comparant leurs valeurs de hachage à une source fiable connue.

Rien de tout cela n'est exotique. C'est la même discipline que les équipes de sécurité appliquent déjà à l'intégrité des fichiers et à la surveillance des processus, ciblée spécifiquement sur les dossiers où les plugins tiers et les applications héritées ont tendance à introduire un comportement faible dans l'ordre de chargement.

Comment prévenir le détournement de DLL

La prévention se divise généralement en deux catégories : corriger les applications et contrôler ce qui est autorisé à s’exécuter sur le endpoint.

Corriger l'application signifie utiliser des chemins entièrement qualifiés pour le chargement des DLL, renforcer les permissions des dossiers afin que les utilisateurs standards ne puissent pas écrire dans les répertoires que l'application recherche, et maintenir le logiciel du fournisseur à jour. C'est la bonne solution à long terme, mais elle dépend de chaque fournisseur pour faire le travail, et beaucoup des applications les plus exposées à ce problème sont justement celles qui ont le moins de chances d'être rapidement corrigées.

Contrôler le endpoint signifie ne pas attendre le fournisseur. PolicyPakLa protection DLL Hijack de PolicyPak, partie de Least Privilege Manager, fonctionne en trois modes : audit, qui enregistre les chargements DLL risqués sans les bloquer pour que les équipes puissent d'abord évaluer l'exposition ; safe elevated, qui bloque le chargement DLL risqué pour les processus élevés ; et anti-hijack, qui étend ce blocage aux processus réguliers s'exécutant depuis des emplacements protégés comme Program Files. Elle arrête directement les deux schémas de détournement les plus courants : une application chargeant une DLL par un nom non qualifié au lieu d'un chemin complet, et une DLL non signée lancée via un utilitaire comme rundll32.exe. Lorsqu'une DLL légitime est bloquée par erreur, les administrateurs peuvent l'autoriser par chemin de fichier, signature numérique ou hash de fichier sans désactiver la protection.

Si votre équipe déploie des capacités d'IA dans des applications antérieures à cette conversation, le détournement de DLL mérite une place dans le registre des risques, non pas comme une hypothèse, mais comme une conséquence à court terme de la manière dont ces plugins sont installés.