Sous Unix, le compte administrateur est simple à trouver, c'est le compte root. Sous Windows, c'est plus complexe. Le nom est souvent internationalisé: Administrator, Administrateur,... Pour le reconnaître, il faut chercher un compte dont le RID vaut 500.
Comme les structures du fichier SAM ont été rapidement mises à jour, Microsoft a décidé de chiffrer par du RC4, au sein même du fichier, les mots de passe cryptés. On peut remarquer que les structures des fichiers de mots de passe Unix sont publiques et cela n'a jamais été considéré comme un problème. Les mots de passe sont de toute façon déjà cryptés de manière irréversible, il s'agit là uniquement d'un codage réversible, une couche de brouillard. Depuis le service pack 3 de NT 4, l'utilitaire Syskey est fourni dans pour réaliser ce codage. Depuis Windows 2000, ce chiffrement est activé par défaut. La clé de codage est
soit présente dans le fichier lui-même en clair, autrement dit, il n'y a aucune protection,
soit la clé est stockée dans le fichier SAM mais protégée par une passphrase, un mot de passe à rallonge. L'administrateur doit entrer ce mot de passe au démarrage de l'ordinateur pour le débloquer.
soit l'administrateur utilise une disquette pour la stocker auquel cas, il faut l'utiliser à chaque démarrage de la machine.
Dans la base de registre, la valeur stockée selon les versions de Windows dans les clés
\SAM\Domains\Account\F, Security\Policy\SecretEncryptionKey ou, HKLM\System\CurrentControlSet\Control\Lsa reproduit ces trois possibilités:
1 - clé dans le registre
2 - clé protégée par une passphrase
3 - clé sur disquette
La possibilité 1 n'offre aucune sécurité, cela revient à mettre une serrure en laissant la clé dessus. Les deux autres empêchent les attaques directes des mot de passe LANMAN et NTML.
Des attaques plus complexes sont toujours possibles. L'algorithme de chiffrement RC4 est un algorithme de chiffrement par flux utilisant le XOR. Or dans ce type d'algorithme, le flux de chiffrement ne doit pas être réutilisé, il ne faut pas chiffrer indépendamment les uns des autres des blocs de données. Bindview s'est rendu compte en 1999 que Microsoft l'utilisait (Il l'utilise toujours) pour chiffrer utilisateur par utilisateur le mot de passe LANMAN puis le mot de passe NTLM. Le flux de chiffrement généré à partir de la clé RC4 est donc réutilisé! Cela ouvre donc la voie à des attaques cryptographiques. La mauvaise implémentation de cet algorithme permet de vérifier la validité d'un mot de passe d'un utilisateur. Si le XOR produit par les deux mots de passe chiffrés en RC4 lus dans le fichier est égale au XOR des mots de passe Lanman et NTLM, bingo, le mot de passe est trouvé!
Si cette relation est vérifiée, le mot de passe est trouvé
→ NTLM ? NTLM chiffré
Mot de passe > Xor = Xor
potentiel
→ LANMAN LANMAN chiffré
Ainsi des attaques sont toujours réalisables même si la clé RC4 est inconnue. C'est juste un peu plus lent que de s'attaquer au chiffrement NTLM directement quand cela était possible (absence de syskey ou clé syskey connue).