L'EDR montre un exécutable d'éditeur correctement signé, dans le dossier temporaire d'un utilisateur, qui charge une DLL non signée placée à côté. Comment l'analysez-vous ?
Réponse courte
Traitez-le comme un probable DLL side-loading. La signature couvre l'exécutable, pas la DLL que Windows résout depuis le dossier de l'application ; un binaire de confiance peut donc exécuter du code d'attaquant. Analysez la DLL elle-même (hash, exports, imports, comportement), vérifiez que le processus réside normalement ailleurs, cherchez d'autres copies de la paire et ne clôturez pas l'alerte sur la réputation de l'EXE.
Le piège de ce scénario est le mot « signé ». Une signature valide sur un exécutable ne prouve quelque chose que sur ce fichier.
Pourquoi le side-loading est l'explication probable
MITRE ATT&CK décrit le DLL side-loading comme le dépôt d'une charge malveillante à côté d'une application légitime, puis le lancement de cette application pour qu'elle exécute le code de l'attaquant. Microsoft documente pourquoi cela marche : quand une application non empaquetée charge une DLL sans chemin complet, le chargeur consulte (après la redirection, les API sets, la redirection par manifeste SxS, la liste des modules chargés et les known DLLs) le dossier d'où l'application a été chargée avant le dossier système. Microsoft avertit aussi que si un attaquant contrôle l'un des répertoires parcourus, il peut y placer une copie malveillante de la DLL. Une copie d'un EXE d'éditeur signé déposée dans un dossier inscriptible par l'utilisateur avec une DLL à côté correspond exactement.
Étapes de tri
- Isoler et préserver la paire et noter le chemin complet ; un outil d'éditeur réside normalement dans un emplacement d'installation de confiance.
- Analyser la DLL : hash, signature (ou son absence), date de compilation, exports comparés à la vraie bibliothèque, imports, chaînes, et ce qu'elle lance ou contacte dans un bac à sable.
- Vérifier l'arbre de processus et la chronologie : comment les deux fichiers sont-ils arrivés (archive, e-mail, téléchargement) ?
- Chasser le même hash, la même paire de noms ou le même motif de chemin sur le parc.
Mesures à citer
MITRE cite le contrôle d'applications bloquant les chargements de DLL suspects, le durcissement par hash dans les manifestes, et le maintien du mode de recherche DLL sûr.
Pourquoi les distracteurs échouent
- « Hérite de la confiance » et « réputation de l'EXE » jugent tous deux le mauvais fichier.
- « Supprimer et relancer » détruit des preuves et laisse le vecteur de livraison et les autres copies inexaminés.
Ce que veulent les recruteurs
Reconnaître que signé ne veut pas dire sûr en contexte, avec une démarche rigoureuse : analyse de la DLL, chemin et provenance, chasse sur le parc.
Questions de suivi probables
- Quels répertoires Windows consulte-t-il avant le dossier système, et que sont les KnownDLLs ?
- Comment confirmer que les exports de la DLL imitent la bibliothèque légitime tout en ajoutant du code malveillant ?
- Quelles détections écririez-vous pour un binaire signé exécuté depuis un chemin inscriptible par l'utilisateur ?