Kerberos : tickets et confiance

Pourquoi Kerberos est le cœur de tout pentest AD

Vous ne pouvez pas attaquer sérieusement un environnement Active Directory sans comprendre Kerberos. Ce n'est pas une couche décorative posée sur NTLM : c'est le protocole d'authentification par défaut du domaine depuis Windows 2000, et la quasi-totalité des techniques offensives que vous croiserez dans ce parcours — Kerberoasting, AS-REP Roasting, Golden Ticket, Silver Ticket, délégation abusée — reposent sur une exploitation précise d'un mécanisme du protocole, pas sur une vulnérabilité logicielle classique. Ce chapitre pose les fondations : les acteurs, les échanges, les objets cryptographiques manipulés (TGT, TGS, SPN, PAC), et la question, trompeusement anodine, de la synchronisation des horloges.

Vous devez sortir de ce chapitre capable de dessiner de mémoire le flux AS-REQ / AS-REP / TGS-REQ / TGS-REP / AP-REQ, et d'expliquer pourquoi chaque ticket est chiffré avec une clé différente. Cette compréhension conditionne tous les chapitres suivants du parcours.

Les trois acteurs et le principe de confiance mutuelle

Kerberos met en scène trois parties :

• Le client — l'utilisateur ou le compte de service qui souhaite accéder à une ressource
• Le KDC (Key Distribution Center) — hébergé sur chaque contrôleur de domaine, il combine deux services logiques : l'AS (Authentication Service) qui délivre le ticket initial, et le TGS (Ticket Granting Service) qui délivre les tickets de service
• Le service cible — une ressource identifiée par un SPN (partage de fichiers, base SQL, service web, contrôleur de domaine lui-même via LDAP ou CIFS)

Le principe fondateur est celui d'une confiance tierce : client et service ne se font pas confiance directement, ils font tous deux confiance au KDC. Chacun partage un secret à long terme avec le KDC (dérivé du mot de passe du compte), jamais avec l'autre partie. C'est ce qui permet à un service de vérifier l'identité d'un client sans jamais contacter le contrôleur de domaine au moment de la requête — le ticket suffit, parce qu'il a été chiffré par le KDC avec la clé du service.

Retenez ce point, il structure toute la suite : un ticket Kerberos n'est jamais chiffré avec la clé de celui qui le présente, mais avec celle de celui qui doit le lire.

Le TGT : authentification initiale (AS-REQ / AS-REP)

Tout commence par un échange avec l'AS. Le client envoie une AS-REQ contenant son identité et, dans l'implémentation standard avec pré-authentification activée, un horodatage chiffré avec la clé dérivée de son mot de passe (le fameux hash NT). Le KDC déchiffre cet horodatage avec la copie qu'il détient de cette même clé (issue de la base NTDS.dit) : s'il obtient une valeur temporelle cohérente, l'identité est confirmée sans que le mot de passe n'ait jamais transité sur le réseau.

En retour, le KDC émet une AS-REP qui contient deux éléments distincts :

1. Une partie chiffrée avec la clé du client, contenant la clé de session à utiliser pour les échanges avec le TGS
2. Le TGT (Ticket Granting Ticket) lui-même, chiffré avec la clé du compte KRBTGT — jamais avec la clé du client

Le TGT est donc opaque pour le client qui le porte : il ne peut ni le lire ni le modifier, il ne fait que le transporter et le représenter lors des demandes suivantes. C'est précisément cette propriété qui rend possible l'attaque du Golden Ticket, traitée dans un chapitre ultérieur : quiconque connaît le hash du compte KRBTGT peut forger un TGT valide pour n'importe quelle identité, puisque c'est la seule clé qui compte pour la validation.

Une commande comme getTGT.py (Impacket) ou asktgt (Rubeus) réalise exactement cet échange AS-REQ/AS-REP et vous restitue un fichier .ccache ou .kirbi contenant le TGT chiffré. Vous ne « voyez » jamais le contenu du TGT en clair : vous manipulez un blob opaque que seul le KRBTGT peut déchiffrer.

