Atelier réécrit le 24 octobre 2026. Lina reçoit une alerte de laboratoire mentionnant Mimikatz. Elle doit distinguer fichier présent, exécution et accès réussi à un matériau d’authentification. Une seule VM Windows jetable, des comptes fictifs et des protections laissées actives permettent de suivre ces étapes sans domaine de production.
Le rejeu de cet atelier a été confirmé avec succès par Kenawek le 24 octobre 2026. Les sorties présentées restent illustratives ; elles ne sont pas des captures du rejeu. Adaptez les commandes à votre environnement et consignez les écarts.
En résumé
- Le scénario utilise une VM jetable et des comptes locaux fictifs, sans domaine de production.
- La version, les protections et le contexte de sécurité sont relevés avant la tentative.
- Une lecture locale de sessions est observée sans réutilisation réseau des matériaux affichés.
- Un blocage reste un résultat : aucune protection ni aucun pilote ne sont modifiés pour le contourner.
- Les événements sont corrélés et le rapport expurgé avant retour à l’instantané initial.
- VM jetableInstantané initial, réseau déconnecté pendant la mesure
- Compte fictifAucune identité professionnelle
- Observation localeMimikatz, protections et événements Windows
1. Préparer la VM
Utilisez une VM Windows supportée avec un administrateur local fictif. Préparez un instantané et le binaire depuis le projet officiel, puis déconnectez le réseau. Si l’EDR bloque le fichier, consignez-le : aucune exclusion ni désactivation n’est nécessaire pour continuer l’analyse.
New-Item -ItemType Directory -Path C:\LabMimikatz -ErrorAction Stop
Set-Location C:\LabMimikatz
Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber
whoami /user
whoami /groups
Get-Date -Format oPlacez le binaire vérifié dans ce nouveau dossier. Toutes les commandes Windows de cet atelier sont destinées à la VM, pas au poste de travail ni à un contrôleur de domaine.
2. Ouvrir une session fictive
Dans PowerShell administrateur, créez un compte de laboratoire et sa fenêtre de commande.
$labPassword = Read-Host "Mot de passe fictif LabSession" -AsSecureString
New-LocalUser -Name LabSession -Password $labPassword -Description "Test local jetable"
Add-LocalGroupMember -SID S-1-5-32-545 -Member LabSession
runas /user:.\LabSession "cmd.exe"
Get-LocalUser LabSessionSaisissez le mot de passe dans runas puis tapez whoami dans la nouvelle fenêtre. Gardez cette session ouverte. Ne l’utilisez pour aucun service distant. Un compte local hors domaine n’a normalement pas de tickets de domaine.
3. Mesurer les protections initiales
Revenez au PowerShell administrateur initial.
Get-FileHash .\mimikatz.exe -Algorithm SHA256
Get-AuthenticodeSignature .\mimikatz.exe | Select-Object Status,SignerCertificate
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus,SecurityServicesConfigured,SecurityServicesRunning
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name RunAsPPL -ErrorAction SilentlyContinue
Get-MpComputerStatus | Select-Object AMServiceEnabled,AntivirusEnabled,RealTimeProtectionEnabled
$labStart = Get-DateLa valeur 1 dans SecurityServicesRunning signale Credential Guard actif. Une valeur RunAsPPL absente ne suffit pas à conclure sur l’état effectif. Defender peut être remplacé par un autre produit : une commande indisponible est une limite de mesure.
4. Observer la version et le contexte
Lancez .\mimikatz.exe depuis le PowerShell du labo. Les commandes suivantes appartiennent à sa console interactive.
version
log C:\LabMimikatz\observation.log
token::whoami
kerberos::list
exitversion identifie le programme ; token::whoami affiche le contexte de sécurité ; kerberos::list liste les tickets du contexte sans les exporter. Une liste vide ne prouve pas une protection. Le journal reste dans la VM.
5. Tester une seule lecture locale
Relancez la console Mimikatz depuis le PowerShell administrateur. Cette étape peut montrer des matériaux sensibles si le système les expose : elle est réservée à la VM fictive et ne comprend aucune réutilisation réseau.
log C:\LabMimikatz\tentative-locale.log
privilege::debug
sekurlsa::logonpasswords
exitprivilege::debug active un privilège déjà accessible au jeton ; ce n’est pas une élévation automatique. sekurlsa::logonpasswords tente de lire les données des sessions via LSASS. Accès refusé, champs absents et données présentes sont trois observations différentes. Un blocage est conservé comme résultat : ne désactivez pas LSA ou Credential Guard et ne chargez aucun pilote pour le contourner. Ne publiez jamais le journal brut.
6. Corréler les événements
Dans le PowerShell où labStart a été défini, examinez la même fenêtre temporelle.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Defender/Operational'; StartTime=$labStart} -ErrorAction SilentlyContinue |
Select-Object TimeCreated,Id,Message
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1,10; StartTime=$labStart} -ErrorAction SilentlyContinue |
Select-Object TimeCreated,Id,Message
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=$labStart} -ErrorAction SilentlyContinue |
Select-Object TimeCreated,Id,MessageSysmon doit être déjà installé et configuré ; 4688 dépend de l’audit de création des processus. Un journal absent n’est pas un contournement prouvé. ProcessAccess 10 ne prouve pas à lui seul une extraction réussie. Corrélez heure, source, cible, résultat et éventuelle alerte SOC.
7. Rapporter et revenir à l’état initial
Fermez la fenêtre runas et les consoles Mimikatz. Inspectez les fichiers avant le retour à l’instantané.
Get-Process mimikatz -ErrorAction SilentlyContinue
Get-ChildItem C:\LabMimikatz -File | Select-Object Name,Length,LastWriteTime
Get-LocalUser LabSessionLe rapport indique la version, les protections, l’étape atteinte, le blocage éventuel et la visibilité. Aucun secret ni ticket ne quitte la VM. Restaurez ensuite l’instantané initial. Si vous conservez le labo, retirez LabSession après fermeture de sa session avec Remove-LocalUser -Name LabSession et traitez les journaux selon votre procédure. Une restauration ne révoquerait pas un vrai secret communiqué ailleurs.
Approfondir : mécanismes, limites, FAQ et sources
1. Mimikatz : de quoi parle-t-on exactement ?
Créé par Benjamin Delpy, Mimikatz est un projet de recherche et d’expérimentation sur la sécurité Windows. Ses fonctionnalités concernent notamment des matériaux d’authentification, des tickets Kerberos et leur utilisation. Il est employé dans des audits autorisés et a aussi été détourné dans des intrusions.
La présence d’un outil ne raconte pas à elle seule ce qui a réussi. Une alerte peut correspondre à un fichier bloqué avant exécution, à une tentative arrêtée par une protection ou à une activité ayant réellement accédé à des secrets. L’investigation doit établir cette chronologie.
Mimikatz n’est pas une vulnérabilité unique qu’un correctif ferait disparaître. Il expose plusieurs mécanismes et faiblesses possibles. Les fonctionnalités disponibles dépendent du système, de la version, des privilèges et des protections. Un résultat obtenu sur un ancien Windows ne peut pas être généralisé à tous les postes actuels.
2. Où se situe le risque dans l’authentification Windows ?
- UtilisateurConnexion et identité présentée
- Système WindowsServices et mécanismes d’authentification
- Matériaux utilisablesEmpreintes, clés ou tickets selon le contexte
- Ressource distanteDécision d’accès selon identité, protocole et droits
LSASS participe à l’authentification et à l’application des politiques de sécurité locales. Il intervient dans un ensemble plus large qui comprend les fournisseurs d’authentification, le système et, pour un domaine, ses contrôleurs. Ce n’est pas un coffre contenant systématiquement tous les mots de passe en clair.
La nature des données présentes dépend de la session, des protocoles, des applications et des protections. Une session distante, une session interactive et un service ne produisent pas nécessairement la même exposition. C’est pourquoi une analyse doit commencer par les chemins de connexion et les usages réels.
Un poste qui reçoit régulièrement des connexions privilégiées peut concentrer davantage de risques qu’un poste limité à des usages ordinaires. La question de défense devient alors : « Pourquoi cette identité sensible doit-elle être utilisée ici, et quel secret ce parcours laisse-t-il disponible ? »
3. Hashes, tickets et mots de passe : distinguer les techniques
| Notion | Principe | Ce qui doit être établi |
|---|---|---|
| Credential dumping | Tentative de récupérer des matériaux d’authentification. | Source des données, privilèges, succès réel et secrets concernés. |
| Recherche de mot de passe | Calcul de candidats pour retrouver un secret correspondant à une empreinte. | Format, budget et couverture de recherche. |
| Pass-the-hash | Usage d’une empreinte adaptée dans une authentification qui le permet. | Protocole, accès réseau, identité et permissions de la cible. |
| Pass-the-ticket | Usage d’un ticket Kerberos récupéré. | Validité, service, identité et contrôles appliqués. |
| Golden Ticket | Fabrication de tickets à partir d’un secret critique du domaine compromis. | Atteinte à la confiance du domaine et étendue de la compromission. |
MITRE distingue la récupération de secrets système de leur utilisation. Dans le pass-the-hash, retrouver le mot de passe en clair n’est pas un préalable. Cela explique pourquoi la seule complexité du mot de passe ne traite pas toutes les situations.
Un Golden Ticket suppose notamment l’obtention d’un secret approprié du compte KRBTGT. Ce n’est pas le résultat automatique d’un accès administrateur local à n’importe quel poste. Il faut distinguer la compromission d’une machine et celle des éléments de confiance du domaine.
D’autres mécanismes, comme DCSync, concernent l’abus de permissions de réplication de l’annuaire plutôt qu’une lecture de mémoire sur un poste utilisateur. Les mesures de protection doivent donc couvrir les droits du domaine aussi bien que la sécurité des endpoints.
4. Les prérequis comptent davantage que le nom du programme
Un accès initial ne donne pas nécessairement les droits de lire des secrets sensibles. Les privilèges du processus, les protections du système et le contexte de session conditionnent les possibilités. Une défense efficace cherche à réduire chaque transition : exécution non approuvée, élévation, exposition des secrets et réutilisation sur une autre machine.
Le moindre privilège concerne aussi les équipes d’administration. Un compte utilisé pour lire ses messages ne devrait pas servir aux opérations les plus sensibles du domaine. Des postes d’administration dédiés, des identités séparées et des parcours contrôlés réduisent les endroits où ces identités sont exposées.
Une session déjà compromise peut permettre des actions autorisées à l’utilisateur sans qu’un mot de passe soit extrait. L’absence de récupération de secrets ne suffit donc pas à déclarer le poste sain. Il faut examiner ce que l’identité et le processus pouvaient déjà faire.
5. Protection LSA et Credential Guard : deux couches distinctes
La protection supplémentaire LSA limite notamment la lecture mémoire et l’injection par des processus non protégés. Elle impose aussi des exigences aux composants chargés dans LSA. Avant déploiement, il faut donc inventorier et tester les modules d’authentification utilisés.
Credential Guard utilise la sécurité fondée sur la virtualisation pour isoler certains secrets, dont des hashes NTLM et des TGT Kerberos. Son état dépend des prérequis matériels, logiciels et des stratégies. Une activation par défaut sur certaines configurations ne dispense pas de vérifier chaque appareil.
| Couche | Objectif | Point de contrôle |
|---|---|---|
| Protection LSA | Renforcer la frontière autour du processus d’authentification. | État effectif, événements de démarrage et compatibilité des modules. |
| Credential Guard | Isoler certains secrets grâce à VBS. | Fonction effectivement en cours d’exécution et prérequis satisfaits. |
| Contrôle applicatif et EDR | Limiter des exécutions et détecter des comportements. | Politique appliquée, capteurs actifs et traitement des alertes. |
| Gestion des privilèges | Réduire les identités et droits accessibles sur le poste. | Comptes administrateurs, parcours de support et connexions sensibles. |
Les limites et problèmes de compatibilité documentés doivent être examinés avant généralisation. Credential Guard ne rend pas toutes les données de toutes les applications inaccessibles. Il ne transforme pas non plus un système compromis en environnement de confiance.
Prévoyez un groupe pilote, des parcours applicatifs représentatifs et un retour arrière documenté. Une incompatibilité doit conduire à une analyse et à une correction encadrée, pas à une exception globale et permanente pour tout le parc.
6. Vérifier un état sans lire de secrets
Le premier contrôle proposé est un inventaire en lecture seule. Sur une machine de laboratoire compatible, ouvrez PowerShell avec les droits requis par la documentation Microsoft et examinez les services de sécurité en cours d’exécution :
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunningLa documentation de configuration associe la valeur 1 à Credential Guard en fonctionnement. La propriété peut être une liste : recherchez la présence de cette valeur, et ne réduisez pas tous les autres nombres à un simple booléen. Si la classe n’est pas accessible ou si la commande échoue, enregistrez le contrôle comme non concluant plutôt que comme une désactivation confirmée.
Comparez l’observation avec les informations système et la politique attendue. Une clé de configuration ou une console d’administration qui annonce un déploiement n’est pas la même preuve qu’un état actif sur la machine. Consignez aussi les redémarrages et changements récents.
Pour LSA, suivez les vérifications de l’éditeur et les journaux appropriés à la version. Ne tentez pas de lire la mémoire du processus pour réaliser un simple inventaire. Le rejeu du guide a été confirmé par Kenawek ; vérifiez ce contrôle sur la version et la configuration de votre propre environnement.
7. LAPS, segmentation et administration : réduire la propagation
Windows LAPS gère et sauvegarde le mot de passe d’un compte administrateur local, avec rotation selon la configuration. Le bénéfice recherché est notamment d’éviter qu’un secret local identique ouvre de nombreuses machines. Vérifiez qui peut lire les secrets sauvegardés et si la rotation fonctionne réellement.
LAPS ne protège pas à lui seul tous les comptes du domaine. Complétez-le par des groupes d’administration limités, des comptes de service adaptés et des restrictions de connexion. Un compte de domaine très privilégié présent sur un poste compromis peut créer un risque différent de celui traité par la rotation du compte local.
La segmentation doit correspondre aux usages : quels postes peuvent administrer quels serveurs, et par quels mécanismes ? Vérifiez depuis une source autorisée et une source qui ne devrait pas l’être. Une règle réseau théorique n’est utile que si son comportement réel correspond au besoin.
La série durcissement Active Directory permet de relier ces mesures aux paliers d’administration, aux protocoles et à la supervision. La sécurité d’un domaine dépend de la cohérence de cet ensemble.
8. Détection SOC : construire une chaîne de preuves
- SourceProcessus, identité et poste concernés
- ActionAccès sensible ou opération inhabituelle
- ContexteSignature, droits, horaire et activité attendue
- CorrélationAuthentification distante et actions suivantes
- TraitementQualification, confinement et conservation des preuves
Une recherche limitée au nom mimikatz.exe peut manquer une autre implémentation et mal qualifier un fichier bloqué. Les comportements et leur contexte sont plus utiles pour comprendre ce qui s’est passé. Il faut distinguer tentative, accès effectivement accordé et utilisation ultérieure d’un secret.
Sysmon documente notamment l’événement 10, ProcessAccess, qui enregistre l’ouverture d’un processus par un autre selon la configuration. Un accès à LSASS mérite une analyse, mais n’est pas automatiquement malveillant : des composants de sécurité ou de diagnostic peuvent avoir des usages légitimes.
Établissez une référence des sources attendues et examinez la signature, l’identité, les droits demandés, la filiation du processus et les événements voisins. Une règle doit être testée sur des activités légitimes autant que sur un scénario d’exercice. Exclure tous les processus d’un répertoire ou d’un éditeur peut créer un angle mort trop large.
Mesurez séparément la génération d’un événement, sa collecte, la création d’une alerte et sa prise en charge. Si un capteur ne remonte rien, vérifiez sa configuration et sa santé. L’absence d’événement ne prouve ni l’absence d’action ni l’efficacité du blocage.
9. Un protocole de validation sans données de production
Préparez une machine isolée avec un système supporté, des comptes fictifs et les capteurs prévus. Notez les versions, les politiques, l’état de Credential Guard et de LSA Protection, les permissions et la synchronisation des horloges. Aucun compte administrateur de production ne doit ouvrir de session dans ce laboratoire.
Commencez par les contrôles de configuration et un parcours métier normal. Pour vérifier le traitement SOC, injectez ensuite un événement de test explicitement marqué comme simulé dans un espace réservé à l’exercice. Ce test vérifie l’acheminement et la règle ; il ne prouve pas que le capteur détecterait une attaque réelle.
Si la mission inclut une simulation technique d’accès aux secrets, définissez à part son scénario, ses critères d’arrêt et ses preuves, avec l’équipe de sécurité. Un succès ou un blocage doit être interprété dans cette configuration exacte. Il n’est pas nécessaire de désactiver les protections pour que le laboratoire fournisse une information utile.
Après l’exercice, comparez les résultats attendus et observés, confirmez les parcours légitimes, retirez les comptes temporaires et remettez le laboratoire dans l’état convenu. Conservez un rapport expurgé avec les limites de couverture. Ne publiez aucune capture contenant un vrai secret.
10. Réagir à une suspicion de vol de secrets
La priorité est de déterminer si l’activité est en cours et quelles identités ont pu être exposées. Coordonnez le confinement avec l’équipe de réponse à incident et les contraintes métier. Conservez les éléments nécessaires à l’enquête selon la procédure prévue ; une action précipitée peut supprimer des indices ou interrompre une activité critique.
Ne vous limitez pas à supprimer le fichier détecté. Examinez les connexions, les comptes présents sur la machine, les opérations réalisées et les systèmes atteints. Une simple rotation de mot de passe ne règle pas tous les cas : des sessions, tickets ou mécanismes de persistance peuvent nécessiter des actions distinctes.
En cas d’atteinte à des secrets de confiance du domaine, la récupération doit suivre un plan spécialisé, tenant compte de la réplication et des dépendances. Les opérations sur KRBTGT ne doivent pas être improvisées comme une réinitialisation ordinaire. Le périmètre de la compromission doit guider l’ordre des actions.
Après rétablissement, faites vérifier les protections effectives et les chemins d’administration. L’objectif est de fermer les conditions qui ont rendu l’exposition possible, puis de disposer d’une preuve que la détection et le traitement fonctionnent.
11. Questions fréquentes : ce que chaque protection change
Un mot de passe très long suffit-il ?
Il aide contre la recherche du mot de passe, mais pas contre tous les usages d’un secret déjà disponible. Le guide Ophcrack explique cette distinction entre calcul et réutilisation.
Le MFA bloque-t-il Mimikatz ?
Le MFA protège les parcours qui l’exigent. Il ne garantit pas qu’aucun matériau réutilisable ne sera exposé sur un poste, ni que tous les protocoles internes demanderont un second facteur. Il faut analyser le parcours complet.
BitLocker et Credential Guard font-ils la même chose ?
Non. Le premier vise notamment la protection des volumes contre les accès hors ligne ; le second isole certains secrets pendant l’exécution du système. Ils répondent à des moments différents du risque.
Un antivirus qui bloque le fichier suffit-il comme preuve ?
C’est une observation utile pour ce fichier et cette configuration. Ce n’est pas une validation de tous les chemins d’accès aux secrets ni des autres outils. La défense doit aussi limiter les privilèges et les possibilités de réutilisation.
Comment relier ce sujet à un audit réseau ?
Le guide Impacket aide à comprendre les interactions entre une identité, les protocoles et les droits. Le résultat doit être traduit en corrections ciblées, puis en contre-tests, comme décrit dans le plan de remédiation après pentest.
Sources et références
Références consultées le 24 octobre 2026. Les schémas et scénarios sont pédagogiques ; le rejeu a été confirmé par Kenawek, sans publication de journaux bruts ni de résultat de mission client.
- Benjamin Delpy - dépôt officiel Mimikatz
- Microsoft - protection supplémentaire LSA
- Microsoft - présentation de Credential Guard
- Microsoft - configuration et vérification de Credential Guard
- Microsoft - limites et compatibilité de Credential Guard
- Microsoft - Windows LAPS
- Microsoft Sysinternals - événements Sysmon
- MITRE ATT&CK - OS Credential Dumping
- MITRE ATT&CK - Pass the Hash
- MITRE ATT&CK - Golden Ticket