Kerberos et KDC dans Active Directory, attaques et durcissement

Kerberos authentifie un utilisateur une fois auprès d’un tiers de confiance, le KDC (Key Distribution Center), puis lui remet des tickets pour chaque service, sans que le mot de passe ne circule sur le réseau. Dans Active Directory, c’est le protocole d’authentification par défaut. C’est aussi la cible préférée de quiconque a déjà un pied dans le domaine. Le protocole tient bien depuis des décennies ; ce qui cède, c’est presque toujours la gestion des clés qui l’entoure.

→ Lire l’explication complète de la marmotte

Principe de Kerberos v5 : tiers de confiance et tickets

Kerberos est né au MIT (Massachusetts Institute of Technology) dans le cadre du projet Athena. La version 5 est spécifiée par la RFC (Request for Comments) 4120, qui a remplacé la RFC 1510. Le modèle repose sur trois acteurs : un client, un service, et un KDC qui partage une clé secrète à long terme avec chacun d’eux. Pour un utilisateur, cette clé est dérivée de son mot de passe. Pour un service, elle est dérivée du mot de passe du compte qui l’exécute.

Le KDC remplit deux rôles logiques. L’AS (Authentication Service) vérifie l’identité et délivre un TGT (Ticket Granting Ticket). Le TGS (Ticket Granting Service) échange ce TGT contre des tickets de service. Un ticket est un bloc chiffré avec la clé de son destinataire. Le client le transporte sans pouvoir le lire, et il reçoit à côté une clé de session chiffrée pour lui seul.

Le compromis central est le suivant. On gagne une authentification unique, mutuelle si on le demande, sans secret rejoué sur le fil. En échange, on concentre toute la confiance dans une poignée de clés à long terme, dont une (celle du compte krbtgt) permet de signer n’importe quel TGT du domaine. Kerberos ne déplace pas le risque, il le concentre. C’est une bonne affaire uniquement si ces clés sont traitées comme les secrets les plus sensibles du système d’information.

Déroulé AS-REQ, TGS-REQ, AP-REQ et clés de session

Le schéma suit un utilisateur qui ouvre une session puis accède à un serveur de fichiers. Il faut regarder quelle clé chiffre quoi : c’est ce qui explique chaque attaque de la suite.

Quatre points méritent l’attention :

La pré-authentification. Dans l’AS-REQ (requête adressée au service d’authentification), le client chiffre un horodatage avec sa clé. Le KDC ne répond qu’après l’avoir déchiffré. Sans cette étape, n’importe qui peut obtenir un AS-REP (réponse du service d’authentification) contenant un bloc chiffré avec la clé de l’utilisateur, et l’attaquer hors ligne.
Le TGT est opaque pour le client. Il est chiffré avec la clé de krbtgt. Seul le KDC le lit. Le client ne connaît que la clé de session 1, valable pour la durée du TGT (10 heures par défaut dans AD, renouvelable 7 jours).
Le service ne contacte pas le KDC. Il déchiffre le ticket avec sa propre clé et fait confiance à son contenu. Cela rend Kerberos très efficace et ouvre la porte au ticket d’argent.
L’authentificateur porte un horodatage. Ce champ limite le rejeu, à condition que les horloges soient alignées.

Kerberos dans Active Directory : KDC, SPN et PAC

Dans AD (Active Directory), chaque contrôleur de domaine est un KDC (port 88 en TCP et UDP, 464 pour le changement de mot de passe). Il n’existe pas de KDC séparé à protéger : compromettre un contrôleur, c’est compromettre le KDC, et l’inverse aussi. La base de comptes du KDC est l’annuaire lui-même, consultable en LDAP (Lightweight Directory Access Protocol). Les pages sur la désactivation du simple bind en clair et sur l’énumération LDAP anonyme traitent ce versant.

SPN (Service Principal Name). Un client demande un ticket pour un nom de service de la forme classe/hôte, par exemple HTTP/web01.exemple.lan ou MSSQLSvc/sql01.exemple.lan:1433. Le KDC cherche le compte qui porte ce SPN et chiffre le ticket avec sa clé. Pour un service qui tourne sous le compte machine, cette clé est aléatoire et tourne d’elle-même. Pour un service qui tourne sous un compte utilisateur, elle est dérivée d’un mot de passe choisi par un humain, souvent en 2014, et jamais changé depuis « pour ne pas casser l’application ».

