Applications, sites et API

Particuliers et entreprises

Détournement du chargement de bibliothèques

DLL hijacking / DLL search order hijacking / DLL sideloading

Un programme charge une bibliothèque non prévue et lui donne accès à son contexte d’exécution.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 4 min
Je pense être concerné : que faire ?
Illustration pédagogique : détournement du chargement de bibliothèques.

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

Une situation concrète

Une application attend une bibliothèque qui lui apporte certaines fonctions. Au démarrage, elle la recherche dans plusieurs emplacements. Un fichier placé dans un dossier modifiable est trouvé avant la bibliothèque prévue. Le programme peut alors charger du code fourni par un tiers.

Comment cela fonctionne

Une bibliothèque contient du code utilisé par un autre programme. Sous Windows, les fichiers DLL en sont une forme courante. Si leur sélection dépend d’un emplacement insuffisamment protégé, un attaquant peut faire choisir une autre bibliothèque. Le programme légitime peut alors exécuter ce code avec ses propres droits. Un chargement inattendu doit être vérifié avant de conclure à une attaque.

Comment le piège fonctionne
  1. Le programme demande une bibliothèque

    Il doit retrouver les fonctions attendues.

  2. Un autre fichier est sélectionné

    Le chemin de recherche passe par une zone modifiable.

  3. Le programme charge ce module

    Son code peut agir avec les droits du processus.

Ce que vous pouvez faire

Vos premiers réflexes

N’installez pas une DLL proposée par un site pour réparer un message d’erreur. Utilisez la réparation ou la mise à jour du fournisseur, et signalez un comportement inhabituel sans relancer le programme.

Si vous êtes responsable du service ou de l’organisation

Faites vérifier les chemins de chargement et les droits des dossiers d’installation. Comparez les modules réellement chargés à ceux de la distribution approuvée, y compris les dépendances.

Un point à vérifierUne idée reçue à corriger

La signature valide du programme principal ne garantit pas que toutes les bibliothèques qu’il charge sont celles prévues par son fournisseur.

À vous de décider

Le programme principal est signé par un éditeur connu. Cela garantit-il la provenance de toutes les DLL qu’il charge ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Non. La signature porte sur le programme concerné. Il faut aussi vérifier les bibliothèques choisies, leurs chemins et leur provenance. Un programme authentique peut charger un module qui n’était pas prévu.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

Un programme authentique charge le module du dossier de travail

Le programme viewer-lab.exe est authentique dans le laboratoire, mais il charge helper-lab.dll depuis un dossier modifiable. L’événement de chargement relie ce module au processus proc-L. Le marqueur factice montre ensuite que le module de test participe à l’exécution.

La signature valide du programme principal ne valide pas ce module à sa place. L’analyse compare le chemin et l’empreinte à la distribution approuvée, puis vérifie qui pouvait écrire dans le dossier. L’exercice n’implique aucune compromission de production : les noms et les empreintes textuelles servent uniquement de repères fictifs.

Après correction, le programme charge le module approuvé depuis l’installation protégée. Il faut contrôler les dépendances de ce module et les autres modes de lancement. Le cas AnyConnect cité concerne un composant et des privilèges particuliers ; ce scénario ne permet pas de conclure que tout chargement détourné donne des droits administrateur.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape
ApplicationProgramme authentique
ChargeurSélection de bibliothèque
Dossier modifiableModule non approuvé
Installation protégéeModule attendu
  1. Action

    Demande de bibliothèque

    Application vers Chargeur

    Trace helper-lab.dll

  2. Action

    Recherche dans le dossier de travail

    Chargeur vers Dossier modifiable

    Trace emplacement modifiable

  3. Réponse

    Module non approuvé trouvé

    Dossier modifiable vers Chargeur

    Trace test-module-B

  4. Réponse

    Chargement dans proc-L

    Chargeur vers Application

    Trace event=image_loaded

  5. Action sur place

    Observation du marqueur factice

    Application

    Trace test isolé

  6. Action

    Nouvelle sélection après correction

    Application vers Chargeur

    Trace recherche restreinte

  7. Action

    Chargement du module approuvé

    Chargeur vers Installation protégée

    Trace approved-module-A

Comment repérer cette attaque

Indices à rechercher

  • Un processus charge une bibliothèque depuis un dossier inhabituel ou modifiable.
  • La provenance ou l’empreinte de la bibliothèque diffère de la version attendue.
  • Une action inattendue suit le chargement dans le contexte de ce processus.

Relier les événements de création et de chargement de la bibliothèque au bon processus. Comparer son chemin, sa provenance et son empreinte à la version attendue, puis rechercher les effets du module dans ce contexte d’exécution.

Quelles informations comparer

