Aller au contenu
Hermes Codex

Sécurité des Identités : Authentification Kerberos et Surface d'Attaque

1. Le chien à trois têtes : composants architecturaux

Section intitulée « 1. Le chien à trois têtes : composants architecturaux »

Kerberos s’appuie sur un tiers de confiance appelé le Key Distribution Center (KDC), un rôle assuré par le contrôleur de domaine (DC) Active Directory. Le KDC est logiquement divisé en deux services :

  1. Authentication Service (AS) : vérifie l’identité de l’utilisateur et émet le “badge maître” initial (le TGT).
  2. Ticket Granting Service (TGS) : émet des tickets d’accès spécifiques pour des services individuels (comme un partage de fichiers ou une base de données SQL).

Le ballet de l’authentification (flux en 6 étapes)

Section intitulée « Le ballet de l’authentification (flux en 6 étapes) »

Le flux Kerberos est un échange cryptographique en trois actes.

  1. AS-REQ (Demande au service d’authentification) : le client initie la connexion en envoyant une requête au KDC. Cette requête inclut le nom d’utilisateur et un horodatage (timestamp) chiffré avec une clé dérivée du mot de passe de l’utilisateur.
  2. AS-REP (Réponse du service d’authentification) : le KDC déchiffre l’horodatage en utilisant le hash de l’utilisateur issu de ntds.dit. En cas de succès, le KDC renvoie un Ticket Granting Ticket (TGT) (chiffré avec le hash du compte krbtgt) et une clé de session (chiffrée avec le hash de l’utilisateur).
  3. TGS-REQ (Demande de ticket de service) : pour accéder à un service spécifique (ex: CIFS/fileserver.corp.local), le client envoie le TGT, un authentificateur (horodatage chiffré avec la clé de session) et le Service Principal Name (SPN) cible au KDC.
  4. TGS-REP (Réponse du ticket de service) : le KDC déchiffre le TGT et valide l’authentificateur. Il émet ensuite un Ticket de service chiffré avec le hash du compte de service cible, et le renvoie au client.
  5. AP-REQ (Requête d’application) : le client présente le ticket de service chiffré au serveur cible.
  6. AP-REP (Réponse d’application - Optionnel) : le serveur cible déchiffre le ticket de service à l’aide de son propre hash. En cas de succès, l’accès est accordé. Une authentification mutuelle a lieu si le serveur renvoie une confirmation chiffrée.

Ballet d'authentification Kerberos

2. La surface d’attaque Kerberos

Section intitulée « 2. La surface d’attaque Kerberos »

Bien qu’extrêmement sécurisé contre l’écoute réseau (sniffing), la dépendance de Kerberos à la cryptographie symétrique et aux tickets introduit des vulnérabilités logiques dévastatrices.

A. Cassage hors ligne : le Kerberoasting

Section intitulée « A. Cassage hors ligne : le Kerberoasting »

Tout utilisateur de domaine authentifié peut demander un ticket de service (TGS-REQ) pour n’importe quel service disposant d’un SPN enregistré. Le KDC s’exécutera et renverra un ticket de service chiffré avec le hash du mot de passe du compte de service.

  • L’attaque : l’adversaire extrait ce ticket chiffré de la mémoire et utilise des outils de force brute hors ligne (Hashcat, John the Ripper) pour casser le mot de passe du compte de service.
  • Focus DFIR : rechercher des pics anormaux d’Événements 4769 pour des comptes de service hautement privilégiés demandés par des comptes d’utilisateurs standards.

B. Domination totale du domaine : Golden et Silver Tickets

Section intitulée « B. Domination totale du domaine : Golden et Silver Tickets »

Si un attaquant compromet un contrôleur de domaine, il peut extraire les ultimes secrets cryptographiques de la base de données ntds.dit ou de la mémoire LSASS.

  • Golden Ticket : l’attaquant vole le hash NT du compte krbtgt. Avec cela, il peut forger ses propres TGT pour n’importe quel utilisateur (y compris les administrateurs du domaine) avec des durées de vie arbitraires. Cela contourne entièrement la phase AS-REQ.
  • Silver Ticket : l’attaquant vole le hash d’un ordinateur ou d’un compte de service spécifique. Il peut forger des tickets de service pour accéder uniquement à ce service, contournant complètement le KDC.

