Détection et neutralisation en temps réel des attaques Kerberos Golden Ticket sous Windows Server avec SIEM et PowerShell

1. Contexte

Le Golden Ticket est une technique d’attaque avancée sur Kerberos qui permet à un adversaire de forger un Ticket Granting Ticket (TGT) valide pour n’importe quel compte Active Directory, y compris les administrateurs de domaine.
En compromettant la clé de chiffrement du service Kerberos (KRBTGT), l’attaquant peut générer des TGT valides sans interaction avec le contrôleur de domaine, contournant ainsi toute authentification.

Une fois en possession de cette clé, l’attaquant peut :

• Obtenir un accès persistant et complet à tout l’environnement AD
• Se faire passer pour n’importe quel utilisateur
• Contourner la révocation classique des comptes

2. Fonctionnement interne

Kerberos repose sur le principe suivant :

1. L’utilisateur demande un TGT au KDC (Key Distribution Center)
2. Le KDC signe le TGT avec la clé secrète du compte KRBTGT
3. Le TGT est ensuite utilisé pour obtenir des Ticket Granting Service (TGS) pour accéder aux ressources

Dans une attaque Golden Ticket, l’attaquant forge directement le TGT, en le signant avec la clé KRBTGT compromise, ce qui supprime toute validation côté KDC.

3. Indicateurs de compromission

Les signaux spécifiques d’un Golden Ticket incluent :

• Event ID 4769 (TGS Request) avec des durées de vie anormalement longues
• Event ID 4624 (Logon) de type 3 ou 9 avec un SID S-1-5-21...-500 utilisé depuis une machine inhabituelle
• Absence d’Event ID 4768 (TGT Request) pour un compte ayant reçu un TGS
• Utilisation de tickets avec des valeurs RenewUntil dépassant la limite normale

Commande PowerShell pour filtrer Event ID suspects :

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769} |
Where-Object { $_.Properties[8].Value -gt (Get-Date).AddHours(10) }

4. Détection avancée avec SIEM

Un SIEM peut corréler plusieurs événements pour détecter un Golden Ticket :

• Recherche d’un TGS sans TGT préalable
• Durée de vie du ticket supérieure à la valeur configurée dans AD
• Accès administratif depuis des endpoints non approuvés

Exemple de règle Splunk :

index=wineventlog EventCode=4769 OR EventCode=4768
| transaction AccountName maxspan=1m
| search NOT EventCode=4768 AND EventCode=4769

Exemple Microsoft Sentinel (KQL) :

SecurityEvent
| where EventID == 4769
| join kind=leftanti (
    SecurityEvent
    | where EventID == 4768
) on AccountName

5. Neutralisation et réponse automatisée

Une fois un Golden Ticket confirmé :

1. Changer deux fois le mot de passe du compte KRBTGT à 24h d’intervalle pour invalider tous les tickets forgés
2. Forcer une reconnexion de tous les comptes
3. Surveiller les tentatives de connexion échouées sur les comptes à privilèges

PowerShell : Réinitialisation KRBTGT

Set-ADAccountPassword -Identity "KRBTGT" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "MotDePasseComplexe1!" -Force)
Start-Sleep -Seconds 86400
Set-ADAccountPassword -Identity "KRBTGT" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "MotDePasseComplexe2!" -Force)

Blocage automatisé via PowerShell et SIEM :

if ($SuspiciousAccount) {
    Disable-ADAccount -Identity $SuspiciousAccount
    Write-EventLog -LogName "Security" -Source "KerberosMonitor" -EntryType Warning -EventId 9001 -Message "Compte $SuspiciousAccount désactivé suite à détection Golden Ticket"
}

6. Bonnes pratiques de prévention

• Limiter les membres du groupe Administrateurs de domaine
• Activer l’audit Kerberos complet sur tous les DC
• Utiliser des comptes d’administration dédiés aux tâches sensibles
• Mettre en place une surveillance comportementale des durées de tickets

Conclusion

Les attaques Golden Ticket sont redoutables car elles permettent un accès persistant et furtif.
Une détection efficace repose sur la corrélation d’événements Kerberos, l’analyse comportementale et l’automatisation de la réponse via PowerShell et SIEM.
En appliquant une rotation régulière de la clé KRBTGT et en surveillant les anomalies, il est possible de limiter l’impact de cette menace.