Kerberoasting, Active Directory à la rôtissoire…

Salut a tous aujourd’hui on va voir une nouvelle technique pour récupérer puis casser des mots de passe dans une infrastructure Active Directory :  le Kerberoasting. Dans la langue de Molière ça donnerai « faire rôtir kerberos » et c’est franchement efficace si les administrateurs de l’AD n’appliquent pas des mots de passes complexes sur les comptes de services. Ça consiste en quoi ? simplement à demander et récupérer des TGS à un KDC pour ensuite casser la protection cryptographique de ces TGS et ainsi récupérer le mot de passe du service associé à ce TGS. On va voir tout ça plus en détail, après quelques rappels sur Kerberos. La technique est sortie en 2014, mais ce n’est que récemment qu’elle est devenue très (spoiler alert : trop) simple à utiliser.

Kerberos : 3 têtes, un os…

Bon alors Kerberos comment ça fonctionne ? Wikipédia explique ça très bien déjà, mais pour faire simple je vous refait un topo. Kerberos fonctionne à base de clés secrètes partagées. En simplifiant beaucoup, on a trois éléments que sont :

• C le client ;
• X un service kerberisé sur le serveur S ; et
• K le serveur KDC de Kerberos.

Le serveur et le client possède une clé secrète symétrique et partagée avec le KDC.

Si C souhaite accéder à X sur S :

1. Il s’authentifie d’abord avec son mot de passe auprès du KDC K pour obtenir un TGT (Ticket Granting Ticket).
2. Le TGT est délivré chiffré à l’aide d’une clé Kc partagée entre K et C. (Et le client reçoit aussi un TGS mais on s’en fou ici en fait).
3. Le client va ensuite utiliser le TGT qu’il a obtenu dans une demande de service (TGS) pour X (sur le serveur S) au KDC, requête protégée par la clé session délivrée avec le TGT.
4. Le serveur lui renverra alors un TGS (Ticket Granting Service), en 2 parties protégées respectivement par : Kc la clé du client et Kx la clé du service.
5. Ce TGS envoyé au service X lui permettra de s’assurer que le TGS en question a bien été délivré par le KDC qu’il reconnait puisqu’il partage Kx avec lui.

Un bon dessin valant mieux qu’un long discours, j’ai schématisé tout ça :

Je rappelle que ce schéma est grossièrement simplifié et qu’il ne faut donc pas le prendre comme référence du fonctionnement de Kerberos. Il manque plein d’éléments, et j’ai fait plusieurs raccourcis pour rendre ça plus accessible (manque un ticket TGS avec le TGT, ne fait pas de host validation, ne détaille pas le contenu des ticket). Si vous n’avez rien compris : rappelez-vous simplement qu’a un moment le client reçoit un TGS incluant un blob chiffré avec la clé du service X sur S partagé entre S et K. Ok ?

Kerberoasting : it’s not a bug, it’s a feature…

Alors quel est le problème dans ce système ? le KDC renvoi des TGS protégés avec une clé partagée que seul le service X et lui connaisse. Oui mais, le KDC délivre des TGS y compris pour des services auxquels le client n’a pas accès ! Car dans Kerberos c’est au service de vérifier si le client a bien les droits d’accès pour lui. Kerberos fourni le SSO, pas le contrôle d’accès.

Du coup, les clients peuvent demander des TGS pour des services auxquels ils savent pertinemment qu’ils n’auront pas accès. En théorie pas de soucis car la partie sensible de ces TGS est protégée par une clé connue seulement par S et K, le client ne peut rien en faire. Enfin, presque rien…

Il y a deux spécificités dans un active directory qui font qu’on peut attaquer ce système. D’abord, les domaines Microsoft sont plein de services « courants » comme Ms SQL, DFS-R/N, ou Microsoft Virtual Console Service et autres. Les « Services Principals Names » (SPN) de ces services sont toujours les mêmes et donc très simple à requêter pour tester leur existence auprès d’un KDC et recevoir un TGS le cas échéant. Ensuite pour un service qui tourne avec un compte de domaine Active Directory, c’est le hash NTLM du mot de passe de ce compte de domaine qui est utilisé comme clé « Kx » (revoir le schéma) pour protéger le TGS délivré. Et pas un vrai secret aléatoire comme une clé AES, vous commencez à sentir le problème venir ?

On peut donc « spammer » un KDC de demandes de TGS pour accéder à des service avec des SPN tirés d’une liste « probable ». On récupère alors tous les TGS existants demandés protégés avec le mot de passe du compte de service… qu’on peut passer dans un logiciel de brute force comme John the Ripper ou hashcat.

Heureusement que tous les comptes de services en entreprise ont des mots de passe complexe et renouvelé régulièrement… Dans le cas contraire, les mots de passes trop simple sur ces comptes seront rapidement trouvé par un John sous stéroïde.

Mise en pratique du kerberoasting

