Avant l’existence du niveau fonctionnel Windows Server 2003, lorsqu’un utilisateur tentait de s’authentifier à l’aide d’un mot de passe n’étant pas le sien, son nombre de tentative d’authentification échouée (représenté par l’attribut « badPwdCount« ) se voyait automatiquement incrémentée.

Depuis l’introduction du niveau fonctionnel Windows Server 2003, lorsqu’un utilisateur essaie de s’authentifier à l’aide d’un de ses deux précédents mots de passe, l’attribut « badPwdCount » n’est plus incrémenté. D’une part, cette fonctionnalité permet de limiter les verrouillages de comptes utilisateurs dues à des tentatives de connexion émises par des applications suite à une modification de mot de passe non répercutée sur ces dernières (Exchange, Skype, etc.).  D’autre part, cette évolution a pour objectif de limiter le nombre de verrouillages de comptes utilisateur et ainsi les interventions futiles des équipes de support. En effet, les mauvaises tentatives d’authentification émanant d’utilisateurs légitimes sont plus susceptibles d’être la cause de tentatives d’authentification à l’aide de mots de passe précédemment valides.

Différents paramètres interviennent au sein du mécanisme de verrouillage de compte utilisateur :

La majeure partie de ces attributs disposent d’un nom autoporteur. Néanmoins, il convient de préciser que la fenêtre d’observation du verrouillage (« lockoutObservationWindow« ) ne représente pas la durée pendant laquelle les tentatives d’authentification infructueuses doivent avoir lieu pour verrouiller un compte, ni le temps nécessaire à la réinitialisation de l’attribut « badPwdCount » si aucune tentative infructueuse de connexion n’est conduite. Au contraire, c’est la durée nécessaire à la réinitialisation de l’attribut « badPwdCount » depuis la dernière mise à jour de l’attribut « badPasswordTime« .

Par ailleurs, les attributs « badPwdCount » et « badPasswordTime » ne sont pas répliqués au sein du domaine mais seulement sauvegardés sur le contrôleur de domaine sur lequel l’utilisateur essaye de s’authentifier. Néanmoins, ces attributs sont synchronisés sur le contrôleur de domaine disposant du rôle FSMO d’émulateur de contrôleur principal de domaine (ou PDCe).

Seuls les protocoles Kerberos et NTLM utilisés lors d’une authentification via mot de passe ou Smart Card bénéficient de cette fonctionnalité (sous réserve que le PDCe soit joignable par le contrôleur de domaine gérant la demande d’authentification).

Du point de vue d’un attaquant, cette nouvelle fonctionnalité offre la possibilité d’attaquer non seulement le mot de passe actuel d’un utilisateur mais aussi ses deux précédents via la vérification de l’incrémentation de l’attribut « badPwdCount » sur le PDCe suite à une tentative d’authentification. En effet, si la tentative d’authentification échoue mais que l’attribut « badPwdCount » ne se voit pas incrémenter, alors un mot de passe précédemment valide vient d’être découvert.

La découverte d’un mot de passe précédemment utilisé par un utilisateur permet à un attaquant d’identifier une éventuelle structure de création de mot de passe employée par cet utilisateur, pouvant parfois conduire à la découverte de son mot de passe actuel.

D’autre part, il est fréquent que des utilisateurs réutilisent leurs anciens mots de passe ; un précédent mot de passe découvert pourrait donc être réemployé par la suite par ce même utilisateur.

Enfin, les anciens mots de passe de domaine découverts peuvent parfois être encore valides sur certains applicatifs se reposant sur un référentiel n’imposant aucun changement de mot de passe.

Un script a été développé dans le but d’identifier, outre les mots de passe actuels des utilisateurs d’un domaine Windows, les mots de passe présents dans les historiques des mots de passe utilisateur :

Le schéma de fonctionnement de ce dernier est le suivant :

• Récupération de la liste des utilisateurs du domaine Windows ou au sein d’un fichier passé en paramètre ;
• Pour chacun des utilisateurs, le contrôleur de domaine disposant du rôle de PDCe va être contacté afin de connaître la valeur initiale de l’attribut « badPwdCount » de l’utilisateur, puis, si cette dernière est inférieure à un seuil défini par l’attaquant, une tentative de connexion à l’aide d’un mot de passe spécifié en paramètre au script (ou présent au sein d’une liste de mot de passe passée en paramètre) va être tentée ;
• Si l’authentification est réussie :
  • Le mot de passe correspond au mot de passe actuel de l’utilisateur ciblé ;

• Si l’authentification échoue :
  • La valeur de l’attribut « badPwdCount » va alors être analysée :
  • Si cette dernière n’a pas été incrémentée, le mot de passe essayé correspond à un des deux mots de passe précédemment défini par l’utilisateur
  • Si cette dernière a été incrémentée, alors le mot de passe ne correspond ni au mot de passe actuel ni a un précédemment mot de passe de l’utilisateur ciblé. Le script va donc passer à l’utilisateur suivant afin de poursuivre l’attaque.

Il est à noter que le seuil de verrouillage d’un compte utilisateur ne peut être collecté par un utilisateur standard du domaine. De fait, il convient par sécurité d’exécuter le script avec une valeur limite de l’attribut « badPwdCount » faible afin d’éviter tout verrouillage de compte utilisateur.