Kerberoasting et attaques par Golden Ticket

Pour comprendre les attaques Kerberoasting et Golden Ticket, vous devez avoir une vision claire de l’émission des tickets de service Kerberos. Lorsqu’un client souhaite accéder à un service (par exemple, un serveur SQL), il présente son Ticket Granting Ticket (TGT) au Ticket Granting Service (TGS) du Domain Controller. Le TGS émet un Service Ticket chiffré avec le hachage du mot de passe du compte de service. Le client présente ensuite ce ticket au service, qui le déchiffre avec son propre hachage afin d’en vérifier l’authenticité. Cela signifie que les tickets de service sont chiffrés avec l’identifiant du service ciblé — un détail essentiel exploité par Kerberoasting.

Kerberoasting est une attaque qui exploite le fait que tout utilisateur de domaine authentifié peut demander un ticket de service Kerberos pour n’importe quel service enregistré avec un SPN (Service Principal Name). L’attaquant demande des tickets de service pour les comptes associés à des SPN, capture les données chiffrées du ticket, puis tente de casser le mot de passe du compte de service hors ligne — sans autre interaction avec Active Directory et sans risque de verrouillage du compte. Les comptes de service utilisent souvent des mots de passe faibles, anciens et antérieurs aux exigences modernes de complexité, ou des mots de passe qui n’expirent jamais, ce qui les rend très vulnérables au cassage hors ligne.

Les hachages des tickets de service capturés par Kerberoasting sont chiffrés par défaut avec RC4-HMAC (hachage NTLM) (pour des raisons de compatibilité), ce qui les rend plus rapides à casser que les tickets Kerberos AES-256. L’attaquant fournit les hachages $krb5tgs$23$ capturés à Hashcat ou à John the Ripper pour effectuer des attaques hors ligne par dictionnaire ou par force brute. Des listes de mots courantes comme RockYou, associées à des ensembles de règles, peuvent casser la plupart des mots de passe faibles de comptes de service en quelques minutes ou quelques heures avec le matériel GPU grand public. Une fois le mot de passe cassé, l’attaquant dispose du mot de passe en clair du compte de service et peut l’utiliser pour s’authentifier directement.

Les mesures de protection contre Kerberoasting ciblent quatre domaines : la robustesse des mots de passe — les comptes de service doivent utiliser de longs mots de passe aléatoires (au moins 25 caractères), résistants au cassage hors ligne, même avec des grappes de GPU ; les Group Managed Service Accounts (gMSA) — Windows gère automatiquement les mots de passe gMSA (valeurs aléatoires de 240 caractères renouvelées tous les 30 jours), ce qui rend Kerberoasting irréalisable sur le plan des calculs ; le chiffrement AES uniquement — configurez les comptes de service pour exiger des tickets AES-256 (msDS-SupportedEncryptionTypes), qui sont exponentiellement plus lents à casser que RC4 ; et la détection — déclenchez une alerte en cas de volume inhabituel de demandes TGS (Event ID 4769) pour des comptes de service provenant de postes de travail non habituels.

Le compte KRBTGT est un compte Active Directory intégré spécial dont le hachage du mot de passe sert à signer et chiffrer tous les TGT Kerberos du domaine. Le contrôleur de domaine utilise le hachage KRBTGT pour créer les TGT et valider les TGT entrants. Le hachage KRBTGT devient ainsi l’identifiant le plus précieux d’un environnement Active Directory : toute personne qui le possède peut créer des tickets Kerberos arbitraires et parfaitement valides pour n’importe quel utilisateur, y compris des utilisateurs inexistants, avec n’importe quelle appartenance à des groupes et pour n’importe quelle durée. Dans de nombreuses organisations, le mot de passe KRBTGT n’a généralement jamais été modifié, car cette opération exige une coordination minutieuse.

Une attaque Golden Ticket crée un TGT Kerberos falsifié et parfaitement valide à l’aide du hachage du mot de passe du compte KRBTGT compromis. L’attaquant utilise la commande kerberos::golden de Mimikatz pour générer un TGT pour n’importe quel utilisateur (souvent un faux compte ressemblant à Administrator), avec n’importe quelles appartenances à des groupes (notamment Domain Admins), et pour n’importe quelle durée de validité (souvent fixée à 10 ans). Ce ticket falsifié est impossible à distinguer d’un ticket légitime pour le contrôleur de domaine, car il est valide sur le plan cryptographique : il a été signé avec le véritable hachage KRBTGT. Un Golden Ticket fournit un contrôle complet, persistant et illimité du domaine.

