Réseaux et infrastructures
Entreprises et organisationsRéutilisation d’empreintes d’authentification
Pass-the-hash
Une empreinte de mot de passe volée permet de se connecter à certains services Windows sans connaître le mot de passe.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Après la compromission d’un poste, un attaquant récupère une empreinte utilisée pour l’authentification. Sur certains services Windows, il peut s’en servir pour se présenter sous une autre identité sans retrouver le mot de passe d’origine.
Comment cela fonctionne
Le pass-the-hash réutilise une empreinte d’authentification volée. Une empreinte n’est pas un mot de passe lisible, mais elle peut rester suffisamment puissante pour permettre un accès. L’attaque concerne surtout les environnements qui acceptent certains mécanismes d’authentification Windows. Elle illustre pourquoi protéger les données de connexion en mémoire et éviter les droits trop étendus est essentiel.
- Une empreinte de connexion est volée
Elle constitue encore un secret utile.
- Elle est réutilisée sur un service
Le mot de passe lisible n’est pas nécessaire.
- Le compte donne accès à d’autres systèmes
Selon ses droits et le protocole.
Ce que vous pouvez faire
Vos premiers réflexes
Sur un poste de travail, signalez une alerte de vol d’identifiants et évitez d’y ouvrir une session d’administration. La recherche sur le réseau relève de l’équipe informatique.
Si vous êtes responsable du service ou de l’organisation
Utilisez des mots de passe administrateurs locaux différents par machine et séparez les postes d’administration. Après un vol d’empreinte, recherchez ses usages sur les autres systèmes.
Ne pas connaître le mot de passe en clair n’empêche pas toujours de s’authentifier.
À vous de décider
L’attaquant n’a qu’une empreinte du mot de passe Windows, pas le mot de passe lisible. Peut-il parfois se connecter ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Oui. Certains mécanismes Windows permettent de réutiliser cette empreinte comme secret d’authentification. Il n’a pas besoin de retrouver le mot de passe en clair.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Une authentification NTLM ouvre un partage puis un accès distant
Le serveur de fichiers accepte une connexion NTLM de type réseau, puis journalise l’accès à ADMIN$. Une activité distante suit. Cet enchaînement peut correspondre à l’utilisation d’une empreinte NTLM volée, mais les journaux d’authentification ne distinguent pas toujours cette utilisation d’une connexion réalisée avec le mot de passe.
Dans une attaque pass-the-hash, l’empreinte permet de répondre au mécanisme d’authentification sans retrouver le mot de passe en clair. L’analyse doit donc chercher comment cette empreinte aurait été obtenue et où le compte a été réutilisé. Un accès suspect à LSASS sur le poste source renforce l’hypothèse, sans suffire à identifier exactement les secrets récupérés.
Relier les événements au moyen du compte, de l’identifiant de session de connexion et du poste source. Un événement 4624, un accès de partage 5140 et un processus distant ne se rapprochent pas uniquement parce qu’ils sont proches dans le temps. Les outils d’administration légitimes produisent aussi cette suite. Vérifier les droits du compte, les interventions prévues et l’usage de secrets administratifs communs à plusieurs machines.
Le déroulement en schéma
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.
- Action sur place
Lecture de secrets suspectée
Poste source
Trace télémétrie EDR
- Action
Authentification NTLM
Poste source vers Serveur FS01
Trace source 10.20.1.24
- Action
Validation du compte
Serveur FS01 vers Contrôleur de domaine
Trace journal DC
- Réponse
Authentification acceptée
Contrôleur de domaine vers Serveur FS01
Trace résultat
- Action sur place
Session type 3 puis partage
Serveur FS01
Trace 4624 et 5140
- Action
Envoi des événements
Serveur FS01 vers Collecteur
Trace hôte et LogonId
- Action
Contexte du processus source
Poste source vers Collecteur
Trace GUID et signature
Comment repérer cette attaque
Indices à rechercher
- Un compte se connecte à de nombreuses machines depuis un poste inhabituel.
- Des authentifications réseau suivent une alerte de vol d’identifiants.
- Un compte administrateur local est utilisé sur plusieurs équipements.
Rechercher les authentifications NTLM inhabituelles vers plusieurs hôtes, les accès aux partages administratifs et les exécutions distantes associées.
Éléments à croiser
Relier la session de la cible aux accès aux partages et aux actions sur cette même machine, puis examiner les indices de vol d’identifiants à la source. Les identifiants de connexion sont locaux à la machine.
Limites de l’interprétation
Un 4624 NTLM de type 3 est courant et ne distingue pas un mot de passe légitime d’une empreinte réutilisée. L’accès à LSASS peut aussi venir d’un logiciel autorisé : vérifier le processus et ses droits.
Comment réagir
Isoler la source compromise, fermer les accès distants exposés et renouveler les secrets réellement concernés depuis un poste d’administration fiable. Pour les comptes locaux, privilégier des secrets uniques et gérés. Réduire progressivement NTLM après inventaire et tests de compatibilité, sans couper aveuglément une dépendance métier.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Vérifier qu’une connexion NTLM légitime est classée comme telle avec son contexte.
- Confirmer la corrélation LogonId sur un même hôte et éviter les jointures intermachines sur ce seul champ.
- Tester que l’ancien secret ne fonctionne plus sur les machines concernées après rotation.
À vous de raisonner
Une connexion NTLM est suivie d’un accès administratif distant. Peut-on affirmer, avec ces seuls événements, que le mot de passe n’était pas connu de l’auteur ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Non : ces événements peuvent aussi venir d’une authentification avec le mot de passe ou d’une intervention légitime. Examinez le poste source, une éventuelle collecte de secrets et le contexte d’administration. Reliez les sessions dans le périmètre où leurs identifiants sont valables.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
TargetLogonId- Identifiant de la nouvelle session sur la cible ; à rapprocher du SubjectLogonId d’autres événements de cette cible, pas de ceux d’un autre serveur.
5140- Événement d’accès à un partage dans la sélection fictive : il ne décrit pas à lui seul tous les fichiers lus.
Connexion cible et activité distante
JournalExtraits synthétiques. Le LogonId n’est corrélable que sur le même hôte et dans son contexte de démarrage.
host=FS01 EventID=4624 TargetUserName=svc_ops
LogonType=3 AuthenticationPackageName=NTLM
TargetLogonId=0x91a IpAddress=10.20.1.24
host=FS01 EventID=5140 SubjectLogonId=0x91a ShareName=\\*\ADMIN$
host=FS01 process=remote_task.exe account=svc_ops parent=services.exe
host=WS24 edr_event=credential_access target=lsass.exe result=observedPréparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
Windows — journal Sécurité de la machine cible
- Où les trouver
- Observateur d’événements → Journaux Windows → Sécurité. Chercher les connexions réussies 4624 sur la machine qui reçoit l’accès, pas seulement sur le poste de départ.
- Quoi relever
- Sur le serveur cible, lire le 4624 : LogonType 3 indique un accès réseau ; AuthenticationPackageName NTLM précise le mécanisme. Relever TargetUserName, TargetLogonId et IpAddress quand ils sont présents.
- Accès et prérequis
- Accès délégué aux événements et stratégie d’audit des ouvertures de session active. Une adresse IP ou un champ peuvent être absents selon le protocole utilisé.
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
- Sur le poste d’origine, rechercher les processus et, si configurés, les accès à d’autres processus (événement 10), notamment LSASS. Sur la cible, rechercher l’exécution distante et son parent.
- 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.
Si vous pensez être concerné
Si vous utilisez le service
Sur un poste de travail, signalez une alerte de vol d’identifiants et évitez d’y ouvrir une session d’administration. La recherche sur le réseau relève de l’équipe informatique.
Pour l’équipe qui exploite le service
- Isolez le poste source selon la procédure d’incident.
- Renouvelez les secrets compromis et recherchez leurs usages sur les autres machines.
- Vérifiez les accès persistants créés avec les droits obtenus.
Pour qualifier votre situation et être orienté : 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
- MITRE ATT&CK — Pass the Hash — attack.mitre.org
- Microsoft — événement 4624 — learn.microsoft.com
