Décrivez-moi le Kerberoasting — comment il fonctionne, pourquoi il est possible et comment les défenseurs l'arrêtent.

Le Kerberoasting est l'une des attaques Active Directory les plus fiables car il abuse du fonctionnement de Kerberos exactement tel qu'il a été conçu. Il ne nécessite qu'un seul compte de domaine valide pour démarrer, ce qui en fait un incontournable des engagements internes.

Comment Kerberos prépare le terrain

Dans Kerberos, les services sont identifiés par un Service Principal Name (SPN). Lorsqu'un utilisateur veut utiliser un service, le Key Distribution Center émet un TGS (ticket de service) chiffré avec le hachage du mot de passe du compte de service (sa clé NTLM/RC4, ou sa clé AES). L'idée est que seul le service légitime, qui connaît son propre mot de passe, puisse déchiffrer et valider le ticket.

L'abus

La faille tient à qui est autorisé à demander. Tout utilisateur du domaine authentifié peut demander un TGS pour n'importe quel SPN — le KDC ne vérifie pas si vous êtes réellement autorisé à utiliser ce service. Un attaquant procède donc ainsi :

1. Énumère les comptes ayant des SPN (souvent des comptes utilisateur ordinaires exécutant des services — SQL, IIS, etc.) via LDAP.
2. Demande les tickets TGS pour eux (outils : Rubeus, GetUserSPNs.py d'Impacket).
3. Extrait le ticket chiffré et le casse hors ligne avec Hashcat. Si le mot de passe du compte de service est faible, il tombe en quelques heures.

Surtout, le cassage se fait hors ligne, donc il n'y a aucune connexion échouée, aucun verrouillage et un bruit minimal. Les attaquants demandent souvent des tickets RC4 (etype 23) car ils sont plus rapides à casser qu'AES.

Pourquoi les comptes de service sont le butin

Les comptes de service ont fréquemment des mots de passe anciens, sans expiration et faibles et sont sur-privilégiés — parfois administrateurs du domaine. Cassez-en un et vous pouvez sauter directement à un haut niveau de privilège.

Défenses

• Utilisez des mots de passe longs et aléatoires (25+ caractères) pour les comptes de service, ou des group Managed Service Accounts (gMSA) qui tournent automatiquement.
• Imposez AES et désactivez RC4 lorsque c'est possible.
• Appliquez le moindre privilège aux comptes de service.
• Détectez les pics d'Event ID 4769, en particulier les demandes de tickets RC4 provenant d'un seul utilisateur.

Ce que recherchent les recruteurs

Que vous expliquiez pourquoi ça fonctionne (n'importe qui peut demander un TGS, cassage hors ligne = furtivité), que vous nommiez de vrais outils, signaliez l'angle RC4, et pivotiez proprement vers les gMSA et la surveillance du 4769 comme correctif.