Casser les identifiants de domaine en cache (DCC2 / MS-Cache v2)
Extrayez les hash DCC2 d'un hôte joint au domaine avec secretsdump, cassez-les avec hashcat mode 2100, et comprenez pourquoi MS-Cache v2 est lent par conception.
Vous avez décroché l'admin local sur un portable. Aucun contrôleur de domaine à portée, aucun identifiant de domaine propre en mémoire, juste un poste de travail hors du réseau de l'entreprise depuis une semaine. L'utilisateur s'est quand même connecté pendant cette semaine. Alors où Windows a-t-il vérifié le mot de passe ?
Les identifiants de domaine en cache. DCC2. Ils dorment dans le registre, et sur la bonne mission ils sont le seul point d'entrée que vous ayez vers le domaine.
Ce que c'est et où ça vit
Quand une machine jointe au domaine ne peut pas joindre un DC, elle doit quand même laisser l'utilisateur du domaine se connecter. Windows met donc en cache un vérificateur de la dernière connexion réussie et valide contre celui-ci hors ligne. Par défaut il en garde dix.
Ce vérificateur, c'est MS-Cache v2, aussi appelé DCC2 (Domain Cached Credentials version 2). Il vit dans le registre sous HKLM\SECURITY\Cache, verrouillé sous SYSTEM et illisible pour un simple admin. Il faut être SYSTEM, ou bien extraire la ruche hors ligne.
La propriété importante : le DCC2 est une dérivation à sens unique. Ce n'est pas le mot de passe, pas le hash NT que vous pouvez passer, et il ne touche jamais le réseau. La machine le calcule localement et compare. Donc votre seule voie, c'est de le casser.
Les sortir
Le secretsdump.py d'Impacket les lit directement si vous le pointez sur les ruches locales. Récupérez SYSTEM et SECURITY (depuis une machine vivante avec reg save, ou depuis une image disque) et lancez-le en mode LOCAL :
secretsdump.py -security SECURITY -system SYSTEM LOCAL
Les identifiants en cache sortent dans un bloc clairement étiqueté :
[*] Dumping cached domain logon information (domain/username:hash)
CONTOSO.LOCAL/jdoe:$DCC2$10240#jdoe#a1b2c3d4e5f6...
mimikatz le fait en direct depuis SYSTEM avec lsadump::cache. Mêmes données, même format. Dans les deux cas vous obtenez le hash DCC2 :
$DCC2$10240#user#hexdigest
Le 10240 est le compte d'itérations. Le user est le nom de compte intégré à la dérivation, et c'est pour ça que le DCC2 ne peut pas partager une table précalculée comme les hash non salés. Le nom d'utilisateur joue de fait le rôle du sel.
Le casser : mode 2100, et de la patience
Donnez la chaîne $DCC2$... entière à hashcat mode 2100 :
hashcat -m 2100 dcc2.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule
John l'appelle mscash2 :
john --format=mscash2 --wordlist=rockyou.txt dcc2.txt
Maintenant l'avertissement. Ne traitez pas ça comme du NTLM. Le DCC2 est du PBKDF2-HMAC-SHA1 enroulé autour du hash NTLM, avec 10240 itérations. Ce compte d'itérations existe précisément pour être lent, et ça marche. Là où le NTLM brut casse à des dizaines de milliards par seconde, le DCC2 sur le même GPU tient dans les quelques centaines de milliers par seconde. C'est cinq ordres de grandeur plus lent.
L'instinct de force brute est donc faux ici. Une passe de 14 millions de mots avec un gros jeu de règles qui finit en quelques secondes contre du NTLM peut tourner des heures contre du DCC2, et une attaque par masque au-delà d'une poignée de caractères est perdue d'avance. On ne balance pas tout l'arsenal sur du DCC2.
On y va au scalpel. Des listes ciblées. Le nom de l'entreprise avec saisons et années, le motif de réinitialisation du support, tout ce que vous avez déjà cassé ailleurs dans le domaine, malaxé avec un jeu de règles resserré. Toute la discipline du bon choix de dictionnaire et de règles compte bien plus sur du DCC2 que sur un hash rapide, parce que chaque candidat gaspillé coûte du vrai temps GPU. Si vous ne savez même pas à quel mode correspond un hash, la recherche de mode hashcat tranche avant que vous ne gaspilliez une passe.
Quand vous le cassez, vous avez le clair. C'est la seule sortie exploitable. Il n'y a pas de pass-the-DCC2.
Quand c'est le bon coup
Le DCC2 brille dans un cas précis : vous avez l'admin local ou SYSTEM sur un terminal, mais aucune liaison vers un DC ni d'autres identifiants de domaine. Un portable volé ou saisi. Un poste compromis resté hors ligne. Une image forensique.
Dans ces cas, les entrées en cache sont votre pont du local vers le domaine. Cassez-en une et vous avez le mot de passe d'un vrai utilisateur du domaine, que vous pouvez alors pulvériser, réutiliser ou exploiter pour grimper. C'est lent, donc on s'y engage seulement quand les voies plus rapides (dump LSASS, tickets, capture NetNTLMv2) sont fermées.
Le point de vue du défenseur
Deux leviers, tous deux frustes et tous deux efficaces.
Limitez le nombre de connexions en cache. La stratégie Ouverture de session interactive : nombre d'ouvertures de session précédentes à mettre en cache vaut 10 par défaut. Sur les serveurs et les hôtes à forte valeur qui n'ont jamais besoin de connexion hors ligne, mettez-la à 0 ou 1. Moins de vérificateurs en cache, c'est moins de hash qu'un attaquant peut emporter, et sur un serveur le scénario de connexion hors ligne justifie rarement l'exposition.
Mais la vraie défense est la même que pour tout le reste : la robustesse des mots de passe. La lenteur du DCC2 ne fait que gagner du temps. Un utilisateur avec Ete2026! tombe sous une liste ciblée malgré 10240 itérations, parce que le candidat est dans les mille premiers essais. Un utilisateur avec une longue phrase de passe aléatoire survit, parce que la lenteur multipliée par un espace de clés énorme devient géologique. Le compte d'itérations est un multiplicateur de force sur un mot de passe solide et presque inutile sur un faible. L'exposition du hash en cache est donc réelle, mais c'est la politique de mots de passe qui décide si elle se transforme un jour en identifiant de domaine.