PAC (Privilege Attribute Certificate). Kerberos standard authentifie, il n’autorise pas. Microsoft ajoute au ticket une structure PAC qui contient les SID (Security Identifier) de l’utilisateur et de ses groupes, signée par le KDC. Le service construit le jeton d’accès Windows à partir de ce PAC. Deux conséquences en découlent. Un changement d’appartenance à un groupe n’a d’effet qu’au prochain ticket. Et quiconque peut forger un PAC accepté peut se donner n’importe quel groupe.

Délégation. Un service frontal a parfois besoin d’agir au nom de l’utilisateur auprès d’un service dorsal. AD propose trois modèles.

Non contrainte : le client transmet une copie de son TGT au serveur, qui peut alors l’utiliser vers n’importe quel service. Un serveur compromis avec ce réglage collecte les TGT de tous ceux qui s’y connectent, administrateurs compris. Il faut la proscrire en dehors des contrôleurs de domaine, où elle est de toute façon inhérente.
Contrainte : le serveur ne peut obtenir des tickets, via les extensions S4U (Service for User), que vers une liste de SPN déclarés sur son propre compte (attribut msDS-AllowedToDelegateTo). Avec la transition de protocole (S4U2Self), il peut le faire même si l’utilisateur ne s’est pas authentifié en Kerberos. C’est puissant, et donc à inventorier.
Basée sur les ressources, dite RBCD (Resource-Based Constrained Delegation) : c’est le service dorsal qui déclare quels comptes peuvent lui présenter des utilisateurs (attribut msDS-AllowedToActOnBehalfOfOtherIdentity). Le droit d’écrire cet attribut sur un objet ordinateur devient alors un chemin d’élévation de privilège. Les droits d’écriture sur les objets machines comptent donc autant que la délégation elle-même.

Le schéma résume le flux de la délégation contrainte. On y lit que le frontal n’a jamais le TGT de l’utilisateur, mais qu’il obtient pourtant un ticket à son nom.

Les comptes sensibles doivent porter l’option « Ce compte est sensible et ne peut pas être délégué », ou appartenir au groupe Protected Users. Les deux ferment toute délégation pour eux.

Horloge, DNS et contrôleurs de domaine : dépendances de Kerberos

Kerberos hérite de trois dépendances qui se comportent comme des composants de sécurité, même si personne ne les a inscrites au périmètre.

L’horloge. La tolérance de décalage par défaut dans AD est de 5 minutes. Au-delà, l’authentification échoue avec une erreur de décalage d’horloge. La chaîne NTP (Network Time Protocol) du domaine part de l’émulateur PDC (Primary Domain Controller), qui doit lui-même se caler sur une source fiable. Une source de temps manipulable devient un levier : on peut provoquer un déni de service sur l’authentification, ou étendre la fenêtre de validité apparente d’un ticket. L’éditorial sur l’heure comme dépendance de sécurité et la page sur la sécurisation de NTP développent ce point. Pour Kerberos, il faut retenir ceci : la source de temps de l’émulateur PDC est un actif de tier 0.

Le DNS (Domain Name System). Le client localise les KDC par enregistrements SRV (localisation de service) et construit le SPN à partir du nom de l’hôte visé. Un alias mal déclaré ou un accès par adresse IP ne trouve pas de SPN correspondant. Windows retombe alors silencieusement sur NTLM (NT LAN Manager) par défaut. Une bonne part du NTLM résiduel d’un parc vient de là, et non d’applications réellement incompatibles.

La disponibilité des contrôleurs. Sans KDC joignable, aucun nouveau ticket n’est délivré. Les tickets en cache tiennent jusqu’à leur expiration, ce qui masque une panne pendant quelques heures puis la révèle d’un coup. Il faut au moins deux contrôleurs par site critique, et superviser la réplication : un mot de passe changé sur un contrôleur et pas encore répliqué produit des échecs intermittents, impossibles à reproduire au moment où on regarde.

