Le Kerberoasting est une attaque courante dans les environnements Active Directory. Elle s’appuie sur une faiblesse du protocole Kerberos, mais son exploitation nécessite des configurations spécifiques.
Dans cet article, nous expliquerons le principe et le fonctionnement de l’attaque Kerberoasting. Nous verrons comment identifier et exploiter un environnement vulnérable, ainsi que les méthodes pour s’en protéger.
Guide complet sur le Kerberoasting
Kerberoasting : principe et fonctionnement
Qu’est-ce que le Kerberoasting ?
Une attaque Kerberoasting cible les environnements Active Directory utilisant le protocole Kerberos pour l’authentification. En effet, le Kerberoasting permet à un attaquant, disposant d’un compte valide sur le réseau, de récupérer des tickets Kerberos appelés Service Tickets. Ces tickets contiennent des informations chiffrées à l’aide du mot de passe du compte lié au service.
L’objectif de l’attaquant est de récupérer ces tickets et d’effectuer une cryptanalyse hors ligne pour tenter de deviner le mot de passe du compte associé. Si le mot de passe est faible ou mal protégé, il peut être craqué, donnant à l’attaquant un accès supplémentaire dans le réseau.
Principe de l’attaque Kerberoasting
Pour comprendre le principe de l’attaque Kerberoasting, il est nécessaire de revenir sur le concept de ticket de service (ST).
Rôle du Ticket de Service (ST) dans Kerberos
Le ticket de service (ST) est le ticket obtenu à l’étape « Ticket Granting Service » (TGS). Cette étape correspond au moment où le client demande l’accès à un service auprès du « key Distribution Center » (KDC).
La particularité du ticket de service (ST), c’est qu’une partie de celui-ci est chiffrée. Le chiffrement de cette partie est effectué au moyen d’un algorithme de chiffrement symétrique et d’un dérivé du mot de passe du compte de service.
Chiffrement des tickets
Dans la logique du protocole Kerberos, le chiffrement des tickets n’a pas le même objectif en fonction des adversaires.
- Si l’adversaire n’est pas l’un des acteurs du protocole Kerberos, mais simplement un attaquant en écoute sur le réseau, alors le chiffrement sert à garantir la confidentialité de certains champs du ticket, en particulier la clé de session.
- Dans le cas où l’adversaire est le client, le chiffrement sert essentiellement à garantir l’intégrité du ticket face à une modification arbitraire de son contenu.
Cette différence s’explique, car, malgré le fait que le client soit dans l’incapacité de déchiffrer le ticket, il reste en mesure de déduire une partie de son contenu. En effet, la partie chiffrée dispose d’informations connues du client (SPN, clé de session, etc.).
Cryptanalyse par attaque à texte clair connu
Avec la connaissance, même partielle, du contenu de la partie chiffré du ticket, il est possible d’effectuer une opération de cryptanalyse avec une « attaque à texte clair connu » (known-plaintext attack). En cas de réussite, le secret du service sera découvert.
La réussite de cette opération de cryptanalyse va dépendre de la complexité du mot de passe du compte de service, ainsi que de la complexité de l’algorithme utilisé pour dériver le mot de passe (RC4, DES, AES, etc.).
Cette observation a une conséquence assez intéressante dans un contexte Active Directory. Puisque le client peut initier une demande TGS pour accéder à n’importe quel service, cela implique que :
- N’importe quel compte actif du domaine est en mesure de tenter cette opération de cryptanalyse.
- N’importe quel compte disposant d’un « Service Principal Name » (SPN)peut être ciblé par cette opération de cryptanalyse.
Ainsi, n’importe quel utilisateur authentifié peut tenter de déduire le mot de passe d’un compte de service par cette opération de cryptanalyse.
Limites de l’attaque sur les comptes machines
Dans la réalité, cette opération de cryptanalyse rencontre des limites. En effet, il se trouve que les comptes machines sont gérés directement par le contrôleur de domaine. Cette gestion différente introduit des mécanismes de sécurité concernant les mots de passe de ces comptes. Ainsi, par défaut, les mots de passe des comptes machines sont :
- Générés aléatoirement avec une longueur de 120 caractères,
- Renouvelés périodiquement tous les 30 jours.
Dans ces conditions, l’opération de cryptanalyse qui ciblerait un compte machine ne peut aboutir à cause de la complexité du mot de passe. Dans un environnement Active directory, il est très commun que les services soient associés à des comptes machine.
Les comptes utilisateurs comme cibles privilégiées d’une attaque Kerberoast
En revanche, il arrive parfois que pour des besoins spécifiques, un compte utilisateur soit utilisé comme service. Puisque ce type de compte ne dispose pas des mêmes mécanismes de sécurité que les comptes machines, l’opération de cryptanalyse a des chances d’aboutir.
En effet, un compte utilisateur ne dispose généralement pas des mêmes contraintes sur la complexité et la rotation de leur mot de passe. Un autre élément rendant ces types de comptes intéressants est le l’algorithme utilisé pour dériver le mot de passe de ces comptes. Par défaut, les comptes utilisateur ne disposent pas de configuration pour imposer l’algorithme AES lors de cette dérivation. L’utilisation de l’algorithme RC4 par le KDC lors de l’obtention du ticket de Service vient encore faciliter l’opération de cryptanalyse.
En conclusion, l’attaque kerberoast consiste à cibler les services utilisant des comptes utilisateur, obtenir un ticket de service (ST) pour ces comptes puis effectuer une opération de cryptanalyse afin de déduire leur mot de passe.
Comment identifier des comptes vulnérables à une attaque Kerberoast ?
Dans un environnement Active Directory, un compte est considéré comme vulnérable à l’attaque kerberoast si c’est un compte utilisateur dont l’attribut « Service Principal Name » (SPN) est non vide.
Un simple utilisateur authentifié sur le domaine est en mesure d’identifier ce type de compte en requêtant l’annuaire LDAP.
Voici le type de requête LDAP permettant d’obtenir l’information voulue :
(&(&(objectCategory=person)(objectClass=user))(servicePrincipalName=*))Plusieurs outils proposent la détection de ces comptes vulnérables. Tous ces outils effectueront plus ou moins la même recherche.
Voici comment retranscrire cette recherche depuis une machine non associée au domaine, l’outil ldeep propose une commande dédiée pour énumérer ce type de compte :
ldeep ldap -u <user> -p <password> -d <domain> -s ldap://<DC_ip> users spnDepuis un poste Windows associé au domaine, il est possible d’utiliser l’outil AD-Module :
get-ADUser -Filter 'ServicePrincipalName -like "*"'
Dans la capture ci-dessus, la valeur de l’attribut msDS-SupportedEncryptionTypes a été explicitement affichée. Cet attribut permet d’identifier les comptes pour lesquels l’algorithme RC4 sera utilisé pour l’obtention du ticket de service (ST). Par défaut, cet attribut est vide pour les comptes utilisateurs, ce qui correspond à l’utilisation de l’algorithme RC4.
Par défaut, le compte krbtgt apparaitra dans la sortie de ces outils. Bien qu’il s’agisse d’un compte possédant les propriétés recherchées, il ne s’agit pas d’un compte considéré comme vulnérable à l’attaque kerberoast.
Exploitation des comptes Active Directory vulnérables au Kerberoasting
Une fois les comptes vulnérables identifiés, l’exploitation effective de l’opération de cryptanalyse requiert plusieurs étapes.
Identification et récupération du Ticket de Service (ST)
Dans un premier temps, il est nécessaire de demander auprès du KDC un Ticket de Service (ST) pour accéder à l’un des services déclarés par l’utilisateur vulnérable.
Ce ticket de service peut ensuite être converti dans un format compréhensible par les programmes de craquage de mot de passe.
Utilisation des outils d’exploitation
L’exploitation peut être effectuée au moyen de l’outil Rubeus ou du script GetUserSPNs.py de la suite Impacket.
Notons que ces outils permettent la détection des comptes vulnérables, la récupération d’un ticket de service et la présentation de ce ticket dans un format adapté aux outils de cracking de mot de passe.
Voici comment procéder à ces actions via Rubeus :
Rubeus.exe kerberoast /nowrap /simple
La sortie ainsi obtenue aura un format similaire à celui-ci :
$krb5tgs$XX$*serviceaccount$domain.local$USSvc/[email protected]*$D35..La valeur inscrite dans XX permet de différencier l’algorithme utilisé par le KDC pour générer le ticket de service (ST). Si la valeur observée est 23, alors l’algorithme utilisé pour dériver le mot de passe du compte de service est RC4.
Cet algorithme est le plus facile à casser. Si la valeur 18 est observée, alors l’algorithme utilisé par le KDC est AES. Bien que la récupération du mot de passe ne soit pas impossible, l’utilisation de cet algorithme rend l’opération de cassage de mot de passe plus difficile.
Craquage du mot de passe
L’utilisation d’outils de cracking comme john ou hashcat servira à calculer le mot de passe du compte à partir du texte obtenu à l’étape ci-dessus.
Voici comment réaliser cette étape avec hashcat et une liste de mots de passe potentiels :
hashcat -m 13100 -a 0 hashfile wordilst.txt # for $krb5tgs$23$*…
hashcat -m 19700 -a 0 hashfile wordlist.txt # for $krb5tgs$18$*…Si le mot de passe du compte de service est l’un de ceux présents dans la liste de mot de passe fournie alors l’outil l’identifiera.
C’est de cette façon qu’un utilisateur du domaine est en mesure d’exploiter un compte vulnérable à l’attaque kerberoast. La conséquence est l’obtention du mot de passe en clair du compte vulnérable.
Comment protéger votre Active Directory contre le Kerberoasting ?
Après avoir expliqué le fonctionnement de l’attaque Kerberoast, intéressons-nous aux moyens de s’en protéger.
Puisque seuls les comptes utilisateurs sont concernés, une solution simple est de limiter leur utilisation pour l’implémentation de services. Cette approche est efficace, mais elle ne couvre pas tous les cas d’usage. Parfois, les comptes machines ne suffisent pas pour répondre à certains besoins spécifiques.
Dans ces situations, il est essentiel de renforcer les éléments qui facilitent la cryptanalyse. Une politique de mots de passe robustes appliquée aux comptes utilisateurs est une méthode efficace. Cependant, gérer cette politique manuellement demande une grande rigueur.
Pour simplifier cette gestion, l’utilisation de comptes de service administrés (gMSA) est recommandée. Ces comptes, conçus spécialement pour les services, bénéficient d’une politique de mots de passe gérée automatiquement par le domaine, comme les comptes machines.
Remplacer les comptes utilisateurs vulnérables par des comptes de service administrés constitue donc une excellente solution pour se protéger des attaques Kerberoast.
Auteur : Benoit PHILIPPE – Pentester @Vaadata