Kerberos et Kerberoasting

Kerberos est un protocole d’authentification fondé sur des tickets. Au lieu d’envoyer des mots de passe, les clients présentent des tickets cryptographiques émis par le centre de distribution de clés (KDC), qui s’exécute sur chaque contrôleur de domaine.

• Le serveur d’authentification (AS) émet un ticket d’octroi de tickets (TGT).
• Le serveur d’octroi de tickets (TGS) émet des tickets de service.
• Les services valident les tickets sans contacter le DC.

Kerberos comporte trois échanges de messages. Les comprendre permet de voir où interviennent les attaques.

• AS-REQ / AS-REP : le client prouve son identité (pré-authentification) et obtient un TGT chiffré avec la clé de krbtgt.
• TGS-REQ / TGS-REP : le client présente le TGT pour demander un ticket de service (TGS).
• AP-REQ / AP-REP : le client présente le TGS au service.

L’AS-REP roasting attaque le premier échange ; le Kerberoasting attaque le deuxième.

Un nom principal de service (SPN) associe une instance de service au compte qui l’exécute. Lorsque vous demandez un TGS pour un SPN, le ticket obtenu est partiellement chiffré avec le hachage du mot de passe du compte de service.

C’est le principe central du Kerberoasting : tout utilisateur authentifié peut demander des tickets pour des comptes de service, puis les casser hors ligne afin de retrouver le mot de passe en clair.

Le Kerberoasting est discret, car demander un TGS constitue un comportement normal. Les étapes de l’attaque sont les suivantes :

• Énumérer les comptes utilisateur associés à des SPN.
• Demander des tickets TGS pour ces SPN.
• Extraire les blocs chiffrés des tickets.
• Les casser hors ligne avec une liste de mots ; aucune interaction avec le DC n’est nécessaire pendant le cassage.

Le ticket capturé utilise le mot de passe du compte de service comme clé. Le cassage hors ligne essaie des mots de passe candidats jusqu’à ce que l’un d’eux déchiffre correctement le ticket.

Les comptes de service ont souvent des mots de passe faibles qui n’ont jamais été renouvelés, ce qui permet de les casser rapidement.

Le chiffrement utilisé pour le ticket influe sur la vitesse de cassage.

• RC4 (etype 23) est rapide à casser et constitue un signal d’alerte s’il est encore autorisé.
• AES (etype 17/18) est bien plus lent à forcer par recherche exhaustive.
• Les attaquants peuvent abaisser le niveau des demandes à RC4 en abusant de /tgtdeleg ou de msDS-SupportedEncryptionTypes.

Les défenseurs devraient désactiver RC4 dans tout le domaine et imposer AES.

Une attaque apparentée cible les comptes dont la pré-authentification Kerberos est désactivée (DONT_REQ_PREAUTH). Sans pré-authentification, l’AS-REP contient des données chiffrées avec le hachage du mot de passe de l’utilisateur, qui peuvent être obtenues sans aucun identifiant.

Le Kerberoasting réussit en raison de faiblesses structurelles, et non de défauts du protocole.

• Tout principal authentifié peut demander n’importe quel ticket de service, par conception.
• Les comptes de service sont souvent créés une fois avec un mot de passe faible, puis ne sont jamais renouvelés.
• Beaucoup disposent de privilèges élevés (par exemple, des comptes de service SQL membres des administrateurs du domaine).
• Le cassage se déroule entièrement hors ligne ; le verrouillage du compte ne se déclenche donc jamais.

Les défenseurs peuvent détecter le roasting grâce à la télémétrie des demandes de TGS.

• Surveillez l’événement 4769 pour les demandes de tickets RC4 (0x17), en particulier lorsqu’elles surviennent par vagues depuis un même compte.
• Déclenchez une alerte lorsqu’un seul principal demande rapidement un grand nombre de SPN distincts.
• Déployez des comptes SPN leurres qu’aucun service légitime n’utilise ; toute demande est alors malveillante.

La correction durable consiste à supprimer les conditions qui rendent les tickets cassables.

• Utilisez des comptes de service gérés par groupe (gMSA) avec des mots de passe de 120 caractères ou plus, renouvelés automatiquement.
• Imposez des mots de passe longs et complexes pour les comptes de service classiques qui subsistent.
• Désactivez RC4 et exigez les types de chiffrement AES.
• Supprimez les SPN inutiles et appliquez le principe du moindre privilège aux comptes.

Pendant des tests autorisés, effectuez le cassage de tickets dans un environnement isolé et n'exfiltrez jamais d'identifiants en clair au-delà du périmètre de la mission. Indiquez quels comptes ont été cassés et à quelle vitesse, afin que le client puisse prioriser la migration vers gMSA.

Traitez les mots de passe cassés comme des données sensibles : stockez-les sous forme chiffrée et supprimez-les après le rapport.

Vérifiez que vous maîtrisez les mécanismes du Kerberoasting.

Vous avez appris comment Kerberos émet des tickets et comment ce mécanisme est détourné.

• Les tickets SPN sont chiffrés avec les hachages des comptes de service, ce qui permet un cassage hors ligne.
• Les tickets RC4 se cassent rapidement ; AES et gMSA sont les protections.
• Le cassage AS-REP ne nécessite aucun identifiant lorsque la préauthentification est désactivée.
• Les SPN leurres et la surveillance des tickets RC4 de l'événement 4769 permettent de détecter l'attaque.

Nous verrons ensuite comment réutiliser des identifiants volés avec le passage par le hachage et le passage par le ticket.