Vol d'identifiants Windows : LSASS, DCSync et Kerberoasting

Le vol d'identifiants est le pivot de la plupart des intrusions Windows : l'attaquant transforme une première tête de pont en accès à tout le domaine en dumpant LSASS, en copiant des ruches ou en demandant ses secrets à un contrôleur de domaine. Ce guide montre, côté défense, les traces que laisse chaque technique dans les journaux d'événements, Sysmon, le système de fichiers et le registre. Vous saurez confirmer ou écarter un accès aux identifiants sur un poste comme sur les contrôleurs de domaine, rattacher chaque constat à MITRE ATT&CK et délimiter les comptes à réinitialiser.

Il fait suite au guide RDP, PsExec et WinRM de la série sur le mouvement latéral : l'accès aux identifiants est en général ce qui précède juste ces ouvertures de session.

Correspondance technique et preuves

Les identifiants de sous-techniques sont à jour au moment de la rédaction ; vérifiez-les sur attack.mitre.org avant de les reporter dans un rapport.

Accès à LSASS et dumps

Sysmon Event 10 : GrantedAccess et CallTrace

lsass.exe détient les hashs NTLM, les tickets et clés Kerberos et, sur des systèmes anciens ou mal configurés, des mots de passe en clair (WDigest). Pour les lire, il faut ouvrir un handle sur LSASS avec des droits de lecture. Sysmon Event 10 (ProcessAccess) enregistre l'image source, l'image cible, le masque d'accès (GrantedAccess) et un CallTrace des modules présents sur la pile.

Parmi les masques souvent associés au dump d'identifiants figurent 0x1010 et 0x1410 (query information plus PROCESS_VM_READ, le sekurlsa classique de Mimikatz), 0x1438, 0x143a et 0x1fffff (accès complet). Ce sont des pistes, pas des verdicts : antivirus, EDR, agents de sauvegarde et processus système ouvrent LSASS en permanence, et les attaquants choisissent leurs masques pour se fondre dans la masse. Un CallTrace qui passe par dbghelp.dll ou dbgcore.dll (MiniDumpWriteDump), ou qui contient des frames UNKNOWN (du code hors de tout module chargé), pèse plus lourd que le masque seul. Sysmon ne journalise cet accès que si sa configuration contient une règle ProcessAccess pour lsass.exe, et beaucoup de configurations le filtrent fortement.

# Événements Sysmon 10 ciblant LSASS, hors source connue comme saine
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=10} |
  Where-Object { $_.Message -match 'TargetImage: .*\\lsass\.exe' -and
                 $_.Message -notmatch 'SourceImage: .*\\MsMpEng\.exe' } |
  Select-Object TimeCreated, Message

Outils de dump et leurs traces

Les moyens courants de produire un dump, et ce qu'ils laissent :