Les Golden Tickets sont particulièrement dangereux, car ils restent valides même après la découverte et le nettoyage de l’attaque initiale. Modifier le mot de passe de l’utilisateur ciblé ne sert à rien : le ticket a été falsifié et ne repose pas sur les véritables identifiants de l’utilisateur. La seule mesure corrective consiste à modifier deux fois le mot de passe KRBTGT (une première fois pour invalider les tickets existants, puis une seconde fois, car deux clés KRBTGT existent toujours pour permettre leur renouvellement). Toutefois, les modifications du mot de passe KRBTGT exigent une coordination minutieuse : si elles sont mal effectuées, elles interrompent l’authentification Kerberos dans tout le domaine. De nombreuses organisations hésitent à appliquer cette mesure corrective, laissant ainsi les Golden Tickets valides indéfiniment.

Un Silver Ticket ressemble à un Golden Ticket, mais sa portée est plus limitée. Il utilise le hachage du compte du service ciblé (au lieu de KRBTGT) pour falsifier un ticket de service destiné uniquement à ce service précis. Par exemple, avec le hachage du compte de service d’un serveur SQL, un attaquant peut falsifier un ticket de service lui accordant n’importe quel accès à ce serveur SQL. Les Silver Tickets sont plus difficiles à détecter que les Golden Tickets, car ils contournent entièrement le contrôleur de domaine : le ticket falsifié va directement de l’attaquant au service, sans contact avec le KDC. La protection exige de sécuriser les hachages des comptes de service et de surveiller les schémas d’accès anormaux aux services sensibles.

Les attaquants obtiennent le hachage KRBTGT au moyen de l’attaque DCSync, qui détourne le protocole légitime de réplication de domaine d’Active Directory. Le Directory Replication Service (DRS) permet aux contrôleurs de domaine de synchroniser les données AD, notamment les hachages de mots de passe, entre eux. Un attaquant disposant des privilèges DCSync (généralement Domain Admin, Enterprise Admin ou tout compte disposant des autorisations Replicating Directory Changes All) peut usurper l’identité d’un contrôleur de domaine et demander la réplication du hachage de n’importe quel compte. La commande lsadump::dcsync de Mimikatz réalise cette attaque entièrement sur le réseau : aucun code ne doit s’exécuter directement sur le DC.

La détection de l’utilisation de Golden Tickets est difficile, mais possible en recherchant des anomalies dans les métadonnées des tickets Kerberos : des tickets dont la durée de validité est inhabituelle (les tickets réels ont une durée de validité de 10 heures pour le TGT, tandis que les Golden Tickets sont souvent configurés pour 10 ans) ; Event ID 4769 où le type de chiffrement du ticket est RC4 (0x17) alors que la valeur par défaut du domaine est AES-256 (0x12) ; des noms de comptes dans les tickets qui n’existent pas dans AD ; et l’absence d’Event ID 4768 (demande de TGT) avant Event ID 4769 (demande de ticket de service) — les Golden Tickets ignorent la phase de demande du TGT puisque le TGT lui-même est falsifié. Une règle Microsoft Sentinel ou Defender for Identity peut signaler automatiquement ces schémas.

Une défense en profondeur contre les attaques Kerberos consiste à : utiliser gMSA pour tous les comptes de service afin de rendre Kerberoasting irréalisable ; activer le chiffrement AES uniquement pour tous les comptes, en particulier les comptes de service à forte valeur, afin de maximiser la difficulté du cassage ; restreindre les privilèges DCSync — auditer les comptes disposant d’autorisations de réplication et supprimer celles qui ne sont pas nécessaires ; activer Microsoft Defender for Identity (anciennement ATA), qui fournit une détection des menaces adaptée à Kerberos, notamment des alertes en temps réel concernant Golden Ticket, Kerberoasting et DCSync ; et mettre en œuvre un modèle d’administration par niveaux afin que, même si un compte de niveau 2 est compromis, il ne puisse pas servir à atteindre des identifiants de niveau DC.

Dans cette leçon, vous avez appris que : Kerberoasting demande des tickets de service pour les comptes enregistrés avec un SPN et les casse hors ligne — cette attaque est neutralisée par gMSA, des mots de passe robustes et le chiffrement AES uniquement ; les attaques Golden Ticket utilisent le hachage KRBTGT pour falsifier des TGT illimités, offrant un contrôle persistant du domaine jusqu’à la réinitialisation deux fois du mot de passe KRBTGT ; et les attaques DCSync répliquent le hachage KRBTGT sur le réseau sans exécuter de code sur le DC, ce qui exige un audit strict des privilèges DCSync. Nous allons maintenant étudier le référentiel MITRE ATT&CK pour associer les techniques des attaquants aux mesures de défense.