Le TGS : obtenir l'accès à un service (TGS-REQ / TGS-REP)

Muni de son TGT, le client peut désormais demander l'accès à un service précis sans se réauthentifier. Il envoie une TGS-REQ au TGS, en présentant le TGT et en précisant le SPN de la ressource visée. Le TGS déchiffre le TGT avec la clé KRBTGT, en extrait les informations d'identité et de groupes, puis émet une TGS-REP contenant le TGS (ticket de service) — chiffré cette fois avec la clé du compte propriétaire du SPN.

C'est cette bascule de clé de chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire, d'un échange à l'autre, qui rend Kerberos aussi intéressant à attaquer : chaque ticket de service est chiffré avec un secret différent (celui du compte de service), et un attaquant qui obtient ce ticket peut tenter de le casser hors ligne pour retrouver le mot de passe du compte. C'est le principe même du Kerberoasting — mais vous étudierez cette attaque dans un chapitre dédié ; l'objectif ici est de comprendre pourquoi elle fonctionne au niveau protocolaire.

Le TGS est ensuite présenté directement au service dans un message AP-REQ. Le service, connaissant sa propre clé, déchiffre le ticket localement, vérifie l'horodatage et l'authentificateur, et accorde l'accès — sans jamais contacter le contrôleur de domaine à ce stade. C'est un point souvent mal compris : l'autorisation finale se fait côté service, en local, sur la seule foi du ticket.

SPN : l'identifiant qui relie un service à un compte

Le SPN (Service Principal Name) est la clé de voûte de la phase TGS. Il identifie de façon unique une instance de service sur un hôte donné, sous la forme classe-de-service/nom-hôte:port, par exemple MSSQLSvc/sql01.corp.local:1433 ou HTTP/intranet.corp.local. Chaque SPN est enregistré sur un compte AD — un compte machine dans le cas courant, ou un compte utilisateur dédié pour les services qui nécessitent une identité stable (comptes de service SQL, IIS, applicatifs tiers).

C'est cet enregistrement qui rend le Kerberoasting possible : n'importe quel utilisateur authentifié du domaine peut demander un TGS pour n'importe quel SPN enregistré, sans droit particulier sur le compte cible. Le ticket obtenu est chiffré avec le hash du mot de passe du compte de service — et si ce compte a un mot de passe faible ou statique depuis des années (fréquent pour les comptes de service historiques), le craquage hors ligne devient une question de temps de calcul, pas de privilège.

Une simple requête LDAP non privilégiée (GetUserSPNs.py, setspn -Q, ou un Get-ADUser -Filter {ServicePrincipalName -ne "$null"}) suffit à énumérer tous les comptes porteurs d'un SPN. En reconnaissance, considérez systématiquement cette liste comme votre carte des cibles Kerberoastables potentielles, avant même de connaître les mots de passe.

Le PAC : au-delà de l'authentification, l'autorisation

Le TGT et le TGS prouvent une identité, mais Kerberos seul ne dit rien des droits associés. C'est le rôle du PAC (Privilege Attribute Certificate), une extension propriétaire Microsoft insérée dans les tickets et signée par le KDC. Le PAC embarque le SID de l'utilisateur, la liste de ses appartenances aux groupes (y compris les groupes universels et les SID history), et d'autres attributs d'autorisation.

Le service qui reçoit un AP-REQ peut donc, en théorie, faire confiance au contenu du PAC pour ses décisions d'autorisation sans requête supplémentaire vers un contrôleur de domaine — c'est l'optimisation que Microsoft a voulu apporter à un protocole qui, historiquement, ne gérait que l'authentification. Mais cette confiance repose entièrement sur la validité des deux signatures du PAC (une signature serveur avec la clé KRBTGT, une signature KDC), que tous les services ne vérifient pas systématiquement — c'est précisément la faille exploitée par certaines variantes de falsification de PAC et par le Golden Ticket, où un attaquant en possession du hash KRBTGT peut construire un PAC mentionnant une appartenance au groupe Domain Admins pour un compte qui n'y appartient pas réellement.