Bon alors, on n’a pas évoqué les prérequis jusque-là, mais pour que ça fonctionne, vous avez compris qu’il faut pouvoir légitimement demander des TGS au KDC, c’est à dire : posséder un TGT. Et donc avoir accès à un compte utilisateur « lambda » sur l’AD que vous voulez attaquer. La dernière version du kerberoasting proposé par Harmj0y est 100% PowerShell donc vous avez seulement besoin d’une console bleu en v2 et du script Invoke-Kerberoast.ps1 packagé par Harmj0y.

Pour lancer le script dans une console PowerShell :

Ça dure plus ou moins longtemps en fonction de la taille de votre AD (« That’s what she said ! »), et si on regarde dans le fichier Kerberoast.csv en sortie, on a ce genre de ligne :

Fichier qu’on passe à John sans réfléchir sur notre linux (avec un GPU dédié pour les plus riches) :

john --session=Kerberoasting Kerberoast.csv

Pour ceux qui ne se souvienne pas le « pourquoi ? comment? » de John : par ici. Une fois la commande démarrée, attendre de quelques minutes à quelques années, et boum :

john --show Kerberoast.csv

SQLServerApp;CN=SQLServerApp,OU=svc,DC=test,DC=domain,DC=tld;host/krbf5.test.domain.tld;$krb5tgs$unknown:Password1234!
1 password hash cracked, 665 left

Un couple login/mot de passe « cadeau » qui permettra probablement d’accéder au serveur qui héberge le service en question à minima, et plus si ce compte possède des privilèges spécifiques : serveurs de fichiers, base de données, logon interactif, administration du serveur, etc.

Contre-mesures

Alors ne jetez pas votre Active Directory immédiatement, il existe des contre-mesures efficaces. Comme souvent la plupart sont de la simple bonne gestion/MCS de parc :

1. Limiter autant que possible les comptes de services de domaine avec un SPN, à fortiori avec des privilèges, au profil des comptes locaux aux machines.
2. Pour les comptes de services restant, privilégier les comptes de services managés (dit MSA). Ces comptes délèguent la gestion de leur mot de passe à la machine qui les héberge, le mot de passe est alors renouvelé automatiquement tous les 30j par un joli bloc de 254 caractères aléatoires. Rendant très improbable toute tentative de brute force par un attaquant un peu trop enthousiaste…
3. Pour les services restant ne supportant pas les MSA, il ne vous reste plus qu’à renouveler régulièrement les mots de passe de ces comptes de service et  de respecter une politique de sécurité irréprochable sur ces mots de passe (>25 caractères ? dixit Harmj0y). Politique, par exemple imposée à l’aide d’une GPO par préférence.

Du côté proactif :

1. Surveiller les logs de vos DC à la recherche de demande massives de TGS en provenance d’un compte/une IP, ce n’est pas un comportement normal (EventId 4769).
   Néanmoins pour avoir testé : c’est assez discret dans le volume des logs d’un AD (de l’ordre de la centaine d’évènements), donc il faut filtrer un peu plus.
   Par exemple en cherchant le nombre de demande de TGS pour des services distincts par utilisateur sur une période de temps courte. Personne ne demande à accéder 1 fois à 150 services différents en 2min 30.
2. Préventif : tester sur votre infra et regarder les mots de passe qui tombent dans une durée pertinente pour simuler l’attaquant dont vous voulez vous protéger.
   Quelques pistes :
   1. Script kiddie : 1j ?
   2. Pentest : 1 semaine ?
   3. Mafieux : 1 mois ?
   4. NSA : 100 ans… changez de mot de passe !

Bref, pas grand-chose à faire, on est principalement sur de la bonne gestion des mots de passes des comptes de services de son AD et un peu de surveillance.

Conclusion

Bon voilà, j’espère que vous avez compris pourquoi il faut désormais gérer de manière irréprochable les comptes de services Active Directory. Le Kerberoasting à le bon goût de fonctionner en « pur-PowerShell » et ne nécessite donc aucun outil particulier qui risque de faire crier un antivirus. Elle est relativement discrète dans les logs. Et permet donc à vos stagiaires d’exfiltrer tranquillement les tokens chiffrés de vos comptes de services AD, pour les casser ensuite sur Amazon EC2 tranquillement, et revenir prendre les clés et la carte grise de votre AD, une semaine plus tard.

Sources

Si vous voulez en savoir plus sur le Kerberoasting, je ne peux que vous conseiller la lecture des sources suivantes que j’ai utilisé pour cet article.

1. Attacking Kerberos: Kicking the Guard Dog of Hades.
2. Kerberoasting Without Mimikatz ;
3. MISC n°85 « Active Directory : nouveaux challenges à venir » (Réf.) ;
4. Room362 Kerberoasting : partie 1, 2 et 3 ;
5. adsecurity.org :  kerberoast, et plus spécialement cet article ;
6. Kerberos Technical Supplement for Windows ;
7. kerberos, kerberoast and golden tickets ;