© 2019. Tous droits réservés.

Principe

L’article sur le a permis de comprendre comment un utilisateur demandait un TGS auprès du contrôleur de domaine. La réponse est

Un utilisateur de l’Active Directory peut demander un TGS pour n’importe quel service auprès du KDC. En effet, ce dernier n’a pas pour rôle de vérifier les droits du demandeur. Il a seulement pour rôle de fournir les informations de sécurité liées à l’utilisateur (via le ). C’est le service qui doit vérifier les droits de l’utilisateur en lisant son PAC dont une copie est fournie dans le TGS.

Ainsi, il est possible d’effectuer des demandes de TGS en indiquant des arbitraires, et si ces sont enregistrés dans l’Active Directory, le KDC fournira un morceau d’information chiffré avec la clé secrète du compte exécutant le service. L’attaquant peut, avec cette information, tenter de trouver le mot de passe en clair du compte via une attaque par exhausitivité (brute force).

Heureusement, la plupart des comptes qui exécutent les services sont les comptes machines (sous la forme ) et leurs mots de passe sont très longs et aléatoires, donc ils ne sont pas vraiment vulnérables à ce type d’attaque. Il existe cependant des services qui sont exécutés par des comptes de services avec des mots de passe choisis par des humains. Ce sont ces comptes qui sont bien plus simples à compromettre via des attaques de type brute-force, donc ce sont ces comptes qui seront visés dans une attaque Kerberoast.

Afin de lister ces comptes, un filtre LDAP peut être utilisé afin d’extraire les comptes de type utilisateur possédant un attribut non vide. Ce filtre est le suivant :

Voici alors un script simple en PowerShell qui permet de récupérer les utilisateurs avec au moins un :

Dans le lab, un faux a été placé sur l’utilisateur “support account”.

Ainsi, lors de la recherche LDAP, voici ce que ça donne :

Bien entendu, il existe plusieurs outils permettant d’automatiser cette tâche. Je citerai ici l’outil de , outil qui s’occupe de lister les comptes utilisateurs avec un ou plusieurs , effectuer des demandes de TGS pour ces comptes et extraire la partie chiffrée dans un format qui peut être cracké (par John par exemple).

On espère alors trouver des mots de passe, ce qui dépend de la politique de mot de passe de l’entreprise pour ces comptes.

Protection

Pour se protéger de ce type d’attaque, il faut éviter d’avoir des sur des comptes utilisateurs, au profit des comptes machines.

Si c’est vraiment nécessaire, alors il faut utiliser la fonctionnalité “Managed Service Accounts” (MSA) de Microsoft qui permet de faire en sorte que le mot de passe du compte soit robuste et changé régulièrement et automatiquement. Pour cela, il suffit d’ajouter un compte de service (seulement via PowerShell) :

Puis il convient de l’installer sur la machine

Enfin, il faut assigner cet utilisateur au service.

Conclusion

L’attaque Kerberoast permet de récupérer de nouveaux comptes au sein d’un Active Directory pour une tentative de mouvement latéral. Les comptes alors compromis peuvent avoir des droits plus élevés, ce qui est parfois le cas sur la machine qui héberge le service. Il est alors important d’un point de vue défensif de maîtriser l’attribut des comptes de domaine pour éviter que des comptes à mot de passe faible soient vulnérables à cette attaque.