Comment les informations d'identification Windows mises en cache sont-elles stockées sur la machine locale?
Comment les informations d'identification de domaine Active Directory mises en cache sont-elles stockées sur un client Windows? Sont-ils stockés dans la base de données SAM locale, les rendant ainsi sensibles aux mêmes attaques de table Rainbow que les comptes d'utilisateurs locaux sont susceptibles, ou sont-ils stockés différemment? Notez que je me rends compte qu'ils sont salés et hachés, afin de ne pas être stockés en texte brut, mais sont-ils hachés de la même manière que les comptes locaux et sont-ils stockés au même endroit?
Je me rends compte qu'au minimum, ils sont susceptibles d'être attaqués par force brute, mais c'est une bien meilleure situation que d'être vulnérable aux tables Rainbow en cas de vol de machine.
"Informations d'identification mises en cache"
Les informations d'identification mises en cache pour un domaine AD sont en fait des doubles hachages salés du mot de passe et stockées dans la ruche HKLM\Security. L'emplacement du fichier de la ruche est: %systemroot%\System32\config\SECURITY
Seul l'utilisateur "système" a accès aux clés de registre:HKLM\Security\Cache\NL$n où n est un index 1 du nombre maximal d'informations d'identification mises en cache.
Sensibilité aux attaques
WinNT à WinXP a utilisé des hachages "Lan Manager" pour les comptes locaux, qui sont facilement cassés sur le matériel moderne. Le cracking prend généralement plusieurs minutes (j'ai récemment fait 3 mots de passe en 00:08:06) avec juste un ordinateur de bureau "normal". Les hachages Lan Manager ne sont pas salés, il existe donc également des tables Rainbow accessibles au public.
Vista et versions ultérieures utilisent des hachages NT pour les comptes locaux. Windows 2000 et versions ultérieures utilisent également des hachages NT pour les comptes domaine. Les hachages NT sont des hachages salés double MD4. Le sel par entrée empêche l'utilisation des tables Rainbow, mais MD4 peut être exécuté très rapidement sur du matériel moderne: environ 6 années de calcul pour un mot de passe 60 bits. Avec de la chance et un cluster de 6 GPU, un pirate peut casser ce type de mot de passe en ~ 6 mois. En prenant cela dans le cloud, environ 35000 $ sur le processeur graphique Amazon EC2 - selon la disponibilité, cela pourrait prendre des heures.
Les informations d'identification ne sont pas réellement mises en cache sur la machine locale. Voir cet extrait de MS:
Sécurité des informations d'identification de domaine mises en cache
Le terme informations d'identification mises en cache ne décrit pas avec précision la façon dont Windows met en cache les informations d'ouverture de session pour les ouvertures de session de domaine. Dans Windows 2000 et dans les versions ultérieures de Windows, le nom d'utilisateur et le mot de passe ne sont pas mis en cache. Au lieu de cela, le système stocke un vérificateur crypté du mot de passe. Ce vérificateur est un hachage MD4 salé qui est calculé deux fois. Le double calcul fait effectivement du vérificateur un hachage du hachage du mot de passe utilisateur. Ce comportement est différent du comportement de Microsoft Windows NT 4.0 et des versions antérieures de Windows NT.
Ils sont gérés par Credential Manager, pour lequel il existe une API Credential Manager. Les hachages salés sont stockés de manière quelque peu sécurisée sur le disque et accessibles via HKLM\Security. (Qui n'est accessible que par LocalSystem par défaut, mais est facile à contourner, par exemple, par psexec -i -s regedit.exe.)
Cependant, sur un système Windows en cours d'exécution, la situation est plus grave, car les informations d'identification récemment utilisées peuvent être obtenues et facilement inversées en texte brut en connectant un DLL à Lsass. (Voir Mimikatz.)
Donc oui, vous trouverez une sorte de hachage (ou hachage d'un hachage, ou "vérificateur" ou tout ce que vous voulez appeler) dans HKLM\Security\Cache sur le client. Mais je ne pense pas qu'il existe un moyen possible d'attaquer le hachage sur le disque. Ce n'est pas le même type de hachage NTLM qui est attaquable.