• ProcDump : procdump.exe -accepteula -ma lsass.exe out.dmp. Création de processus avec la ligne de commande (Security 4688 si l'audit des lignes de commande est actif, Sysmon 1), Prefetch pour PROCDUMP.EXE ou PROCDUMP64.EXE, et HKCU\Software\Sysinternals\ProcDump\EulaAccepted pour l'utilisateur qui l'a lancé. Les attaquants renomment souvent le binaire ; le champ Sysmon OriginalFileName et le hash du fichier l'identifient malgré tout.
• comsvcs.dll MiniDump : rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <PID> C:\Windows\Temp\x.dmp full. Variante LOLBin : cherchez des lignes de commande rundll32 contenant comsvcs et MiniDump (ou un ordinal comme #24), et un fichier Prefetch de RUNDLL32.EXE dont les fichiers référencés incluent COMSVCS.DLL et DBGCORE.DLL.
• Gestionnaire des tâches : « Créer un fichier de vidage » sur lsass écrit lsass.DMP dans le %LOCALAPPDATA%\Temp de l'utilisateur. Cela suppose une session interactive et des droits administrateur : corrélez avec les ouvertures de session RDP.
• Détournement de silent process exit : l'attaquant configure SilentProcessExit\lsass.exe dans le registre pour que WER écrive un dump quand LSASS est amené à signaler une sortie. Vérifiez HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\lsass.exe (valeurs LocalDumpFolder et DumpType) ainsi que la clé IFEO pour une valeur GlobalFlag.
• Outils sur mesure (nanodump, appels système directs, duplication de handles) : ils cherchent à éviter ces traces. Attendez-vous à ce que la télémétrie EDR et l'analyse mémoire pèsent davantage.

Le fichier de dump est le trésor de l'attaquant, et le vôtre. Sysmon Event 11 (FileCreate) enregistre la création des .dmp, et la MFT comme le journal USN conservent nom, chemin et horodatages même après suppression. Cherchez les gros fichiers .dmp et les archives créées juste après (les dumps sont en général compressés avant exfiltration). Passez aussi en revue les emplacements de Windows Error Reporting et de crash dumps : un plantage de LSASS causé par un outil maladroit peut laisser son propre rapport.

Defender, ASR et protection LSA

Les détections Microsoft Defender comme HackTool:Win32/Mimikatz ou Behavior:Win32/LsassDump apparaissent en 1116 (détection) et 1117 (action effectuée) dans Microsoft-Windows-Windows Defender/Operational, ainsi que dans les fichiers MPLog sous C:\ProgramData\Microsoft\Windows Defender\Support. La règle de réduction de la surface d'attaque (ASR) « Bloquer le vol d'informations d'identification du sous-système LSA » journalise 1121 en mode blocage et 1122 en mode audit. Les noms de détection évoluent avec les mises à jour de signatures : cherchez par famille plutôt que par chaîne exacte.

Vérifiez aussi la configuration. RunAsPPL sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa exécute LSASS comme processus protégé, et Credential Guard isole les secrets dans LsaIso.exe. Un attaquant qui positionne UseLogonCredential = 1 sous HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest réactive la mise en cache des mots de passe en clair, un indicateur d'intention fort. Chacune de ces clés a une date de dernière écriture à placer dans la chronologie.

Ruches SAM, SECURITY et SYSTEM

Les hashs des comptes locaux se trouvent dans la ruche SAM, protégée par la boot key stockée dans SYSTEM. Les secrets LSA (mots de passe de comptes de service, secret du compte machine, parfois mots de passe d'autologon) et les ouvertures de session de domaine en cache (DCC2) se trouvent dans SECURITY. Un attaquant administrateur les exporte pour les casser hors ligne :

reg save HKLM\SAM      C:\Windows\Temp\s.hiv
reg save HKLM\SYSTEM   C:\Windows\Temp\y.hiv
reg save HKLM\SECURITY C:\Windows\Temp\e.hiv

Preuves : 4688 ou Sysmon 1 pour reg.exe avec save et le nom de la ruche, Prefetch de REG.EXE, Sysmon 11 et entrées MFT pour les nouveaux fichiers (souvent avec des extensions trompeuses), puis création d'archives ou transferts SMB peu après. Certaines variantes se passent de reg.exe : copie des ruches depuis une shadow copy (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\Windows\System32\config\SAM), esentutl.exe /y /vss, ou la faille HiveNightmare (CVE-2021-36934) qui permettait à des non-administrateurs de lire les shadow copies des ruches sur les builds vulnérables. Voir les pages ruches de registre et comptes utilisateurs SAM pour les structures concernées.

Extraction de NTDS.dit sur les contrôleurs de domaine

NTDS.dit contient le hash de tous les comptes du domaine. Il est verrouillé tant qu'AD DS tourne, d'où deux voies d'accès pour l'attaquant.

ntdsutil IFM (Install From Media) crée une copie cohérente accompagnée des ruches SYSTEM et SECURITY :

ntdsutil "ac i ntds" "ifm" "create full C:\Windows\Temp\ifm" q q

Cela laisse un événement de création de processus avec la ligne de commande complète, et des événements ESENT dans le journal Application souvent cités pour cette activité : 216 (changement d'emplacement de base), 325 (nouvelle base créée), 326 (base attachée) et 327 (base détachée). Le dossier de sortie contient Active Directory\ntds.dit et registry\SYSTEM/SECURITY, faciles à repérer dans la MFT même après suppression.

Shadow copy : vssadmin create shadow /for=C: ou WMI Win32_ShadowCopy.Create, puis copie de ntds.dit et SYSTEM depuis le chemin du périphérique de shadow copy. Cherchez des créations de processus vssadmin, wmic shadowcopy ou diskshadow, des démarrages du service Volume Shadow Copy dans le journal System et des shadow copies dont l'heure de création ne correspond à aucune sauvegarde planifiée. La page shadow copies explique comment les énumérer. Le tri détaillé d'un DC est traité dans le guide d'investigation des contrôleurs de domaine.

DCSync

DCSync détourne le protocole de réplication de l'annuaire (MS-DRSR) : tout compte qui détient les droits étendus de réplication peut demander à un DC de répliquer les données de mots de passe, sans exécuter le moindre code sur le DC. La preuve côté DC est l'événement Security 4662 (une opération a été effectuée sur un objet) dont le champ Properties contient :

Les contrôleurs de domaine répliquent en permanence : écartez les sujets qui sont des comptes ordinateurs de DC (terminés par $ et membres de Domain Controllers). Un compte utilisateur ou un compte machine hors DC dans SubjectUserName est un constat fort. L'événement n'existe que si l'audit Directory Service Access est activé et que l'objet domaine porte une SACL d'audit : vérifiez les deux avant de conclure « pas de DCSync ». Les preuves réseau (RPC DRSUAPI depuis l'IP d'un poste) et les 4624 sur le DC depuis l'hôte attaquant aident à attribuer la source. Vérifiez aussi qui a reçu récemment des droits de réplication : un 5136 (objet d'annuaire modifié) sur le nTSecurityDescriptor de la racine du domaine peut révéler un attaquant qui prépare un DCSync persistant.

DPAPI, Credential Manager et navigateurs

DPAPI protège les identifiants RDP enregistrés, les entrées du Credential Manager, les clés Wi-Fi et les secrets des navigateurs. Les master keys par utilisateur se trouvent dans %APPDATA%\Microsoft\Protect\<SID>\, les blobs d'identifiants dans %APPDATA%\Microsoft\Credentials et %LOCALAPPDATA%\Microsoft\Credentials, et les coffres dans %LOCALAPPDATA%\Microsoft\Vault. Voir DPAPI et Credential Manager.

Les traces de vol comprennent :

• Security 4692 (tentative de sauvegarde d'une master key de protection des données) et 4693 (tentative de récupération), si l'audit DPAPI Activity est activé. Sur les DC, la récupération de la clé de sauvegarde DPAPI du domaine permet à l'attaquant de déchiffrer les master keys de tous les utilisateurs : c'est un constat de gravité élevée, qui exige en général des droits d'administrateur du domaine.
• La création de processus cmdkey /list, vaultcmd /listcreds:"Windows Credentials" ou d'outils comme SharpDPAPI et les modules dpapi:: de Mimikatz.
• Des processus autres que le navigateur qui lisent Login Data et Local State de Chrome ou Edge, ou logins.json et key4.db de Firefox. Une simple lecture de fichier n'est pas journalisée par Sysmon : il faut la télémétrie fichier d'un EDR ou l'audit d'accès aux objets (4663) avec une SACL. Les versions récentes de Chromium ajoutent un chiffrement lié à l'application (app-bound encryption), ce qui pousse les attaquants à injecter du code dans le navigateur ou à détourner son service d'élévation, visible sous forme de processus enfants ou de chargements de modules inhabituels. Le guide forensique des navigateurs couvre les magasins eux-mêmes.

Les attaquants ciblent aussi les conteneurs d'identifiants laissés sur disque : bases KeePass, fichiers Office protégés, clés privées SSH. Quand l'un d'eux apparaît dans une collecte et que vous devez savoir s'il était protégé par un mot de passe connu ou réutilisé, Hash Extractor produit le hash hashcat ou John côté client, et Secretsdump fait de même pour les ruches SAM, les secrets LSA et NTDS.dit afin de délimiter les comptes exposés.

Attaques Kerberos

Elles se lisent dans le journal Security des contrôleurs de domaine : collectez-le sur chaque DC. Le guide des journaux d'événements détaille la collecte et le parsing.

Kerberoasting

Tout utilisateur du domaine peut demander un ticket de service pour un compte doté d'un Service Principal Name ; le ticket est chiffré avec la clé de ce compte de service et peut être cassé hors ligne. Les tickets RC4 se cassent bien plus vite, d'où la demande du type de chiffrement 0x17. Sur les DC, 4769 (ticket de service demandé) montre :

• Ticket Encryption Type = 0x17,
• un Service Name qui n'est ni krbtgt ni un compte ordinateur terminé par $,
• un même Account Name qui demande des tickets pour de nombreux services différents en quelques minutes, depuis une seule Client Address.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} |
  Where-Object { $_.Properties[5].Value -eq 0x17 -and $_.Properties[2].Value -notmatch '\$$|^krbtgt$' } |
  Group-Object { $_.Properties[0].Value } | Sort-Object Count -Descending |
  Select-Object Count, Name

La position des champs dans Properties peut varier selon les builds ; vérifiez-la sur le XML d'un événement avant de vous fier aux indices. L'absence de RC4 ne blanchit pas un compte : les tickets AES (0x12) peuvent aussi être roastés, simplement plus lentement.

AS-REP roasting

Les comptes configurés avec « Ne pas demander la pré-authentification Kerberos » (DONT_REQ_PREAUTH, UserAccountControl 0x400000) renvoient à quiconque le demande un AS-REP chiffré avec la clé de l'utilisateur. Cherchez des 4768 avec Pre-Authentication Type = 0, listez les comptes qui portent ce drapeau et vérifiez les 4738 (compte utilisateur modifié) pour repérer un attaquant qui l'active volontairement afin de roaster le compte plus tard.

Pass-the-hash, pass-the-ticket et tickets forgés

• Pass-the-hash (T1550.002) avec sekurlsa::pth de Mimikatz produit un 4624 local de type d'ouverture de session 9, avec le processus d'ouverture seclogo et le package d'authentification Negotiate, sur l'hôte de l'attaquant. Sur les cibles, il apparaît comme des ouvertures de session réseau NTLM (type 3) depuis des hôtes qui utilisent normalement Kerberos.
• Overpass-the-hash se manifeste par une demande de TGT 4768 chiffrée en RC4 pour un compte qui utilise normalement AES.
• Pass-the-ticket (T1550.003) et les tickets forgés (T1558.001 golden, T1558.002 silver) sont plus difficiles : cherchez des 4769 sans 4768 préalable pour ce compte et cet hôte, des tickets aux durées de vie anormales, des noms de comptes inexistants et, en mémoire (guide d'analyse mémoire), des tickets Kerberos qui ne correspondent pas à l'utilisateur connecté.

Associez chaque 4624 trouvé à son SID et à son adresse source : l'objectif est la liste des identités compromises.

Erreurs fréquentes

• Conclure « pas de dump » faute d'événements. Sysmon ProcessAccess, l'audit des lignes de commande, l'audit DPAPI et l'audit Directory Service Access sont souvent désactivés. Indiquez quelle télémétrie existait avant d'affirmer ce qui ne s'est pas produit.
• Alerter sur GrantedAccess seul. Les produits de sécurité génèrent l'essentiel des accès à LSASS. Établissez une baseline des sources par rôle d'hôte, puis regardez les valeurs aberrantes.
• Ignorer les binaires renommés. Un procdump renommé en svchost.exe garde son nom de fichier d'origine dans l'en-tête PE et un hash connu.
• Ne vérifier qu'un seul DC. Les événements Kerberos et DCSync atterrissent sur le DC qui a répondu. Collectez-les tous.
• Réinitialiser trop peu de comptes. Un DCSync ou un vol de NTDS.dit signifie que tous les hashs du domaine sont compromis, y compris celui de krbtgt, à réinitialiser deux fois avec une réplication entre les deux.
• Oublier le trajet du dump. Retrouvez où sont partis le .dmp ou les copies de ruches : archives, partages, envois vers le cloud.

Méthode d'investigation

1. Inventorier la télémétrie : quels hôtes ont Sysmon (et journalise-t-il l'Event 10 pour lsass), l'audit des lignes de commande, l'audit DPAPI et DS Access, un EDR.
2. Chasser côté hôte : Sysmon 10 sur lsass, créations de processus pour procdump, comsvcs, reg save, ntdsutil, vssadmin, cmdkey, vaultcmd ; Defender 1116/1117 et ASR 1121/1122.
3. Fouiller le système de fichiers : fichiers .dmp, copies de ruches, dossiers ifm, archives, dans la MFT et le journal USN, entrées supprimées comprises.
4. Chasser sur les DC : 4662 avec GUID de réplication depuis des sujets non DC, ESENT 216/325/326/327, création de shadow copies, rafales de 4769 RC4, 4768 avec pré-authentification de type 0, modifications 4738 et 5136.
5. Contrôler les dérives de configuration : UseLogonCredential de WDigest, RunAsPPL, SilentProcessExit sur lsass, comptes sans pré-authentification, nouveaux droits de réplication.
6. Dresser la liste des identités : tous les comptes dont les identifiants étaient exposés sur chaque hôte touché, plus tous les comptes du domaine si NTDS.dit ou DCSync est confirmé.
7. Corréler avec le mouvement latéral : suivez ces identités à travers les ouvertures de session 4624/4648 pour mesurer la propagation, puis planifiez les réinitialisations avec le confinement. Si l'hôte tourne encore, capturez d'abord la mémoire comme décrit dans le guide de live response.