Attaques Kerberos : Kerberoasting, AS-REP roasting, pass-the-ticket, tickets d’argent et d’or

Aucune de ces attaques ne casse le protocole. Toutes exploitent une clé faible, une clé volée ou un ticket volé. La page sur les délégations et chemins d’attaque d’Active Directory replace ces techniques dans le graphe du domaine. Ici, on s’en tient à ce qui les rend possibles et à ce qui les ferme.

Attaque	Ce qui la rend possible	Ce qui la ferme
Kerberoasting	Tout compte authentifié peut demander un ticket de service pour n’importe quel SPN. Le ticket est chiffré avec la clé du compte de service, qu’on attaque hors ligne. RC4 et un mot de passe court rendent l’attaque rapide.	gMSA, ou mot de passe aléatoire long (25 caractères ou plus). AES seul sur le compte. Aucun SPN sur un compte privilégié.
AS-REP roasting	Un compte avec l’option « ne pas demander la pré-authentification Kerberos » (`DONT_REQ_PREAUTH`) livre un bloc chiffré avec sa clé à quiconque le demande.	Retirer cette option partout ; la justification « appli legacy » se revérifie à chaque fois. Mots de passe longs pour les rares exceptions.
Pass-the-ticket	Un TGT ou un ticket de service extrait de la mémoire d’une machine compromise est réutilisable ailleurs jusqu’à son expiration.	Ne pas exposer de comptes privilégiés sur des machines de tier inférieur. Protected Users (TGT de 4 heures). Postes d’administration dédiés.
Ticket d’argent	La clé d’un compte de service permet de forger un ticket de service, avec un PAC arbitraire, sans jamais contacter le KDC.	Rotation des secrets de service (gMSA, comptes machines). Validation du PAC quand le service la supporte. Détection côté service, puisque le KDC ne voit rien.
Ticket d’or	La clé de krbtgt permet de forger un TGT pour n’importe quelle identité, avec n’importe quels groupes et une durée arbitraire.	Protéger les contrôleurs de domaine comme tier 0. Après compromission, double réinitialisation de krbtgt.

Deux remarques que les supports de formation omettent souvent. D’abord, le Kerberoasting ne requiert aucun privilège : un stagiaire authentifié suffit, et la demande de ticket est un comportement parfaitement normal. On ne peut donc pas l’empêcher, seulement le rendre inutile par la force du secret. Ensuite, le ticket d’or n’est pas une attaque mais un constat. Si la clé de krbtgt est sortie, le domaine est perdu jusqu’à preuve du contraire, et la question devient celle de la reconstruction, pas celle de la détection.

Durcissement de Kerberos : gMSA, AES, krbtgt et Protected Users

L’ordre de priorité qui suit va du meilleur rapport risque fermé sur effort au moins bon.