Certains outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire offensifs (par exemple les implémentations forgeant des tickets) génèrent des PAC minimalistes ou légèrement incohérents. Cela n'empêche généralement pas l'attaque de fonctionner, la plupart des services ne validant pas rigoureusement chaque champ, mais laisse des artefacts détectables par une supervision qui compare le PAC aux donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire réelles de l'annuaire.

Clock skew : la synchronisation temporelle, un prérequis silencieux

Kerberos utilise l'horodatage comme mécanisme anti-rejeu : chaque requête embarque un timestamp chiffré, et le KDC (ou le service) rejette toute requête dont l'horodatage s'écarte trop de l'heure locale. Par défaut sur un domaine Windows, cette tolérance — le clock skew — est fixée à 5 minutes via la stratégie de groupe Maximum tolerance for computer clock synchronization.

Ce détail, en apparence purement opérationnel, a des conséquences directes en pentest :

• Un poste d'attaque désynchronisé de plus de 5 minutes par rapport au KDC verra toutes ses requêtes Kerberos rejetées avec une erreur KRB_AP_ERR_SKEW, y compris des attaques par ailleurs correctement construites
• Les machines virtuelles de test, les conteneurs, ou les postes isolés du réseau (donc sans synchronisation NTP vers le contrôleur de domaine) sont les cas les plus fréquents de désynchronisation
• Un ticket forgé (Golden Ticket, Silver Ticket) doit intégrer un horodatage cohérent avec l'heure du domaine, faute de quoi il sera rejeté avant même que sa signature soit examinée

Avant toute opération Kerberos depuis un poste d'attaque, synchronisez l'horloge sur le contrôleur de domaine cible : sudo ntpdate -u <ip-DC> ou sudo rdate -n <ip-DC> sous Linux, w32tm /resync sous Windows. C'est l'une des causes d'échec les plus fréquentes et les plus mal diagnostiquées en début d'engagement — un message d'erreur cryptique masque un simple problème d'horloge.

Pièges de compréhension fréquents chez les pentesters

Quelques confusions reviennent régulièrement, y compris chez des testeurs expérimentés :

Ces confusions ne sont pas de simples détails théoriques : elles déterminent directement quelle attaque est pertinente dans quel contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, et surtout ce qu'un ticket volé ou forgé vous permet réellement de faire une fois en votre possession.

Ce qu'il faut retenir avant d'attaquer

Avant d'aborder les chapitres suivants sur le Kerberoasting, l'AS-REP Roasting ou la fabrication de tickets, assurez-vous de maîtriser ces quatre points :

1. Un ticket est toujours chiffré avec la clé de celui qui doit le lire, jamais avec celle de celui qui le présente
2. Le TGT dépend de la clé KRBTGT, le TGS dépend de la clé du compte de service : ce sont deux surfaces d'attaque distinctes
3. Le PAC porte l'autorisation (groupes, SID) et sa validité repose sur des signatures que tous les services ne vérifient pas rigoureusement
4. La tolérance d'horloge par défaut est de 5 minutes : une désynchronisation est souvent la cause silencieuse d'un échec d'attaque par ailleurs correcte

Chaque attaque des chapitres suivants exploite une propriété précise décrite ici : le Kerberoasting exploite la clé du SPN dans le TGS, l'AS-REP Roasting exploite l'absence de pré-authentification dans l'AS-REQ, et le Golden Ticket exploite la confiance absolue accordée à quiconque détient la clé KRBTGT. Revenez à ce chapitre si un mécanisme vous échappe : la suite du parcours suppose cette base acquise.