Kerberos et le Kerberoasting : comprendre le principe

Kerberos est le protocole d'authentification au cœur d'Active Directory. Il est élégant, robuste, et pourtant certaines de ses propriétés, combinées à de mauvaises habitudes d'administration, ouvrent des attaques célèbres, dont le « Kerberoasting ». Cette leçon explique le fonctionnement de Kerberos avec une analogie, puis le principe de cette attaque, uniquement de façon conceptuelle, pour que vous sachiez la reconnaître et la prévenir.

Kerberos expliqué par une analogie

Imaginez un parc d'attractions. À l'entrée, vous montrez une pièce d'identité à l'accueil, qui vous remet un bracelet valable toute la journée. Ensuite, à chaque attraction, vous ne remontrez pas votre pièce d'identité : vous présentez le bracelet pour obtenir un billet propre à l'attraction. Le guichet n'a pas besoin de vous reconnaître : il fait confiance à l'accueil qui a émis le bracelet.

Kerberos fonctionne de la même façon, avec trois acteurs :

• Le client : vous, ou plutôt votre poste de travail.
• Le centre de distribution de clés (KDC) : un service du contrôleur de domaine, qui joue le rôle de l'accueil et du guichet.
• Le service : le serveur de fichiers, la base de données ou l'application que vous voulez utiliser.

Le déroulement simplifié est le suivant :

1. Vous prouvez votre identité au KDC (par votre mot de passe, sans qu'il circule en clair) et recevez un ticket d'octroi de tickets (TGT), le « bracelet ».
2. Quand vous voulez accéder à un service, vous présentez votre TGT au KDC et demandez un ticket de service, le « billet ».
3. Vous présentez ce ticket de service au service, qui peut le vérifier parce qu'il est chiffré avec un secret que seuls le KDC et ce service connaissent.

Ce mécanisme évite de transmettre le mot de passe sur le réseau à chaque connexion, et permet l'ouverture de session unique : vous vous authentifiez une fois, puis vous accédez à plusieurs services.

Les comptes de service et les SPN

Pour que le KDC sache quel secret utiliser pour chiffrer le ticket d'un service donné, chaque service est rattaché à un compte dans l'annuaire, et identifié par un nom appelé SPN (service principal name). Quand un service fonctionne sous un compte dédié (un « compte de service »), la clé qui chiffre ses tickets est dérivée du mot de passe de ce compte.

Deux choses sont à retenir ici, car elles sont à l'origine du problème :

• Un utilisateur authentifié, même sans aucun privilège, peut demander un ticket de service pour n'importe quel SPN. C'est normal : le KDC ne sait pas à l'avance quels services vous comptez utiliser.
• Une partie de ce ticket est chiffrée avec une clé issue du mot de passe du compte de service.

Le principe du Kerberoasting

Réunissons les deux idées. Un attaquant qui contrôle un compte ordinaire peut demander des tickets de service pour des comptes de service, puis les emporter hors du réseau. Le ticket est une sorte de coffre-fort dont la clé est le mot de passe du compte de service. L'attaquant peut alors, sur sa propre machine, tenter des mots de passe en boucle et vérifier lequel ouvre le coffre-fort. Cette attaque s'appelle un craquage hors ligne : elle ne génère aucun trafic vers l'organisation une fois les tickets récupérés, donc aucune alerte de verrouillage de compte.

Le point crucial est que la réussite dépend presque entièrement de la qualité du mot de passe du compte de service. Si ce mot de passe est court, prévisible ou ancien (« Service2019! »), il tombera vite. S'il est long, aléatoire et unique, la même attaque devient pratiquement inopérante. Le Kerberoasting n'est donc pas une « faille » du protocole au sens strict ; c'est l'exploitation de la combinaison fonctionnement normal de Kerberos + mot de passe faible sur un compte de service.

Pourquoi les comptes de service sont-ils souvent faibles ? Parce qu'ils sont créés un jour pour une application, que personne n'ose changer leur mot de passe de peur de casser un service, et qu'ils reçoivent souvent des droits trop étendus « pour que ça marche ». Un mot de passe ancien associé à des privilèges élevés est la combinaison la plus dangereuse.

Une famille d'attaques voisines

Sans rentrer dans le détail, sachez qu'il existe d'autres scénarios fondés sur la même idée : exploiter une propriété normale de Kerberos lorsqu'un compte est mal configuré. Par exemple, certains comptes peuvent avoir la préauthentification désactivée (un réglage rare, parfois conservé pour d'anciennes applications) : leur ticket initial peut alors être demandé sans prouver son identité, avec le même risque de craquage hors ligne. Retenez la leçon générale : les attaques Kerberos s'attaquent aux mauvaises pratiques de gestion des comptes, pas au chiffrement lui-même.

Comment s'en protéger et le détecter

La bonne nouvelle est que les défenses sont connues, et plutôt peu coûteuses :

• Des mots de passe très longs et aléatoires pour les comptes de service (plusieurs dizaines de caractères), gérés par un coffre-fort ou, mieux, par des comptes de service gérés (gMSA), dont le mot de passe est généré et renouvelé automatiquement par le système.
• Le moindre privilège : un compte de service n'a besoin que des droits de son application, jamais ceux d'un administrateur du domaine.
• Un chiffrement moderne : privilégier les algorithmes récents plutôt que les anciens, qui offrent moins de résistance au craquage.
• Un inventaire : savoir quels comptes ont des SPN, à quoi ils servent, qui en est responsable. Supprimer ceux qui ne servent plus.
• La détection : les contrôleurs de domaine journalisent les demandes de tickets (les événements de type 4768 pour les TGT et 4769 pour les tickets de service sous Windows). Un compte qui demande en peu de temps des tickets pour de nombreux services différents est suspect. Les équipes de supervision (le « blue team », notre chapitre 3) bâtissent des règles autour de ce comportement.

Le lien avec MITRE ATT&CK

Les attaquants et défenseurs décrivent ces comportements avec un vocabulaire commun : le framework MITRE ATT&CK (attack.mitre.org), que nous étudierons au chapitre 4, répertorie une technique de « vol ou forge de tickets Kerberos », dont ce scénario fait partie. Y rattacher votre constat dans un rapport permet à n'importe quel professionnel de comprendre immédiatement de quoi vous parlez et de quelles mesures s'inspirer.

À vous de jouer

Mise en situation. Dans l'annuaire fictif d'Atelier Boréal, un audit de laboratoire relève trois comptes de service :

Classez ces trois comptes du plus urgent au moins urgent à corriger, et justifiez en une phrase.