Comptes de service gérés. Le gMSA (group Managed Service Account, depuis Windows Server 2012) porte un mot de passe aléatoire de 240 octets, que le domaine renouvelle automatiquement (30 jours par défaut) et qu’aucun humain ne connaît. Il rend le Kerberoasting inopérant. Quand l’application ne le supporte pas, il faut un mot de passe aléatoire long, stocké dans un coffre et tourné par outillage : voir coffre de secrets et enregistrement.
AES partout, RC4 nulle part. L’attribut msDS-SupportedEncryptionTypes des comptes et la stratégie « Configurer les types de chiffrement autorisés pour Kerberos » fixent les algorithmes acceptés. RC4-HMAC dérive sa clé du condensat NT sans sel ni itérations. Une clé RC4 se casse donc bien plus vite qu’une clé AES (Advanced Encryption Standard), et elle est identique au condensat utilisé par NTLM. Avant de couper RC4, il faut mesurer qui le demande encore (voir l’exemple plus bas). Couper à l’aveugle casse d’abord les vieux appliances, puis la confiance de l’équipe envers le projet.
Pré-authentification et blindage. Supprimer DONT_REQ_PREAUTH, puis activer le blindage Kerberos, dit FAST (Flexible Authentication Secure Tunneling, RFC 6113). Il protège l’échange AS dans un tunnel et empêche l’attaque hors ligne de la pré-authentification capturée.
Protected Users. Pour les membres de ce groupe : pas de NTLM, pas de DES ni RC4 en pré-authentification, pas de délégation, TGT limité à 4 heures. On y place tous les comptes d’administration, après un test, car un compte de service placé là cesse de fonctionner. C’est le comportement attendu, pas un bogue.
Délégation. Inventorier la délégation non contrainte hors contrôleurs (la cible est zéro), la délégation contrainte avec transition de protocole, et les droits d’écriture sur msDS-AllowedToActOnBehalfOfOtherIdentity.
krbtgt. Rotation régulière en temps normal. Après compromission, deux réinitialisations, séparées d’au moins la durée de vie maximale d’un TGT et d’une réplication complète. La raison : le KDC accepte encore les tickets chiffrés avec le mot de passe précédent. Une seule réinitialisation laisse donc la clé volée valide. Deux réinitialisations enchaînées sans attendre invalident en revanche tous les TGT légitimes d’un coup, et le support n’oubliera pas cette matinée.
Supervision. Les événements 4768 (demande de TGT), 4769 (demande de ticket de service) et 4771 (échec de pré-authentification) sur les contrôleurs, collectés dans le SIEM (Security Information and Event Management). Le champ « type de chiffrement du ticket » est le plus rentable : 0x17 désigne RC4-HMAC, 0x12 AES256. Un ticket RC4 demandé pour un compte qui supporte AES, ou une rafale de 4769 vers des SPN variés depuis un même poste, méritent une alerte. Le ticket d’argent reste invisible depuis le KDC, et il faut le rappeler à quiconque vend une détection « complète » des attaques Kerberos sur la seule base des journaux des contrôleurs.

Kerberos face à NTLM

Kerberos n’est pas parfait, mais il est nettement supérieur à NTLM. Il offre l’authentification mutuelle et la délégation contrôlée. Le service n’a pas besoin d’interroger le contrôleur à chaque connexion. Et il n’y a pas de défi-réponse relayable de la même manière. Microsoft a d’ailleurs annoncé l’abandon progressif de NTLM. La position à tenir : Kerberos par défaut, NTLM en exception inventoriée et datée, puis bloquée. La page NTLM, fonctionnement, vulnérabilités et durcissement détaille l’audit préalable. Le levier le plus efficace reste rarement l’application : ce sont les accès par IP et les SPN absents qui forcent le repli.

Ce que Kerberos ne garantit pas

La qualité du secret. Kerberos protège le mot de passe en transit, pas contre l’attaque hors ligne d’un ticket chiffré avec une clé faible.
La révocation immédiate. Désactiver un compte n’invalide pas ses tickets déjà émis côté service. Un ticket de service reste accepté jusqu’à son expiration, car le service ne consulte pas le KDC.
L’intégrité de l’hôte. Un poste compromis livre ses tickets en mémoire. Le cloisonnement par tiers et les postes d’administration dédiés font ce travail ; voir séparation des plans de contrôle.
L’autorisation fine. Le PAC transporte des groupes. Ce que ces groupes permettent relève de la gouvernance des droits, voir Gouvernance des identités.
La confidentialité applicative. Kerberos fournit une clé de session. Encore faut-il que le protocole applicatif s’en serve pour signer ou chiffrer (SMB, LDAP), ce qui se configure à part.

Exemple : vérifier les tickets et repérer RC4

On peut observer le déroulé sur un client Linux avec MIT Kerberos, joint à un domaine de test EXEMPLE.LAN. Chaque commande déclenche un échange précis du protocole.

# AS-REQ / AS-REP : obtenir un TGT (le mot de passe est demandé localement, il ne circule pas)
kinit alice@EXEMPLE.LAN

# TGS-REQ / TGS-REP : demander un ticket de service pour un SPN donné
kvno HTTP/web01.exemple.lan@EXEMPLE.LAN

# Lister les tickets en cache avec leurs types de chiffrement (etype)
klist -e

Dans la sortie de klist -e, chaque ticket indique un type de chiffrement pour le ticket et un autre pour la clé de session. Une ligne DEPRECATED:arcfour-hmac (RC4) sur un ticket de service signale un compte de service resté en RC4. C’est le premier candidat au Kerberoasting et le premier à corriger. Sur un poste Windows, la commande klist affiche les mêmes informations (« KerbTicket Encryption Type »).

