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
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
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 pour se connecter. Même si cette empreinte ne révèle pas le mot de passe en clair, certains mécanismes Windows l’acceptent comme preuve d’accès. Il faut donc protéger les données de connexion conservées en mémoire et limiter les droits des comptes pour réduire les conséquences d’un vol.
- 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.
Certains mécanismes acceptent une empreinte volée pour se connecter, même sans connaître le mot de passe lisible.
À 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 ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Oui. Certains mécanismes Windows acceptent cette empreinte comme preuve d’authentification. L’attaquant peut donc se connecter sans retrouver le mot de passe lisible.
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
Une authentification NTLM ouvre un partage puis un accès distant
Le serveur de fichiers accepte une connexion réseau NTLM, enregistre un accès à ADMIN$, puis une activité distante. Une empreinte NTLM volée peut expliquer cette suite. Les journaux d’authentification ne permettent toutefois pas toujours de la distinguer d’une connexion utilisant 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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
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.
- 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 ?
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 : 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
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.
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
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.
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 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
- MITRE ATT&CK — Pass the Hash — attack.mitre.org
- Microsoft — événement 4624 — learn.microsoft.com
