Active Directory - Credential Dumping - Post-exploitation - MITRE ATT&CK T1555
La Data Protection API (DPAPI) est le mécanisme Windows qui chiffre les mots de passe des navigateurs, les credentials du Credential Manager, les certificats et les secrets des applications. En obtenant les droits Domain Admin sur un Active Directory, un attaquant peut extraire la clé de sauvegarde de domaine et déchiffrer tous les secrets DPAPI de tous les utilisateurs du domaine. Ce guide explique l'architecture, les techniques d'exploitation utilisées en pentest et comment s'en défendre.
Qu'est-ce que la DPAPI (Data Protection API) ?
La Data Protection API (DPAPI) est une interface de programmation intégrée à Windows depuis Windows 2000 qui permet aux applications de chiffrer et déchiffrer des données sensibles sans avoir à gérer elles-mêmes la complexité cryptographique. Elle repose sur deux fonctions principales exposées dans crypt32.dll :
CryptProtectData(): chiffre un bloc de données en utilisant les credentials de l'utilisateur ou de la machine comme source d'entropie.CryptUnprotectData(): déchiffre un blob DPAPI en retrouvant la clé appropriée depuis les credentials disponibles dans le contexte d'exécution.
L'opération de chiffrement est réalisée par LSASS (Local Security Authority Subsystem Service) via un appel RPC. Ce design simplifie le développement : l'application stocke un blob chiffré sur disque sans gérer de clé. La sécurité repose entièrement sur la protection des credentials Windows de l'utilisateur ou de la machine.
Concrètement, la DPAPI protège aujourd'hui une surface extraordinairement large de secrets Windows :
- Navigateurs Chromium (Chrome, Edge, Brave, Opera) : mots de passe, cookies, tokens d'authentification, données de formulaires.
- Windows Credential Manager : credentials de connexion aux partages réseau, aux sessions RDP, aux comptes Microsoft, aux tokens OAuth.
- Certificats et clés privées : clés privées des certificats utilisateur stockées dans le magasin de certificats Windows.
- Applications Microsoft Office : tokens d'accès aux services Microsoft 365.
- Wi-Fi profiles : clés WPA/WPA2 des réseaux sans fil mémorisés.
- Tâches planifiées : credentials des comptes de service configurés dans le Planificateur de tâches.
- Applications tierces : tout logiciel utilisant l'API Windows standard de protection des données.
Pour un pentester, la DPAPI représente un coffre-fort centralisé de secrets : compromettre le mécanisme de déchiffrement, c'est potentiellement accéder à l'ensemble des secrets de chaque utilisateur d'un domaine Active Directory.
Architecture de la DPAPI : Master Keys, blobs et clé de sauvegarde de domaine
Comprendre l'architecture de la DPAPI est indispensable pour saisir pourquoi elle est si attractive pour un attaquant ayant obtenu des droits élevés. La protection repose sur une hiérarchie de clés à trois niveaux.
Niveau 1 : Le DPAPI blob
Un DPAPI blob est le résultat de l'appel à CryptProtectData(). C'est un fichier binaire structuré qui contient les données chiffrées, un GUID référençant la Master Key utilisée pour le chiffrement, l'algorithme de chiffrement (typiquement AES-256 en mode CBC), et un HMAC permettant de vérifier l'intégrité du blob. Le blob est stocké sur disque par l'application : dans le profil utilisateur pour les credentials navigateurs, dans %APPDATA%MicrosoftCredentials pour le Credential Manager, etc.
Niveau 2 : La Master Key (MK)
Chaque utilisateur Windows possède une ou plusieurs Master Keys, stockées dans %APPDATA%MicrosoftProtect{SID}. Chaque fichier de Master Key est lui-même chiffré. La clé de déchiffrement de la Master Key est dérivée du mot de passe de l'utilisateur (via PBKDF2), de son SID et d'un sel aléatoire. Sans le mot de passe de l'utilisateur ou un mécanisme de récupération, il est impossible de déchiffrer la Master Key et donc les blobs.
Niveau 3 : La clé de sauvegarde de domaine (Domain Backup Key)
C'est ici que la DPAPI en environnement Active Directory prend toute sa dimension offensive. Dans un domaine Windows, chaque Master Key est également chiffrée avec la clé de sauvegarde de domaine (DPAPI Domain Backup Key), stockée sur le contrôleur de domaine. Ce mécanisme permet à un administrateur de récupérer les secrets d'un utilisateur dont le mot de passe a été perdu.
La clé de sauvegarde de domaine est une paire de clés RSA-2048. La clé publique est distribuée à toutes les machines du domaine pour chiffrer une copie de chaque Master Key. La clé privée est stockée de façon sécurisée sur le DC dans l'objet LSA Secrets.
Conséquence pour la sécurité : quiconque extrait cette clé privée peut déchiffrer toutes les Master Keys de tous les utilisateurs du domaine, et donc tous les blobs DPAPI de tout le monde. C'est la raison pour laquelle la DPAPI Domain Backup Key est qualifiée de crown jewel de l'Active Directory dans la communauté offensive.
La DPAPI_SYSTEM : secrets de la machine
En parallèle des Master Keys utilisateur, Windows maintient une DPAPI_SYSTEM pour les secrets de niveau machine : credentials des tâches planifiées, des services Windows, des profils Wi-Fi, des connexions VPN. La clé de déchiffrement de ces secrets est stockée dans les LSA Secrets, accessible à un processus tournant avec les droits SYSTEM. En pentest d'infrastructure, l'obtention des droits SYSTEM sur un serveur permet d'extraire ces secrets machine directement depuis la mémoire ou les ruches de registre.
Votre Active Directory résiste-t-il à une extraction de Domain Backup Key ?
Nos missions de pentest infrastructure et Active Directory testent systématiquement les chemins d'escalade vers Domain Admin et l'extraction des secrets DPAPI. Découvrez notre approche.
Structures internes de la DPAPI : ce que le reverse engineering révèle
Comprendre les structures binaires de la DPAPI permet d'appréhender précisément pourquoi certaines attaques fonctionnent, et où se situent les vraies faiblesses cryptographiques. Cette section s'appuie sur les travaux de recherche présentés par Jean-Christophe Delaunay (Synacktiv) à la JSSI 2017, qui constituent la référence francophone sur le sujet.
Structure d'un DPAPI blob
Chaque appel à CryptProtectData() produit un blob binaire avec la structure suivante :
| Champ | Type | Description |
|---|---|---|
dwVersion |
DWORD | Version de la structure DPAPI |
guidMasterKey |
GUID | Identifiant de la Master Key utilisée pour le chiffrement. Permet de retrouver le bon fichier MK dans %AppData%MicrosoftProtect{SID} |
algCrypt |
ALG_ID | Algorithme de chiffrement utilisé (AES-256 sur les versions modernes) |
pSalt |
BYTE[] | Sel aléatoire pour la dérivation de clé, protège contre les Rainbow Tables |
pHmac |
BYTE[] | HMAC de vérification d'intégrité du blob |
algHash |
ALG_ID | Algorithme de hachage (SHA-512 sur Win7+) |
pData |
BYTE[] | Données chiffrées |
pSign |
BYTE[] | Signature de validation finale |
Le champ guidMasterKey est particulièrement important pour un attaquant : il indique directement quel fichier Master Key doit être déchiffré pour accéder aux données. Cette information est en clair dans le blob, ce qui permet de cibler précisément la clé à attaquer.
Structure d'en-tête d'un fichier Master Key
Le fichier Master Key lui-même a une structure binaire documentée par Synacktiv. L'en-tête contient notamment :
dwVersion: version de la structureszGuid: GUID de cette Master Key (correspond au nom du fichier sur disque)dwUserKeySize: taille du bloc chiffré par le mot de passe utilisateurdwLocalEncKeySize: taille du bloc chiffré par la clé locale machinedwLocalKeySize: taille du bloc de clé localedwDomainKeySize: taille du bloc chiffré par la Domain Backup Key (présent uniquement dans les environnements Active Directory)
La présence de dwDomainKeySize non nul dans un fichier Master Key confirme que la machine est jointe à un domaine et qu'une copie de la MK chiffrée par la Domain Backup Key est disponible. Pour un pentester, cela signifie que la MK peut être déchiffrée depuis le DC sans connaître le mot de passe de l'utilisateur.
Évolution des algorithmes cryptographiques par version Windows
L'une des données les plus pertinentes pour évaluer la résistance au craquage offline est l'évolution des algorithmes et du nombre d'itérations PBKDF2 selon la version de Windows :
| Version Windows | Algorithme de chiffrement | Algorithme de hachage | Itérations PBKDF2 | Résistance au craquage offline |
|---|---|---|---|---|
| Windows 2000 | RC4 | SHA-1 | 1 | Nulle (attaque GPU triviale) |
| Windows XP | 3DES | SHA-1 | 4 000 | Faible |
| Windows Vista | 3DES | SHA-1 | 24 000 | Moyenne |
| Windows 7 et ultérieur | AES-256 | SHA-512 | 5 600 | Bonne (mot de passe fort requis) |
CREDHIST : le fichier qui conserve l'historique des mots de passe
Le fichier CREDHIST (Credential History) est l'un des composants les moins connus de la DPAPI, pourtant capital en forensique et en pentest offline. Il est stocké dans %AppData%MicrosoftProtectCREDHIST et joue un rôle clé dans la continuité du déchiffrement DPAPI lors des changements de mot de passe.
Fonctionnement du CREDHIST
Quand un utilisateur change de mot de passe, ses Master Keys existantes ont été chiffrées avec l'ancien mot de passe. Sans mécanisme de transition, ces Master Keys deviendraient illisibles après le changement. C'est le rôle du CREDHIST : il stocke une chaîne de condensats de tous les mots de passe successifs de l'utilisateur, permettant à Windows de remonter dans l'historique pour déchiffrer des Master Keys créées avec un ancien mot de passe.
La structure du CREDHIST est une chaîne de blocs enchaînés :
- Chaque entrée contient un condensat du mot de passe au format NT et SHA1.
- Chaque condensat est chiffré par le condensat du mot de passe précédent dans la chaîne.
- Le condensat le plus récent (n) est chiffré par le mot de passe actuel.
- Le condensat n-1 est chiffré par le condensat n, et ainsi de suite jusqu'au mot de passe initial (1).
Implications offensives du CREDHIST
Pour un pentester ou un analyste forensique, le fichier CREDHIST présente plusieurs intérêts concrets :
- Craquage des anciens mots de passe : le CREDHIST stocke les condensats NT et SHA1 de tous les anciens mots de passe de l'utilisateur. Ces condensats peuvent être extraits et soumis à Hashcat pour retrouver les mots de passe en clair. Des anciens mots de passe souvent plus faibles (politiques de complexité moins strictes dans le passé) peuvent ainsi être retrouvés même si le mot de passe actuel est robuste.
- Déchiffrement offline de Master Keys historiques : dans un contexte forensique ou de pentest offline (extraction d'image disque), si le mot de passe actuel n'est pas connu mais qu'un ancien mot de passe est identifié (via le CREDHIST ou d'autres sources), il est possible de déchiffrer les Master Keys créées sous cet ancien mot de passe, et donc les blobs DPAPI correspondants.
- Corrélation multi-comptes : si un utilisateur réutilise le même mot de passe sur plusieurs comptes ou services, le CREDHIST révèle l'historique de ces réutilisations. La découverte d'un ancien mot de passe via le CREDHIST peut permettre d'accéder à des comptes externes où ce même mot de passe était encore utilisé.
Le fichier CREDHIST est localisé dans %AppData%MicrosoftProtectCREDHIST et peut être extrait lors d'un accès au profil utilisateur, même offline. En pratique, sa lecture nécessite un outil spécialisé (dpapick, impacket-dpapi ou des outils internes Synacktiv) car sa structure binaire n'est pas documentée officiellement.
Stockage complet des assets DPAPI sur disque
Pour un inventaire complet de ce qu'un attaquant doit collecter lors d'un accès au profil utilisateur, les assets DPAPI sont répartis dans le profil de la façon suivante :
%AppData%MicrosoftProtectCREDHIST: historique des condensats de mots de passe%AppData%MicrosoftProtect{SID}{GUID}: fichiers Master Keys de l'utilisateur%AppData%MicrosoftCredentials{GUID}: blobs DPAPI du Credential Manager%AppData%MicrosoftVault{GUID}: blobs DPAPI du Windows Vault%LocalAppData%GoogleChromeUser DataDefaultLocal State: clé AES Chrome chiffrée par DPAPI%LocalAppData%GoogleChromeUser DataDefaultLogin Data: base SQLite des mots de passe Chrome (chiffrés avec la clé AES)%LocalAppData%MicrosoftEdgeUser DataDefault: équivalent pour Microsoft Edge
DPAPI online vs offline : deux contextes d'exploitation distincts
La distinction entre exploitation online et offline est fondamentale pour comprendre les possibilités et les contraintes d'une attaque DPAPI selon le scénario de mission. C'est l'une des grilles d'analyse centrales présentées dans les travaux de Synacktiv.
Exploitation online (exécution de code sur la machine)
Quand le pentester dispose d'une exécution de code sur la machine cible (shell obtenu, accès interactif, implant), l'exploitation DPAPI est dans son mode le plus simple. Windows gère transparentement le déchiffrement des Master Keys via LSASS : les clés sont déjà disponibles en mémoire pour l'utilisateur connecté. L'attaquant peut :
- Invoquer
CryptUnprotectData()directement dans le contexte de l'utilisateur, ce que font les outils comme SharpDPAPI en modetriage. - Extraire les Master Keys depuis la mémoire LSASS via
sekurlsa::dpapi(Mimikatz) si les droits Local Admin sont obtenus. - Utiliser les API Windows légitimes pour déchiffrer les blobs sans toucher à LSASS, ce qui réduit la détection EDR.
Dans ce mode, la robustesse cryptographique de la DPAPI importe peu : les clés sont disponibles en clair en mémoire. La seule contrainte est d'avoir les droits suffisants.
Exploitation offline (image disque, forensique, pas d'exécution)
Le mode offline est plus contraint mais correspond à plusieurs scénarios réels en pentest et forensique :
- Analyse forensique d'une image disque acquise après incident.
- Accès à un partage réseau contenant des profils utilisateurs (
\serveurprofiles) sans session active sur les postes. - Exfiltration du profil utilisateur depuis un système sans pouvoir y exécuter de code (serveur de fichiers, partage de backup).
- Analyse post-mortem d'un poste déconnecté du domaine.
En mode offline, il faut reconstituer la chaîne de déchiffrement manuellement :
- Identifier les blobs DPAPI à déchiffrer dans le profil utilisateur.
- Extraire les fichiers Master Keys depuis
%AppData%MicrosoftProtect{SID}. - Obtenir la clé de déchiffrement via l'une de ces sources :
- Le mot de passe utilisateur en clair (si disponible via d'autres vecteurs).
- Le hash NT de l'utilisateur + son SID pour dériver la clé PBKDF2.
- La Domain Backup Key extraite du DC (si le domaine est accessible ou si elle a été collectée précédemment).
- Les hashes du CREDHIST si le mot de passe actuel n'est pas disponible mais qu'un ancien l'est.
- Déchiffrer les Master Keys avec l'outil adapté.
- Déchiffrer les blobs DPAPI avec les Master Keys obtenues.
La suite impacket (Python) permet de réaliser l'ensemble de cette chaîne depuis un poste Linux : dpapi.py backupkeys -t domaine/admin:mdp@DC01 pour extraire la backup key, dpapi.py masterkey -file masterkey -pvk backup.pvk pour déchiffrer la MK, dpapi.py credential -file credential_blob -key {masterkey_hex} pour déchiffrer le blob final. Cette approche est couramment utilisée lors de nos missions de pentest Active Directory depuis une machine d'attaque Linux sans nécessiter d'exécution de code sur les postes Windows.
La contrainte fondamentale du mode offline sans domaine
Synacktiv identifie dans ses travaux la contrainte la plus difficile à contourner : en mode offline hors domaine, sans mot de passe utilisateur ni Domain Backup Key, il est théoriquement impossible de déchiffrer les Master Keys modernes (Windows 7+, AES-256/SHA-512/5600 itérations PBKDF2). Le seul vecteur restant est le craquage du condensat NT ou SHA1 avec Hashcat, dont la viabilité dépend entièrement de la robustesse du mot de passe utilisateur. C'est pourquoi la politique de mots de passe utilisateur reste un contrôle de sécurité fondamental même dans les environnements avec DPAPI moderne.
Exploitation de la DPAPI en pentest : techniques et outils
L'exploitation de la DPAPI en pentest suit une progression logique liée au niveau de droits obtenu. Nos pentesters distinguent trois scénarios selon la position de l'attaquant dans le système.
Scénario 1 : Droits utilisateur standard sur le poste (contexte utilisateur actif)
Quand le pentester a un accès interactif au poste en tant qu'utilisateur courant (session active, shell obtenu via phishing ou exploitation applicative), Windows déchiffre les Master Keys transparentement via LSASS. Il est alors possible de déchiffrer directement tous les blobs DPAPI de cet utilisateur sans connaître son mot de passe, car les clés sont disponibles en mémoire.
Extraction des secrets navigateurs Chromium avec Mimikatz :
mimikatz # dpapi::chrome /in:"%localappdata%GoogleChromeUser DataDefaultLogin Data" /unprotect
Mimikatz invoque CryptUnprotectData() dans le contexte de l'utilisateur courant. Le résultat : tous les mots de passe sauvegardés dans Chrome en clair.
Extraction du Credential Manager :
mimikatz # vault::cred /patch
Ou via cmdkey et une approche plus discrète :
mimikatz # dpapi::cred /in:"%appdata%MicrosoftCredentials{GUID}" /unprotect
Avec SharpDPAPI (outil .NET plus discret que Mimikatz pour l'EDR evasion) :
SharpDPAPI.exe triage
SharpDPAPI énumère et déchiffre automatiquement l'ensemble des blobs DPAPI accessibles dans le contexte utilisateur courant : navigateurs, Credential Manager, certificats, secrets Wi-Fi.
Scénario 2 : Admin local sur le poste (droits élevés sur la machine)
Avec des droits Local Admin, le pentester peut accéder à la mémoire de LSASS pour extraire les Master Keys déjà déchiffrées en mémoire, ou utiliser le secret DPAPI_SYSTEM pour déchiffrer les secrets machine.
Extraction des Master Keys depuis la mémoire LSASS avec Mimikatz :
mimikatz # sekurlsa::dpapi
Cette commande extrait toutes les Master Keys actuellement chargées en mémoire pour tous les utilisateurs connectés. Si plusieurs utilisateurs ont des sessions actives (serveurs RDS, environnements de travail partagés), leurs Master Keys sont toutes extractibles d'un coup.
Extraction des secrets SYSTEM (tâches planifiées, services) :
mimikatz # lsadump::secrets
Retourne notamment la clé DPAPI_SYSTEM permettant de déchiffrer les blobs machine : credentials de tâches planifiées, mots de passe de services Windows, profils Wi-Fi stockés au niveau système.
Approche offline (sans EDR sur le poste) : copie des ruches de registre SYSTEM et SECURITY + des fichiers Master Keys du profil utilisateur, déchiffrement hors ligne avec impacket ou Mimikatz offline.
Scénario 3 : Domain Admin (le scénario le plus impactant)
Avec des droits Domain Admin, le pentester peut extraire la DPAPI Domain Backup Key depuis le contrôleur de domaine. Cette clé privée RSA-2048 permet de déchiffrer toutes les Master Keys de tous les utilisateurs du domaine, et donc tous leurs secrets DPAPI, même hors ligne.
Étape 1 : Extraction de la Domain Backup Key avec Mimikatz :
mimikatz # lsadump::backupkeys /system:dc01.domaine.local /export
Cette commande se connecte au DC via RPC, extrait la clé de sauvegarde DPAPI et l'exporte au format .pvk (Private Key file). L'opération est protégée par des ACL nécessitant les droits Domain Admin ou Backup Operators.
Étape 2 : Déchiffrement d'une Master Key utilisateur avec la backup key :
mimikatz # dpapi::masterkey /in:"C:UserscibleAppDataRoamingMicrosoftProtect{SID}{GUID}" /pvk:ntds_capi_0_backup.pvk
La Master Key déchiffrée est retournée en hexadécimal.
Étape 3 : Déchiffrement des blobs DPAPI de l'utilisateur :
mimikatz # dpapi::chrome /in:"C:UserscibleAppDataLocalGoogleChromeUser DataDefaultLogin Data" /masterkey:{clé hexadécimale}
Tous les mots de passe Chrome de l'utilisateur cible sont déchiffrés, y compris pour un utilisateur qui n'est pas connecté et dont la session n'est pas active.
Automatisation avec SharpDPAPI et DonPAPI :
SharpDPAPI automatise ce flux complet depuis un accès Domain Admin :
SharpDPAPI.exe backupkey [/server:DC01.domaine.local]SharpDPAPI.exe machinemasterkeys /pvk:backup.pvkSharpDPAPI.exe credentials /pvk:backup.pvk
DonPAPI (Python, depuis Linux) permet de faire de même à distance :
DonPAPI.py domaine/adminuser:Password@10.0.0.1
DonPAPI se connecte à chaque machine du domaine via SMB, collecte les blobs DPAPI et les déchiffre automatiquement en utilisant la Domain Backup Key. Le résultat est un inventaire complet des secrets DPAPI de tout le domaine en un seul passage.
DPAPI, Domain Admin et Active Directory : le chemin complet d'une compromission
La DPAPI n'est pas une vulnérabilité isolée. Elle s'inscrit dans le contexte plus large de la compromission Active Directory, où chaque escalade de privilège ouvre de nouvelles portes. Voici comment nos pentesters construisent le chemin complet.
Identifier le chemin vers Domain Admin avec BloodHound
Avant toute extraction DPAPI, il faut atteindre les droits Domain Admin ou un niveau de privilège équivalent. BloodHound est l'outil de référence pour cartographier les chemins d'escalade dans un Active Directory. Il collecte les relations entre objets AD (utilisateurs, groupes, GPO, ACL) et identifie les chemins les plus courts vers Domain Admin.
Lors d'un pentest Active Directory, nos pentesters enchaînent :
- Collecte BloodHound via SharpHound depuis un compte utilisateur standard.
- Analyse des chemins d'escalade : Kerberoasting, AS-REP Roasting, délégations Kerberos non contraintes, ACL abusables, GPO mal configurées.
- Exploitation du chemin le plus court vers Domain Admin ou équivalent (DCSync, WriteDACL sur le domaine, GenericAll sur le DC).
- Une fois Domain Admin obtenu : extraction de la DPAPI Domain Backup Key, DCSync pour les hashes NTDS, Golden Ticket si Kerberos est en jeu.
DCSync et DPAPI : deux faces de la même compromission
Avec les droits Domain Admin (ou les droits DCSync explicitement délégués), un pentester peut également exécuter une attaque DCSync pour extraire tous les hashes NTLM du domaine depuis NTDS.dit :
mimikatz # lsadump::dcsync /domain:domaine.local /all /csv
Ces hashes permettent le Pass-the-Hash vers n'importe quelle machine. Combinés avec l'extraction DPAPI, la compromission couvre à la fois les credentials stockés dans l'AD (hashes NTLM, Kerberos) et les credentials stockés sur les postes de travail (navigateurs, Credential Manager, certificats). La couverture est totale.
Cas particulier : DPAPI sans Domain Admin via les profils itinérants
Un attaquant ayant accès en lecture aux partages de profils itinérants (roaming profiles) d'un domaine peut collecter les fichiers Master Keys et les blobs DPAPI des utilisateurs. Combiné avec la Domain Backup Key obtenue ultérieurement, ou avec le craquage du mot de passe utilisateur via Hashcat, cette collecte offline peut être exploitée même sans session active de l'utilisateur cible.
DPAPI et persistance post-compromission
La Domain Backup Key a une propriété particulièrement redoutable pour la persistance : elle ne change jamais automatiquement, même après un changement de mot de passe Domain Admin, même après une réinitialisation de KRBTGT. Une fois extraite, elle reste valide tant que le domaine existe, à moins d'une procédure spécifique de remplacement de clé (une opération complexe qui implique de recréer toutes les Master Keys du domaine).
C'est pourquoi dans les scénarios de Red Team et de réponse à incident, la compromission de la Domain Backup Key est un indicateur de compromission persistante qui nécessite une réponse bien au-delà du simple reset de mots de passe.
DPAPI en mission PIIRATES : ce que nous trouvons chez nos clients
Cas 1 : Extraction de credentials cloud depuis un poste de développeur
Lors d'un pentest interne pour un éditeur SaaS, PIIRATES obtient un accès sur le poste d'un développeur via un email de phishing simulé. L'exécution de SharpDPAPI dans le contexte de la session active révèle les éléments suivants :
- Mots de passe Chrome : 47 credentials dont les accès AWS Management Console, GitHub, GitLab, Jira, Confluence, et la console d'administration de la plateforme SaaS.
- Credential Manager : token d'accès au serveur de build Jenkins, credentials du compte de service déploiement, accès SMB à 3 serveurs de fichiers internes.
- Certificat de signature de code : clé privée du certificat utilisé pour signer les releases de l'application.
Impact démontré : compromission de la chaîne de build, possibilité d'injecter du code malveillant dans les releases signées de l'application, accès à l'ensemble de l'infrastructure cloud AWS. Tout cela depuis un seul accès utilisateur standard sur un poste de développeur.
Cas 2 : Domain Backup Key extraite depuis un Active Directory d'une ETI industrielle
Dans le cadre d'un pentest boite blanche sur un groupe industriel de 800 utilisateurs, PIIRATES cartographie le domaine avec BloodHound et identifie un chemin vers Domain Admin via un Kerberoasting sur un compte de service avec une délégation non contrainte. Durée pour atteindre Domain Admin depuis un compte utilisateur standard : 4h30.
Une fois Domain Admin obtenu :
- Extraction de la DPAPI Domain Backup Key via
lsadump::backupkeys. - DCSync sur NTDS.dit : extraction des hashes NTLM de 847 comptes utilisateurs et 23 comptes de service.
- Utilisation de DonPAPI pour déchiffrer les blobs DPAPI de 12 postes critiques identifiés (postes des DSI, RSSI, directeurs financier et général).
Résultats de l'extraction DPAPI avec la backup key : credentials des applications bancaires et de trésorerie, tokens Microsoft 365 des comptes dirigeants, accès au système de supervision industrielle SCADA via des credentials Chrome, mots de passe de la connexion VPN de maintenance prestataires. L'impact business est documenté et présenté au COMEX dans le rapport de pentest.
Cas 3 : Secrets DPAPI_SYSTEM sur un serveur de fichiers
Sur un pentest infrastructure interne, PIIRATES identifie un serveur de fichiers Windows Server 2019 avec des droits Local Admin obtenus via un Pass-the-Hash sur un compte de service partagé. L'extraction des LSA Secrets via lsadump::secrets retourne la DPAPI_SYSTEM key et révèle les credentials des tâches planifiées du serveur : un compte de service avec des droits de lecture/écriture sur 4 partages réseau sensibles, dont le partage de sauvegarde contenant les fichiers de configuration des serveurs applicatifs avec leurs credentials de bases de données en clair.
Ces trois cas illustrent un pattern constant : la DPAPI est rarement la vulnérabilité initiale. Elle est la récompense post-exploitation qui transforme une compromission technique en impact business concret et démontrable.
Détection et défense contre l'exploitation de la DPAPI
La DPAPI est un mécanisme légitime : sa protection repose sur la sécurité du domaine et des postes, pas sur la confidentialité du mécanisme lui-même. La défense contre son exploitation passe par plusieurs axes.
Durcissement de l'Active Directory
L'extraction de la Domain Backup Key nécessite des droits élevés. Réduire l'exposition de la DPAPI passe d'abord par durcir l'AD pour limiter les chemins vers Domain Admin :
- Kerberoasting : utiliser des mots de passe longs (25+ caractères) sur tous les comptes de service, ou migrer vers des MSA/GMSA (Managed Service Accounts) qui gèrent automatiquement des mots de passe complexes sans les stocker en clair.
- Délégations Kerberos : auditer et supprimer toutes les délégations non contraintes (Unconstrained Delegation). Utiliser la délégation contrainte basée sur les ressources (RBCD) uniquement quand nécessaire.
- ACL abusables : auditer régulièrement avec BloodHound les permissions excessives sur les objets AD (WriteDACL, GenericAll, GenericWrite sur des objets sensibles).
- Tier Model : implémenter le modèle de séparation par niveaux (Tier 0/1/2) qui isole les comptes d'administration du domaine des postes de travail.
Détection de l'extraction de la Domain Backup Key
L'accès à la DPAPI Domain Backup Key génère des événements Windows auditables. Sur le DC, surveiller :
- Event ID 4662 : accès à un objet AD. Filtrer sur l'objet
CN=BCKUPKEY_PetCN=BCKUPKEY_PREFERRED. Ces deux objets dans la partition de configuration contiennent les clés de sauvegarde DPAPI. Un accès à ces objets hors procédure de récupération normale est suspect. - Event ID 4776 (NTLM) combiné à une connexion depuis un compte Domain Admin vers le DC hors fenêtre de maintenance connue.
- Règles Sigma MITRE ATT&CK T1555.004 (Credentials from Password Stores: Windows Credential Manager) pour la détection via SIEM.
Protection des sessions LSASS
L'extraction des Master Keys en mémoire passe par LSASS. Les mesures de protection incluent :
- Activer Credential Guard (Windows 10/2016+) : isole LSASS dans une VM légère basée sur Hyper-V, rendant l'accès depuis le niveau OS normal impossible même avec des droits SYSTEM.
- Activer la protection LSASS via PPL (Protected Process Light) : empêche l'injection et la lecture de mémoire LSASS par des processus non signés Microsoft.
- Désactiver WDigest (
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential = 0) pour éviter le stockage des mots de passe en clair dans LSASS.
Réduction des secrets stockés dans le Credential Manager et les navigateurs
La meilleure protection contre l'extraction DPAPI des navigateurs est de réduire ce qui y est stocké :
- Déployer un gestionnaire de mots de passe d'entreprise centralisé (Keepass, CyberArk, 1Password Business) plutôt que les navigateurs natifs pour les comptes professionnels sensibles.
- Interdire via GPO le stockage de mots de passe dans les navigateurs sur les postes d'administration.
- Utiliser des PAW (Privileged Access Workstations) dédiés aux tâches d'administration, physiquement séparés des postes de travail courants.
Que faire si la Domain Backup Key est compromise ?
C'est le scénario le plus difficile à gérer. La DPAPI Domain Backup Key ne se renouvelle pas automatiquement. Sa compromission signifie que tous les secrets DPAPI de tous les utilisateurs peuvent être déchiffrés indéfiniment, même après changement des mots de passe, tant que l'attaquant conserve la clé exportée.
Les actions de remédiation impliquent :
- Générer une nouvelle Domain Backup Key via
dpapi.py(impacket) ou les outils DSInternals. - Invalider l'ancienne clé dans l'AD.
- Forcer tous les utilisateurs à renouveler leurs Master Keys (implique en pratique un changement de mot de passe pour tous).
- Révoquer et renouveler tous les certificats utilisateurs protégés par DPAPI.
Cette procédure est complexe et potentiellement disruptive. Elle illustre pourquoi la compromission de Domain Admin dans un environnement Windows doit être traitée comme un incident majeur nécessitant une réponse complète, et non comme un simple changement de mot de passe.
Indépendance totale
Expertise offensive
Professionnalisme
Local State. Cette clé AES chiffre les données sensibles dans la base SQLite Login Data (mots de passe), Cookies (dont les cookies de session et tokens d'authentification), Web Data (données de formulaires) et l'historique. L'extraction DPAPI du fichier Local State donne accès à la clé AES, ce qui permet de déchiffrer l'ensemble de ces données. Lors de nos missions de pentest interne, c'est systématiquement l'un des vecteurs les plus riches en credentials récupérés.
%AppData%MicrosoftProtectCREDHIST. Il conserve les condensats NT et SHA1 de tous les anciens mots de passe de l'utilisateur, enchaînés de sorte que chaque condensat est chiffré par le précédent. Son rôle légitime est de permettre le déchiffrement des Master Keys créées sous d'anciens mots de passe lors d'un changement. Pour un attaquant, il représente un historique de mots de passe exploitable : les condensats extraits peuvent être soumis à Hashcat, et des anciens mots de passe souvent plus faibles peuvent être retrouvés même si le mot de passe actuel est robuste. Lors de nos missions forensiques et de pentest interne, le CREDHIST est systématiquement collecté avec les Master Keys.
dwDomainKeySize dans l'en-tête d'un fichier Master Key indique la taille du bloc chiffré par la Domain Backup Key du domaine. Sa valeur non nulle confirme deux choses : la machine est jointe à un domaine Active Directory, et il existe une copie de la Master Key chiffrée par la clé RSA-2048 stockée sur le DC. Pour un pentester ayant obtenu les droits Domain Admin, ce champ signifie que toutes les Master Keys des machines du domaine peuvent être déchiffrées sans connaître le mot de passe des utilisateurs, simplement en possédant la Domain Backup Key. Ce champ est en clair dans le fichier, lisible sans déchiffrement préalable.
Nos coordonnées
- 04 28 49 00 25
- contact@piirates.fr
- 6 Rue Denis Papin
07130 Saint Peray
Envoyez nous un ping
DPAPI (Data Protection API) : architecture, Domain Backup Key, exploitation avec Mimikatz et SharpDPAPI en pentest Active Directory, cas terrain PIIRATES et mesures de défense complètes.
