Krbtgt est un compte critique d’infrastructure dans la sécurité Active Directory, tout simplement !
Rappel
Il s’agit d’un compte built-in, donc présent dans tout annuaire Active Directory. Il est situé au niveau du chaque domaine et porté par les contrôleurs en lecture/écriture (RWDC par opposition à RODC).
Par défaut, son statut est désactivé. Son mot de passe est inconnu dans la mesure où il est généré aléatoirement. Autrement, le compte krbtgt historise ses deux derniers mots de passe.
Autrement, les contrôleurs de domaine de type RODC (en lecture seule) ont chacun leur propre compte krbtgt. Il est formaté avec la convention de nommage suivante : krbtgt_xxxxx. Par analogie, il est utilisé pour crypter et signer les tickets Kerberos sur leurs propres sites. Chaque RODC a un compte krbtgt spécifique pour garantir par conséquent une bonne isolation cryptographique.
Particularité
krbtgt est un compte particulier. Il est important et stratégique puisque son mot de passe est utilisé dans le mécanisme du protocole Kerberos, c’est-à-dire pour générer les tickets (au niveau du KDC) lors des processus d’authentification Active Directory.
Précisément, le hash du mot de passe du compte krbtgt est utilisé pour crypter/chiffré et signer tous les tickets Kerberos.
Par rapport à l’historisation évoquée, une unique modification du mot de passe du compte krbtgt est donc insuffisante. C’est inefficace puisque l’ancien mot de passe demeure connu (le hash également de ce fait), donc effectif et valable dans ce cas. Cela implique que tous les tickets Kerberos déjà émis avec ce paramètre restent valides.
Conseils / Sécurisation
Par rapport au risque de compromission de l’annuaire Active Directory, la recommandation est de changer deux fois le mot de passe du compte krbtgt. Cela, dans le but d’éviter que celui-ci puisse être sujet aux attaques baptisées Golden Ticket.
D’une façon générale, pour des questions de sécurité et de prévention, il est recommandé de changer régulièrement le mot de passe du compte krbtgt. Le cycle dépend de votre stratégie, chaque six mois en laissant au moins 10 heures entre les deux changements requis (cf. Maximum lifetime for user ticket).
Pour rappel, les 10 heures représentent la valeur par défaut de validité du ticket d’un compte « lambda » par opposition à « Protected Users« .
Vous devez vérifier ce paramètre au niveau du domaine pour ajuster le temps d’attente si nécessaire lors de votre processus de sécurisation. Cette valeur se trouve dans : Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy.
Lors du premier changement, il faut toujours laisser le temps au système de cacher (au sens mise en cache) l’ancien hash. Par conséquent, la réplication vers l’ensemble des contrôleurs de domaine doit être sans faille.
Recommandations
La recommandation de l’ANSSI est de changer le mot de passe krbtgt tous les 40 jours. Cela reste à évaluer vis-à-vis de votre manière de fonctionner. Est-ce réaliste ?
Aussi, vous êtes invités à ajustez votre cadence de changement selon la taille de votre infrastructure et la capacité de vos équipes.
Conclusion
Cette modification du mot de passe krbtgt reste une opération simple et élémentaire, script GitHub par ici.
Elle demande toutefois une certaine organisation ainsi que le respect de certaines règles.
Le risque que vous encourez est d’invalider tous les tickets en cours en cas de changement successif et précipité. La conséquence sera de déstabiliser votre infrastructure en cassant l’authentification Kerberos. Notez que ce risque peut parfois être une réponse (une parade) en cas d’attaque avérée.