Kerberoasting : transformer un ticket de service en mot de passe de domaine

Le Kerberoasting fait partie de ces attaques qui ressemblent à un bug et qui sont en réalité une fonctionnalité. Active Directory remet à n'importe quel utilisateur authentifié un ticket de service pour tout compte disposant d'un Service Principal Name enregistré. Ce ticket est chiffré avec une clé dérivée du mot de passe du compte de service. Demandez-le, sortez-le hors ligne, cassez-le sur votre propre matériel. Aucun droit particulier, aucun contact avec le service cible, aucun verrouillage de compte puisque les essais ont lieu entièrement sur votre machine.

C'est ce dernier point qui le rend dangereux. Le password spraying en ligne est bruyant et déclenche les politiques de verrouillage. Le Kerberoasting déplace la force brute complètement hors du domaine.

D'où vient la matière cassable

Quand vous demandez à un contrôleur de domaine un TGS pour un SPN donné, une partie de la réponse est chiffrée sous la clé à long terme du compte propriétaire de ce SPN. Pour RC4 (etype 23), cette clé n'est rien d'autre que le hash NTLM du mot de passe. La structure que vous récupérez est donc en somme « un blob chiffré que vous pouvez vérifier en devinant le mot de passe ». Devinez le mot de passe, dérivez la clé, le blob se déchiffre en quelque chose de bien formé. Voilà l'oracle.

Le hic, en pratique, c'est de savoir quels comptes possèdent des SPN. Les comptes machine en ont aussi, mais leurs mots de passe font 120 caractères aléatoires et tournent régulièrement, donc oubliez-les. Vous visez les SPN enregistrés sur des comptes utilisateur ordinaires. Ce sont généralement des comptes de service créés par un humain il y a des années, souvent avec un mot de passe du genre Sql2017! qui n'a jamais changé parce que le faire tourner risquerait de casser quelque chose que personne n'a documenté.

Récupérer les tickets

Sur une machine d'attaque Linux, Impacket est la voie habituelle :

GetUserSPNs.py -request -dc-ip 10.0.0.10 contoso.local/lowprivuser:Password1 -outputfile tgs.txt

Cela énumère les comptes porteurs de SPN et demande un ticket pour chacun, en les écrivant au format hashcat. Depuis Windows, Rubeus fait la même chose et de façon plus discrète :

Rubeus.exe kerberoast /outfile:tgs.txt

Ce qui atterrit dans le fichier ressemble à ceci, et c'est ce qu'on appelle un hash krb5tgs :

$krb5tgs$23$*svc_sql$CONTOSO.LOCAL$MSSQLSvc/sql01.contoso.local:1433*$a8f2...

Le 23 est le type de chiffrement. Retenez-le, car c'est lui qui décide si l'affaire vaut votre temps.

Le casser

Les tickets RC4 vont vers le mode 13100 de hashcat :

hashcat -m 13100 -a 0 tgs.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Les hash Kerberoast RC4 sont rapides. Sur un seul GPU moderne, vous tournez à plusieurs milliards d'essais par seconde, donc un compte de service avec un mot de passe « dictionnaire plus règles » tombe presque immédiatement. C'est pourquoi la technique affiche un taux de réussite si élevé dans les environnements réels : les comptes porteurs de SPN sont précisément ceux dont le mot de passe a été défini une fois puis oublié.

John the Ripper gère les mêmes hash avec le format krb5tgs si vous préférez la détection automatique et rester sur un seul outil. Les arbitrages entre outils s'appliquent comme d'habitude.

Quand vous récupérez de l'etype 17 ou 18

Parfois le ticket revient sous la forme $krb5tgs$18$ au lieu de $krb5tgs$23$. C'est de l'AES256, et le mode est -m 19700 (ou 19600 pour AES128). La structure se ressemble. L'expérience de cassage, non. Le Kerberos AES utilise une dérivation string-to-key volontairement lente, si bien que votre débit s'effondre de plusieurs milliards par seconde à quelque chose comme quelques centaines de milliers. Un mot de passe qui tomberait instantanément sous RC4 devient en pratique hors d'atteinte, à moins d'être réellement faible.

Vous ne pouvez pas toujours forcer RC4. Les domaines modernes peuvent être configurés pour n'émettre que des tickets AES pour un compte, et dans ce cas, le Kerberoasting de ce compte est le plus souvent une impasse. Ne brûlez pas une semaine de temps GPU sur un unique ticket AES en espérant un miracle. Passez aux tickets RC4 et aux comptes AS-REP roastables.

Lire le résultat en attaquant, et en défenseur

Un compte de service cassé est rarement un but en soi. C'est un levier. Les comptes de service sont fréquemment sur-privilégiés, parfois logés dans Domain Admins parce que c'était le moyen rapide de faire fonctionner quelque chose en 2019. La vraie valeur d'un cassage krb5tgs réside donc dans ce que cette identité permet d'atteindre ensuite.

Côté défense, la vérité dérangeante, c'est que vous ne pouvez pas empêcher les utilisateurs de demander des tickets : c'est Kerberos qui fonctionne comme prévu. Ce que vous pouvez faire, c'est retirer la récompense. Utilisez des group managed service accounts pour que les mots de passe fassent 240 bits aléatoires et tournent automatiquement. Auditez les comptes utilisateur qui portent des SPN et demandez-vous pourquoi. Et forcez l'AES, car transformer un cassage 13100 en cassage 19700 change suffisamment l'équation économique pour que la plupart des attaquants n'insistent pas.

La longueur du mot de passe est la seule chose qui vous sauve vraiment ici. Un mot de passe de compte de service aléatoire de 14 caractères ou plus survit très bien au Kerberoasting RC4. Welcome2024!, non, et les dictionnaires à règles l'avalent en quelques secondes.