C. Vecteur avancé (2025) : Reflective Kerberos Relay

Section intitulée « C. Vecteur avancé (2025) : Reflective Kerberos Relay »

Pendant des années, NTLM a été la cible principale des attaques par relais, tandis que Kerberos était considéré comme immunisé grâce à la validation SPN et à l’authentification mutuelle. Cependant, des recherches récentes (2025) de RedTeam Pentesting ont démontré les attaques de Reflective Kerberos Relay. Si un service manque de protection étendue de l’authentification (EPA) stricte ou de signature SMB, un attaquant peut forcer une victime à s’authentifier vers une machine contrôlée par l’attaquant, et “réfléchir” la requête AP-REQ Kerberos vers un service différent sur la propre machine de la victime, contournant ainsi les mitigations de relais traditionnelles.

3. Télémétrie DFIR : la pierre de Rosette des journaux

Section intitulée « 3. Télémétrie DFIR : la pierre de Rosette des journaux »

Pour traquer les abus Kerberos, les analystes DFIR doivent auditer des identifiants d’événements (Event IDs) spécifiques sur les contrôleurs de domaine.

ÉvénementDescriptionContexte de Threat Hunting
4768TGT demandé (AS-REQ/REP)la base de référence pour une connexion réussie. L’absence d’événements 4768 suivis d’une activité de ticket ultérieure indique des tickets forgés.
4769Ticket de service demandé (TGS-REQ)critique pour le suivi des mouvements latéraux et du Kerberoasting. Un pic soudain d’événements 4769 demandant le chiffrement RC4 (0x17) est hautement suspect.
4771Échec de la pré-authentificationgénéré lorsque le déchiffrement de l’horodatage AS-REQ échoue (généralement un mauvais mot de passe). Une tempête massive d’événements 4771 depuis une seule IP sur plusieurs comptes est la signature définitive du Password Spraying.
4770Ticket renouveléles TGT ont une durée de vie (10 heures par défaut) et peuvent être renouvelés. Des demandes de renouvellement anormales pour des comptes très sensibles en dehors des heures de travail justifient une investigation.
4772Échec de demande de ticketéchec générique (ex: important décalage d’horloge entre le client et le DC, ou comptes désactivés). Utile pour diagnostiquer des problèmes informatiques plutôt que des attaques directes.

4. Requêtes de Threat Hunting

Section intitulée « 4. Requêtes de Threat Hunting »
hunt_golden_ticket_anomalies.kql
// Détecte l'utilisation potentielle d'un Golden Ticket en trouvant des requêtes TGS (4769)
// dépourvues de requête TGT (4768) précédente dans un délai logique.
let TGT_Requests = SecurityEvent
| where EventID == 4768
| project Account, TargetLogonId, TimeGenerated;


SecurityEvent
| where EventID == 4769
// Filtrer pour l'accès administratif ou les services critiques
| where Account has_any ("admin", "svc_")
// Jointure pour trouver les requêtes TGS manquant d'un TGT récent
| join kind=leftanti (TGT_Requests) on Account
| project TimeGenerated, Computer, Account, ServiceName, TicketOptions, TicketEncryptionType
| sort by TimeGenerated desc

5. Atténuation et durcissement

Section intitulée « 5. Atténuation et durcissement »
  1. Imposer le chiffrement AES : désactiver l’ancien algorithme de chiffrement RC4 (0x17) sur l’ensemble du domaine. Le protocole Kerberos moderne doit utiliser strictement l’AES-256 (0x12). Les attaquants forgeant des tickets optent souvent par défaut pour le RC4 car cela ne nécessite qu’un simple hash NTLM plutôt que des clés AES complexes.
  2. Rotation régulière du krbtgt : la seule façon d’invalider un Golden Ticket est de changer le mot de passe du compte krbtgt deux fois (pour effacer l’historique des mots de passe). Cela devrait être une pratique architecturale de routine, et non une simple réaction post-incident.
  3. Implémenter l’EPA et la signature SMB : pour atténuer les nouvelles attaques de Reflective Kerberos Relay, imposez la protection étendue de l’authentification (EPA) sur les serveurs IIS/LDAP et rendez la signature SMB (SMB signing) obligatoire sur tous les terminaux.

Sources et références

Section intitulée « Sources et références »