À l’échelle du domaine, la même logique devient une règle de détection sur les journaux des contrôleurs. Le schéma suivant la décrit ; il se lit de haut en bas, chaque condition filtrant la précédente.

La règle sépare deux choses que les tableaux de bord mélangent souvent. D’un côté, la dette technique (des comptes encore en RC4, à migrer). De l’autre, le comportement suspect (une énumération de SPN). Tant que la dette n’est pas résorbée, l’alerte sur RC4 seul noie l’équipe de supervision. Le seuil de la corrélation se règle sur la ligne de base du parc, pas sur une valeur trouvée dans une présentation de salon.

🐝 Ce qui arrive si on s’en passe

Sans Kerberos, chaque accès retombe sur NTLM, et la perte la moins visible concerne la traçabilité. L’événement 4769 d’un contrôleur de domaine consigne le compte, l’adresse source et le SPN demandé, donc le service visé. Son pendant NTLM, l’événement 4776 de validation des identifiants, ne consigne que le compte et le poste d’origine, sans le serveur cible. Reconstituer le déplacement latéral d’un compte exige alors de collecter les journaux de chaque serveur membre. Le groupe Protected Users devient en outre inutilisable, puisque ses membres ne peuvent s’authentifier qu’en Kerberos. Les comptes d’administration restent donc hors du groupe : leurs vérificateurs de connexion en cache et leurs identifiants délégués par CredSSP persistent sur les postes où ils ouvrent une session, et restent extractibles par quiconque prend la main sur ces postes.

🦫 Explication de la marmotte 🍫

Quand une personne ouvre sa session au bureau, son ordinateur envoie au serveur central d’authentification une petite preuve : l’heure actuelle, chiffrée avec une clé tirée de son mot de passe. Le mot de passe lui-même ne part jamais sur le réseau. Le serveur connaît la même clé. Il déchiffre la preuve, vérifie que l’heure est correcte à cinq minutes près, puis renvoie un premier ticket. Ce ticket est verrouillé avec une clé secrète que seul le serveur central connaît. Quand la personne veut ouvrir un dossier partagé, son ordinateur présente ce premier ticket au serveur central et reçoit un ticket propre au service de partage. Ce second ticket est verrouillé avec la clé du compte qui fait tourner ce service. Le service l’ouvre lui-même et y lit l’identité et les groupes de la personne, sans redemander au serveur central. Tout repose donc sur des clés secrètes. Si la clé d’un service vient d’un mot de passe court, un attaquant peut récupérer un ticket et deviner ce mot de passe chez lui, à loisir. S’il vole la clé d’un service, il fabrique de faux tickets pour ce service. S’il vole la clé principale du serveur central, il fabrique des tickets pour tout le monde. Il faut alors changer cette clé deux fois, car l’ancienne reste acceptée. Si les horloges divergent ou si les noms de machines sont mal déclarés, l’authentification échoue ou retombe sur un ancien protocole moins sûr. La défense tient en quelques règles : mots de passe de service longs et changés automatiquement, chiffrement moderne, comptes d’administration protégés, et surveillance des demandes de tickets.

Pages voisines

La citent

Kerberos et KDC dans Active Directory, attaques et durcissement

Elle cite

: les deux pages se citent l’une l’autre.

Kerberos et KDC dans Active Directory, attaques et durcissement

Kerberos et KDC dans Active Directory, attaques et durcissement

Principe de Kerberos v5 : tiers de confiance et tickets

Déroulé AS-REQ, TGS-REQ, AP-REQ et clés de session

Kerberos dans Active Directory : KDC, SPN et PAC

Horloge, DNS et contrôleurs de domaine : dépendances de Kerberos

Attaques Kerberos : Kerberoasting, AS-REP roasting, pass-the-ticket, tickets d’argent et d’or

Durcissement de Kerberos : gMSA, AES, krbtgt et Protected Users

Kerberos face à NTLM

Ce que Kerberos ne garantit pas

Exemple : vérifier les tickets et repérer RC4

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines