Pentest Active Directory : Kerberoasting Pas a Pas dans un Lab GOAD

Le Kerberoasting est lattaque qui paie le loyer sur presque chaque engagement interne, car il ne demande rien de plus quun seul compte de domaine valide et transforme des tickets de service demandes en silence en cassage de mot de passe hors ligne, sans privilege special et sans exploit bruyant. Dans ce guide vous montez un lab avec GOAD, le Game of Active Directory dOrange Cyberdefense, et deroulez la chaine complete: comprendre comment Kerberos emet des tickets, enumerer les service principal names, demander les tickets, les casser hors ligne avec hashcat puis fermer la boucle avec la detection et le hardening qui larretent vraiment. Tout tourne contre vos propres controleurs de domaine, dans un reseau isole, sous autorisation ecrite; le but est la maitrise du mecanisme, pas un trophee.

Comment fonctionne lauthentification Kerberos

Kerberos est un protocole a tickets avec trois parties: le client, le Key Distribution Center qui vit sur le controleur de domaine, et le service. Dabord le client prouve qui il est avec un AS-REQ et recoit un Ticket Granting Ticket, chiffre avec la cle du compte krbtgt pour que seul le KDC le lise. Quand le client veut atteindre un service, il presente le TGT dans un TGS-REQ et demande un ticket de service; le KDC repond avec un TGS chiffre avec la cle propre du compte de service, derivee du mot de passe de ce compte. Le client remet ce ticket au service, qui le dechiffre pour prouver lautorisation. Le detail critique est que le KDC donne a tout utilisateur authentifie un ticket de service pour nimporte quel service, et ce ticket est chiffre avec une cle derivee dun mot de passe choisi par un humain.

Pourquoi le Kerberoasting marche

Ce seul fait de conception est toute la vulnerabilite. Nimporte quel utilisateur de domaine peut demander un TGS pour tout compte ayant un Service Principal Name enregistre, et le ticket retourne est chiffre avec la cle derivee du mot de passe du compte de service. Emportez le ticket hors ligne et vous pouvez brute-forcer le mot de passe sans jamais retoucher le domaine, car la verification a lieu sur votre propre materiel. Cela empire quand le ticket revient en RC4 (etype 23, le hash $krb5tgs$23$), qui casse bien plus vite quAES. Les comptes de service sont les victimes parfaites: ils portent souvent des mots de passe faibles, anciens et fixes par un humain, tournent rarement, et sont frequemment sur-privilegies parce que quelquun leur a donne domain admin il y a des annees pour faire marcher un installeur.

Construire le lab GOAD

GOAD livre une foret Active Directory multi-domaine deliberement vulnerable, batie pour exactement cet exercice. Provisionnez-la avec Ludus ou par la voie Vagrant et Ansible sur un hyperviseur avec assez de RAM, car une foret realiste veut plusieurs VMs Windows Server et un hote dattaque Kali ou Windows. Gardez tout lenvironnement sur un reseau isole sans route vers la production ni internet, car GOAD est intentionnellement faible et ne doit jamais toucher quoi que ce soit de reel. Une fois les controleurs de domaine en marche et un compte de domaine a faible privilege en main, vous avez la position de depart exacte dun attaquant qui vient de phisher un seul utilisateur du helpdesk, le point dentree realiste que le Kerberoasting est concu pour exploiter.

Enumeration: trouver les comptes de service

On ne rotit pas ce quon ne voit pas, donc enumerez dabord les comptes portant un SPN. Depuis Windows, setspn -T domain -Q */* liste les service principal names enregistres, tandis que Get-DomainUser -SPN de PowerView filtre directement les comptes utilisateur avec un SPN, les cibles cassables. Depuis Linux, un ldapsearch authentifie sur servicePrincipalName=* fait de meme. Injectez le domaine dans BloodHound et il liste non seulement les utilisateurs kerberoastables mais montre lesquels appartiennent a des groupes de grande valeur, pour que vous priorisiez le compte de service qui se trouve aussi dans Domain Admins. Notez les types de chiffrement supportes par chaque compte; un compte autorisant encore RC4 est la cible la plus molle du plateau.

Demander et extraire les tickets

Cibles choisies, demandez les tickets. Depuis un foothold Windows, Rubeus.exe kerberoast /outfile:hashes.txt demande un TGS pour chaque compte kerberoastable et ecrit les hashes en format cassable; ajoutez /tgtdeleg ou filtrez par utilisateur pour rester discret. Depuis Linux avec Impacket, GetUserSPNs.py DOMAIN/user:password -dc-ip 10.0.0.10 -request fait de meme en une commande et deverse les blobs $krb5tgs$. Si vous pouvez, ciblez volontairement les comptes qui repondent en hashes RC4; si le KDC renvoie AES etype 18 ($krb5tgs$18$), vous pouvez tout de meme le casser, juste bien plus lentement. Chaque hash collecte est maintenant totalement detache du reseau, cest exactement pour cela que letape suivante se passe sur votre propre machine.

Casser les tickets hors ligne

Hors ligne, le Kerberoasting devient cruel. Donnez les hashes a hashcat avec le mode -m 13100 pour les tickets TGS RC4 ou -m 19700 pour AES, pointez-le sur une wordlist solide comme rockyou plus des regles ciblees, et laissez le GPU travailler. Un mot de passe de service faible tombe en secondes; un mot de passe humain de douze caracteres a structure previsible tombe souvent en heures. Comme la verification est locale, il ny a ni verrouillage, ni rate limit, ni entree de log dans le domaine pour vous trahir. Cette asymetrie est tout lenjeu: la politique de mots de passe du defenseur est la seule chose entre un unique compte a faible privilege et une credential de service cassee qui peut detenir bien plus dacces que le compte de depart.

Post-crack: transformer un mot de passe en pouvoir de domaine

Un compte de service casse est rarement la fin; cest un pivot. Connectez-vous en tant que compte de service et relancez BloodHound depuis son contexte pour mapper ce quil peut atteindre, car les comptes de service detiennent couramment ladmin local sur beaucoup de serveurs ou siegent dans des groupes privilegies. Si le compte est un service SQL ou de sauvegarde, il possede peut-etre des chemins vers un controleur de domaine via delegation ou abus de DACL. Voila pourquoi le Kerberoasting est si prise en engagement reel: il convertit la position de depart la plus faible possible, un utilisateur ordinaire, en credentials provisionnees pour des machines et donc bien plus fiables que ne devrait letre aucun compte humain.

Detection: la vue du defenseur

Chaque Kerberoast laisse une trace si vous la guettez. LEvent ID 4769 de Windows enregistre chaque requete TGS, et le revelateur est le champ de type de chiffrement: une rafale devenements 4769 avec type de chiffrement 0x17 (RC4) dun seul utilisateur contre de nombreux services distincts dans une courte fenetre est la signature dune session de rotissage. Alertez sur ce motif dans votre SIEM plutot que sur des evenements individuels, car un 4769 est normal et mille en une minute ne lest pas. La detection unique la plus forte est un SPN honeypot: creez un compte de service leurre avec un SPN, ne lutilisez jamais, et declenchez une alerte de severite haute a linstant ou quelquun demande son ticket, car aucun processus legitime ne le fera jamais.

Mitigation et hardening

Le correctif vise la cassabilite, pas la requete. Remplacez les comptes de service geres par des humains par des group Managed Service Accounts, dont les mots de passe de 240 caracteres generes par la machine tournent automatiquement et sont pratiquement impossibles a casser hors ligne. La ou un gMSA nest pas encore possible, imposez un mot de passe tres long et aleatoire sur chaque compte de service et faites-le tourner. Desactivez RC4 sur tout le domaine pour que les tickets ne reviennent quen AES, ce qui augmente le cout de cassage de plusieurs ordres de grandeur, et auditez chaque compte de service pour tout privilege inutile afin quune credential cassee ne mene nulle part. Posez le SPN honeypot et la detection 4769 par-dessus, et vous avez reduit a la fois les chances dun cassage reussi et le rayon dimpact sil arrive.

Pieges et une checklist

Les erreurs courantes coupent des deux cotes. Les attaquants se font prendre en demandant tous les tickets dun coup au lieu de doser et cibler, ou perdent des jours a casser un hash AES quils auraient pu sauter pour un RC4. Les defenseurs se croient surs parce quils ont impose une politique de mots de passe aux utilisateurs tandis que leurs comptes de service portent encore un mot de passe vieux dune decennie et RC4 active. Avant de declarer le domaine durci, confirmez quaucun compte utilisateur nautorise RC4, que chaque compte de service est un gMSA ou porte un mot de passe long et aleatoire, quun SPN honeypot existe et alerte, que la detection danomalie 4769 est active, et quaucun compte kerberoastable ne siege dans un groupe privilegie. Prouvez-le en rotissant votre propre domaine et en voyant le honeypot se declencher.

Un cousin proche: lAS-REP roasting

Une fois le Kerberoasting assimile, son frere ne coute presque rien a ajouter. LAS-REP roasting vise les comptes avec la pre-authentification Kerberos desactivee, un reglage qui laisse le KDC renvoyer un AS-REP chiffre avec la cle derivee du mot de passe de lutilisateur avant que celui-ci nait rien prouve. Cela signifie que vous pouvez demander le blob dun tel compte sans aucune credential et le casser hors ligne exactement comme un TGS. Enumerez les victimes avec Get-DomainUser -PreauthNotRequired dans PowerView ou GetNPUsers.py dans Impacket, puis donnez le hash $krb5asrep$ obtenu au mode -m 18200 de hashcat. Lhistoire defensive est identique dans lesprit: ne desactivez jamais la pre-authentification, imposez des mots de passe forts et alertez sur la requete anormale. Enchainer les deux attaques dans GOAD vous apprend que toute la famille des bugs de roasting se ramene a la meme racine, une cle de chiffrement derivee dun mot de passe humain faible que nimporte qui peut demander.

FAQ

Ai-je besoin de droits admin pour Kerberoaster? Non, et cest justement ce qui le rend dangereux. Tout compte de domaine authentifie peut demander des tickets de service et les emporter hors ligne; aucune elevation, aucun exploit et aucun acces special requis, cest pourquoi cest lun des premiers coups apres tout foothold.

Activer AES arrete-t-il totalement le Kerberoasting? Non, cela le rend bien plus difficile, pas impossible. Les tickets AES peuvent toujours etre demandes et casses, juste bien plus lentement, donc un mot de passe de service faible reste vulnerable meme sous AES. Le correctif durable, ce sont les mots de passe gMSA quaucune wordlist natteindra, combines au moindre privilege pour quun cassage ne rapporte rien.

A retenir en pratique: montez GOAD, deroulez la chaine une fois dun seul compte a faible privilege jusqua un ticket de service casse puis un pivot privilegie, puis passez du cote bleu et batissez le SPN honeypot et la detection 4769 jusqua ce que votre propre rotissage les allume. Le Kerberoasting nest pas une technique exotique; cest une consequence de conception de Kerberos rencontrant des mots de passe de service faibles. Passez au gMSA, tuez RC4, retirez les privileges et guettez la requete, et vous transformez un jour de paie fiable de lattaquant en impasse.