Suivre proc-L depuis le lancement de viewer-lab.exe jusqu’au chargement de helper-lab.dll et au marqueur de test. Comparer l’emplacement consulté et les permissions avant le chargement, puis les modules de la version approuvée.

Ce que ces indices ne permettent pas de conclure

Une création de DLL ne prouve pas son chargement ; la signature du programme principal ne suffit pas à authentifier le module. Ce cas de laboratoire ne démontre aucune compromission de production ni élévation de privilèges.

Comment réagir

Préserver le programme et le module avant nettoyage, puis isoler le poste selon les effets observés. Corriger la sélection des dépendances et les permissions des dossiers ; réinstaller depuis une source approuvée et examiner les ressources accessibles au processus.

Vérifier la correction

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

  1. Le module sélectionné correspond à la distribution approuvée dans chaque mode de lancement.
  2. Un utilisateur non autorisé ne peut pas modifier un emplacement consulté pour ce chargement.
  3. Les dépendances indirectes et les fonctions normales sont contrôlées après correction.

À vous de raisonner

Une DLL est créée dans un dossier modifiable, mais aucun événement de chargement ne la relie au programme. Peut-on déjà affirmer que ce programme a exécuté son code ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Non. La présence du fichier est établie ; sa sélection et son chargement restent à démontrer. Il faut relier le module au processus et vérifier les effets observés, en tenant compte des limites de la collecte.

Consulter les détails techniques

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.

process_guid
Identifiant fictif du processus utilisé pour relier les observations ; il joue ici le rôle d’une clé de corrélation.
synthetic_module_marker_observed
Observation d’un marqueur factice du module de test, distincte d’une preuve d’action hostile dans un environnement réel.

Reconstitution pédagogique du cas en laboratoire

JSONL

Valeurs et événements fictifs réunis pour expliquer le cas. Ce format est une reconstitution, pas un export natif du logiciel ou du système cité.

{"case":"module-6","environment":"isolated_test","process_guid":"proc-L","image":"viewer-lab.exe","main_signature":"valid"}
{"case":"module-6","process_guid":"proc-L","module_path":"C:\\Lab\\Writable\\helper-lab.dll","module_hash":"test-module-B","event":"image_loaded"}
{"case":"module-6","process_guid":"proc-L","synthetic_module_marker_observed":true,"production_compromise":"not_established"}
{"case":"module-7","build":"fixed","module_hash":"approved-module-A","search_scope":"protected_installation"}
Préparer une collecte dans votre environnement

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.

  1. Windows — Microsoft Sysmon

    Où les trouver
    Observateur d’événements → Journaux des applications et des services → Microsoft → Windows → Sysmon → Operational, ou leur copie dans le collecteur central.
    Quoi relever
    Si les événements Image loaded étaient activés, conserver le module, son chemin et le ProcessGuid. La configuration peut exclure ces événements ; leur absence ne garantit donc pas l’absence de chargement.
    Accès et prérequis
    Sysmon doit avoir été installé et configuré avant les faits. L’événement réseau 3 est désactivé par défaut ; les filtres peuvent exclure des événements. L’événement 11 décrit une création de fichier, pas sa lecture.
    Documentation : Windows — Microsoft Sysmon

  2. Fichiers préservés — comparaison et empreintes complètes

    Où les trouver
    Sur des copies de travail des fichiers conservés, dans l’environnement d’analyse autorisé. Calculer les empreintes complètes avec un outil fiable, puis comparer les octets si une égalité mérite vérification.
    Quoi relever
    Préserver le programme et la bibliothèque, comparer leurs empreintes complètes à la distribution approuvée et conserver la provenance. Les libellés test-module-B et approved-module-A du cas ne sont pas des empreintes cryptographiques.
    Accès et prérequis
    Accès aux originaux ou à des copies dont la provenance est documentée. Préciser l’algorithme, la longueur et toute transformation ; un recalcul actuel ne prouve pas quel fichier le service a traité auparavant.
    Documentation : Fichiers préservés — comparaison et empreintes complètes

Si vous pensez être concerné

Si vous utilisez le service

N’installez pas une DLL proposée par un site pour réparer un message d’erreur. Utilisez la réparation ou la mise à jour du fournisseur, et signalez un comportement inhabituel sans relancer le programme.

Pour l’équipe qui exploite le service

  1. Signalez le logiciel et l’heure sans relancer le programme pour vérifier.
  2. Faites préserver le programme, la bibliothèque chargée et leurs informations de provenance.
  3. Isolez le poste si nécessaire, corrigez le chargement et examinez les actions du processus.

Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

Sur des sujets proches

Compromission de la chaîne d’approvisionnement ↗Intrusion dans un système informatique ↗Exploitation de vulnérabilités ↗Toutes les fiches ECRAN →