Part 3 : Les empreintes des mots de passe
Dans cette partie, nous abordons la donnée la plus sensible qui est stockée dans le NTDS : les empreintes cryptographiques des mots de passe utilisateurs (appelées également hash ou encore condensats des mots de passe).
Dans l’article précédent Part-2 – La Datatable, nous avons listé l’ensemble des colonnes de la datatable en fonction des différents niveaux fonctionnels d’Active Directory (cf. https://github.com/xmco/ntds_extract/tree/main/Part-2-La-Datatable)
Au sein des colonnes ATTk589879 et ATTk589914, nous allons retrouver les empreintes cryptographiques des mots de passe utilisateurs sous deux formats : LM (LAN Manager) et NT (NT hash).
Les attaques sur les empreintes LM et NT peuvent être classées en plusieurs catégories, notamment :
1 – Attaques par force brute : Ces attaques consistent à essayer toutes les combinaisons possibles de caractères jusqu’à trouver celle qui correspond à l’empreinte cryptographique du mot de passe. Des outils tels que Hashcat et John the Ripper sont couramment utilisés ;
2 – Attaques par dictionnaire : Les attaques par dictionnaire utilisent un ensemble défini de mots et de phrases, souvent tirés de listes de mots de passe courants ou de dictionnaires, pour tenter de deviner les mots de passe correspondants aux empreintes cryptographiques LM et NT. Les attaquants peuvent également utiliser des variations de ces mots en appliquant des transformations simples, telles que la substitution de caractères ou l’ajout de préfixes et de suffixes. Les outils John the Ripper ou Hashcat sont également utilisés ;
3 – Attaques par Rainbow Tables : Les tables « arc-en-ciel » sont des structures de données précalculées qui permettent de retrouver rapidement un mot de passe à partir de son empreinte cryptographique. Celles-ci sont plus rapides que les attaques par force brute et par dictionnaire, car elles tirent parti de l’espace mémoire pour réduire le temps de recherche. Des outils tels que RainbowCrack et Ophcrack sont populaires pour effectuer ce type d’attaques.
Nous réalisons systématiquement ces trois attaques lors de nos audits de mot de passe menés au travers de notre service managé IAMBuster.
Le format LM
Le format LM est le plus ancien et est considéré obsolète par Microsoft depuis 2006 et la sortie de Windows Vista. En effet, la taille du mot de passe ne peut pas réellement dépasser 14 caractères et n’est pas sensible à la casse (les minuscules sont converties en majuscules). De plus, par construction, il est faible face aux attaques par cryptanalyse qui nécessitent uniquement de bruteforcer deux mots de passe de 7 caractères en majuscules. Voici ci-dessous un schéma qui illustre la création d’un hash LM.
1 – Conversion du mot de passe en majuscule
2 – Ajout de bourrage si la longueur du mot de passe est inférieure à 14 caractères (caractère NULL)
3 – Séparation du mot de passe en 2 mots de passe de 7 caractères (le mot de passe est tronqué à 14 caractères)
4 – Application de l’algorithme DES pour chiffrer la chaine de caractères arbitraires « KGS!@#$% » en utilisant les 2 mots de passe comme clés
5 – Concaténation des deux résultats pour obtenir le hash LM
Un attaquant ayant récupéré des hash LM pourra récupérer le mot de passe originel via différents types d’attaque pouvant prendre quelques minutes à quelques heures. L’une d’entre elle repose sur un compromis temps / mémoire, il s’agit de table de résultats précalculés, appelée Rainbow Tables.
Depuis Windows Vista et Windows Serveur 2008, la génération du format LM est désactivée et une GPO est également disponible. Le mot de passe est stocké uniquement au format NT. Lorsqu’un compte utilisateur dispose d’une empreinte LM associé à un mot de passe non vide, il est nécessaire de s’assurer que le stockage au format LM est bien désactivé via la GPO(2) ‘Sécurité réseau : ne pas stocker de valeurs de hachage de niveau Lan Manager’ et surtout de changer le mot de passe après application.
Bien qu’obsolète et non généré par défaut depuis plus de 15 ans, les empreintes sous format LM sont encore utilisés dans beaucoup d’entreprises (entre 1 et 3% des mots de passe d’après nos audits IAMBuster). En effet, la suppression de l’empreinte au format LM nécessite de changer le mot de passe après l’application de la GPO. Il est donc encore courant de voir de vieux comptes de services dont le mot de passe n’a jamais été changé, qui possèdent encore leur empreinte LM.
Le format NT
Le format NT est apparu en 1997 avec Windows NT 4 Service Pack 3 et corrige les défauts du hash LM :
- Le codage passe en Unicode UCS-2 qui augmente leur potentielle complexité (chaque caractère est codé sur deux octets)
- La longueur de la taille supportée des mots de passe augmentent de 14 à 255 caractères
- L’algorithme DES est abandonné au profit de MD4
Celui-ci est bien plus résistant aux attaques mentionnée en introduction.
Voici ci-dessous un tableau qui montre quelques exemples des deux formats de stockage de mots de passe.
| Mot de passe | Hash LM | Hash NT |
|---|---|---|
| jedimaster | 1934425df90e03b45acc35a98e0ae6f9 | 454da4021f7b054cbdeb3885ad8d1b1c |
| wcsRb0lePdhS | 52f2eadda0a87897b214e2be51e01fad | fb1588d471d3f3fb8cee550b916d2d04 |
| (vide) | aad3b435b51404eeaad3b435b51404ee | 31d6cfe0d16ae931b73c59d7e0c089c0 |
Note : Il est très fréquent d’observer de nombreux comptes utilisateurs ayant un hashLM et un hashNT vides. Ces comptes sont généralement issus d’un autre domaine ayant une relation d’approbation. Leurs empreintes de mots de passe sont en réalité stockées dans la base NTDS d’un autre Active Directory.
Un autre point intéressant est l’absence de sel dans la génération des empreintes. Le sel est une chaine de caractères aléatoires ajoutée lors du processus de génération permettant de rendre unique une empreinte. Ainsi, avec le sel, deux mots de passe identiques auront une empreinte générée différente. En revanche, cette absence de sel permet notamment de connaitre le nombre de mots de passe identiques en comparant les empreintes sans avoir besoin de connaitre la valeur en clair.
Note : La comparaison des empreintes permet d’identifier facilement des utilisateurs qui, lorsqu’ils ont plusieurs comptes pour différents usages, réutilisent le même mot de passe sur leurs comptes. Un exemple courant est un administrateur qui utilise le même mot de passe pour son compte bureautique et son compte d’administration privilégié.
Extraction dans le NTDS
Dans le NTDS, les champs correspondants aux empreintes cryptographiques sont les suivants :
| Hash | Colonne | Nom LDAP |
|---|---|---|
| LM | ATTk589879 | dBCSPwd |
| NT | ATTk589914 | unicodePwd |
Les hash stockés dans le NTDS sont cependant chiffrés et non accessibles directement comme d’autres attributs tels que le login utilisateur ou sa description.
Afin d’exploiter les empreintes des utilisateurs, il est nécessaire de les déchiffrer avec la clé PEK (Password Encryption Key). Cette dernière est utilisée pour chiffrer les données « sensibles » du NTDS et a la même valeur pour l’ensemble du domaine. Ainsi, la clé utilisée pour le NTDS du contrôleur de domaine primaire sera identique à la clé du domaine secondaire.
La PEK est également stockée sous forme chiffrée dans le NTDS lui-même (colonne ATTk590689). Pour la déchiffrer, la BOOTKEY, stockée dans la ruche SYSTEM (C:\Windows\System32\config\SYSTEM) sera nécessaire. Sans la ruche SYSTEM, vous ne pourrez pas accéder aux données chiffrées contenues dans le NTDS tels que les hashs des mots de passe, des hashs des mots de passe historiques et d’autres attributs additionnels pouvant contenir des secrets (supplementalCredentials).
Note : Lorsqu’une sauvegarde du NTDS est réalisée avec l’utilitaire NTDSUtil, la ruche SYSTEM est toujours exportée avec.
Microsoft a mis en place 3 couches de chiffrements pour protéger hash NT et LM contenu dans le NTDS. Voici donc les 3 étapes :
1 – Déchiffrer la PEK avec la BOOTKEY (RC4 – couche 1)
2 – Déchiffrer le hash une première fois avec la PEK et RC4 (couche 2)
3 – Déchiffrer une seconde fois le hash avec l’algorithme DES et une clé basée sur le RID(3) de l’utilisateur (couche 3)
Voici quelques outils disponibles permettant d’effectuer l’opération :
- Le module Get-ADDBAccount de DSInternals : https://github.com/MichaelGrafnetter/DSInternals/
- Le module Secretsdump d’Impacket (https://github.com/fortra/impacket)
Exemple du processus d’extraction des empreintes utilisateurs avec le module d’Impacket :
1 – La BOOTKEY est extraite depuis la ruche système fournie
2 – Les empreintes des utilisateurs sont récupérées (colonne ATTk589879 et ATTk589914 de chaque objet utilisateurs)
3 – Recherche de la PEK (objet avec la colonne ATTk590689 non vide)
4 – La PEK est déchiffrée avec la BOOTKEY (couche 1)
5 – Déchiffrement des hashes utilisateurs avec la PEK (couche 2 et couche 3)
Exploitation des mots de passe
Comme évoqué précédemment, un mot de passe utilisateur sous un format LM ne vous résistera pas longtemps dû à sa conception. En revanche, le format NT, même après 20 ans, résiste bien aux attaques de cryptanalyse par force brute, à partir du moment où le mot de passe est suffisamment complexe. Ainsi, un mot de passe dérivé du login, dérivé du nom de l’entreprise ou présent dans un dictionnaire sur Internet ne résistera pas longtemps aux différentes attaques de cassage pour retrouver sa valeur en clair. En revanche, un mot de passe de plus de 12 caractères aléatoires et variés (caractères spéciaux, chiffres, etc.) sera très résistant.
Bien qu’un mot de passe robuste sous un format NT ne puisse pas être cassé dans un temps raisonnable, un attaquant peut se passer de cette étape. En effet, au travers du protocole d’authentification réseau NTLM, encore omniprésent dans les environnements Active Directory, seule l’empreinte du mot de passe utilisateur est nécessaire pour se connecter sur un service distant tel qu’SMB. Cette technique, découverte en 1997 (mais réellement exploitée 10 ans plus tard) a été baptisée « Pass-The-Hash » et fonctionne toujours aujourd’hui.
Nous reviendrons sur les empreintes des mots de passe dans d’autres parties de la série (compte de service krbtgt, tickets Kerberos, etc.).
(1) https://ww2.ac-poitiers.fr/ecolgt/sites/ecolgt/IMG/pdf/securite_relatives_aux_mdp.pdf
(2) Les stratégies de groupe (en anglais, Group Policy ou GP) permettent la gestion centralisée des ordinateurs et des utilisateurs dans un environnement Active Directory.
(3) Le RID (relative ID) est une partie du Security Identifier (SID) qui est un identifiant unique et immuable de sécurité alphanumérique assigné dans l’Active Directory pour chaque système, utilisateur ou objet.
