Qu’est-ce qu’une attaque Silver Ticket ?
Une attaque Silver Ticket consiste à forger un ticket de service Kerberos (TGS) avec le secret du compte de service ciblé. MITRE référence cette technique sous T1558.002, Silver Ticket.
Le périmètre est plus étroit qu’un Golden Ticket, mais le mécanisme est important. Un attaquant qui connaît le hash de mot de passe ou la clé Kerberos d’un compte de service peut forger un ticket pour ce service et le présenter directement à l’hôte qui l’exécute. MITRE est explicite sur trois points :
- l’attaquant a besoin du hash de mot de passe du compte de service ciblé
- le ticket forgé est un ticket de service, pas un TGT
- le ticket peut être créé sans interaction avec le KDC
Ce dernier point explique l’intérêt de l’attaque. L’attaquant ne demande pas en temps réel à un contrôleur de domaine d’émettre le ticket de service. Il le forge hors ligne, puis le présente au service cible.
Le périmètre de cet article est Kerberos dans Windows Active Directory. L’objectif est d’expliquer les prérequis réels, ce qui distingue Silver Ticket de Golden Ticket, et les durcissements de comptes de service qui réduisent réellement l’opportunité.
Comment fonctionne l’attaque Silver Ticket
Dans un flux Kerberos normal, le Key Distribution Center émet un ticket de service après présentation d’un TGT valide. Silver Ticket casse ce flux attendu en forgeant directement le ticket de service.
La page MITRE Silver Ticket indique que les adversaires ayant le hash de mot de passe d’un compte de service ciblé peuvent forger des Kerberos ticket granting service tickets, c’est-à-dire des tickets de service. Contrairement aux Golden Tickets, ces tickets sont limités à une ressource et au système qui héberge cette ressource. Mais contrairement à un flux Kerberos normal, le ticket peut être créé sans interaction avec le KDC.
Cette différence a deux conséquences directes :
- le ticket forgé est limité à un service principal précis
- la détection est souvent plus difficile parce que le chemin d’émission habituel côté contrôleur de domaine manque
Pourquoi le secret du compte de service est central
Silver Ticket fonctionne parce que l’attaquant connaît la clé du compte de service ciblé. Ce secret peut provenir de :
- credential dumping après compromission d’un serveur
- extraction d’un hash de compte de service depuis un hôte où le service tourne
- Kerberoasting : Cracker les Mots de Passe des Comptes de Service, que MITRE cite comme chemin possible pour obtenir le hash cible
Si l’attaquant ne récupère pas le secret du compte de service, il ne peut pas forger un Silver Ticket utilisable pour ce service.
Le rôle de la PAC doit être formulé prudemment
La documentation Microsoft sur la PAC montre que le traitement peut dépendre du modèle applicatif et d’hypothèses de confiance. Microsoft précise notamment que la validation PAC peut être optionnelle pour une application autonome.
Cette nuance est utile, mais elle ne doit pas être surinterprétée. Le prérequis central reste la possession du secret du compte de service et un chemin service qui accepte le ticket présenté. Le comportement PAC est un élément du traitement côté service, pas une explication universelle de toutes les réussites Silver Ticket.
Silver Ticket vs Golden Ticket, Kerberoasting et Pass-the-Ticket
Ces termes sont souvent mélangés. Ils ne décrivent pas la même chose.
- Silver Ticket : ticket de service forgé pour un service précis après obtention du secret du compte de service
- Golden Ticket : TGT forgé à partir du secret
krbtgt, avec impact beaucoup plus large sur le domaine. Voir Golden Ticket : Les Clés de Votre Domaine - Kerberoasting : demande de tickets de service légitimes au KDC, puis cracking hors ligne pour retrouver le secret du compte de service
- Pass-the-Ticket : réutilisation d’un vrai ticket Kerberos volé, plutôt qu’un ticket forgé
Silver Ticket arrive souvent après une autre attaque. Kerberoasting ou credential dumping donne le secret. Silver Ticket transforme ce secret en accès non autorisé au service.
Pourquoi Silver Ticket reste important
Silver Ticket est moins connu que Golden Ticket, mais il vise une faiblesse fréquente : les secrets de comptes de service mal gérés.
Les comptes de service vivent trop longtemps
Les comptes de service survivent souvent pendant des années, supportent plusieurs applications et accumulent SPN, droits locaux et exceptions opérationnelles. C’est exactement le type de secret stable qu’un attaquant cherche.
L’attaque est plus silencieuse qu’un flux KDC normal
MITRE met en avant le problème central : un Silver Ticket peut être créé sans interaction avec le KDC. Une partie de la visibilité habituelle côté contrôleur de domaine est donc absente au moment où le ticket est forgé.
L’hygiène des comptes de service reste faible
La documentation Microsoft sur les comptes de service managés existe parce que la gestion manuelle des mots de passe de service est fragile. Un compte utilisateur classique utilisé comme compte de service reste un endroit courant pour trouver secrets anciens, rotation faible et chiffrement incohérent.
Le chiffrement Kerberos legacy augmente l’exposition
La guidance Microsoft actuelle continue de pousser l’audit et la réduction de RC4 dans Kerberos. Ce point est pertinent parce que les vieux comptes de service avec posture de chiffrement legacy sont souvent les mêmes comptes mal gérés opérationnellement.
Prérequis d’une attaque Silver Ticket réussie
Silver Ticket n’est pas une astuce Kerberos sans prérequis. Plusieurs conditions doivent être réunies.
1. L’attaquant doit obtenir le secret du compte de service
C’est le prérequis non négociable. MITRE indique explicitement que l’attaquant a besoin du hash du compte de service ciblé. Les chemins courants sont credential dumping et Kerberoasting.
2. Le service cible doit s’appuyer sur ce service principal
Le ticket forgé doit correspondre à une identité de service réelle acceptée par l’hôte. Le périmètre est donc plus étroit qu’un Golden Ticket.
3. Le ticket doit être accepté par le chemin service ciblé
La documentation Microsoft sur la PAC explique pourquoi le traitement côté service peut varier selon l’application. Mais cette nuance ne supprime pas le besoin de viser le bon service principal avec le bon secret.
4. Le compte de service doit avoir de la valeur
Un ticket forgé pour un service sans impact reste un problème, mais le vrai risque concerne les comptes liés à applications sensibles, workflows administratifs ou hôtes privilégiés.
5. L’environnement garde une mauvaise hygiène de comptes de service
Comptes utilisateurs utilisés comme services, absence de gMSA, mots de passe anciens, droits excessifs ou dépendance à RC4 rendent les prérequis Silver Ticket plus réalistes.
Chaîne d’attaque
Une intrusion Silver Ticket ressemble souvent à ceci.
Étape 1 - Identifier un compte de service intéressant
L’attaquant cartographie SPN, services et systèmes pour trouver un service principal utile.
Étape 2 - Obtenir le hash ou la clé du compte de service
Le secret est récupéré par dumping, cracking après Kerberoasting ou autre chemin d’accès aux identifiants.
Étape 3 - Forger le ticket de service hors ligne
Avec ce secret, l’attaquant crée un ticket de service Kerberos pour le service principal choisi.
Étape 4 - Présenter le ticket forgé directement au service
C’est là que Silver Ticket diverge du flux Kerberos normal. MITRE précise que le ticket forgé peut être utilisé sans interaction avec le KDC.
Étape 5 - Exploiter l’accès dans le périmètre du service
L’accès est plus restreint qu’un Golden Ticket, mais il peut être sérieux si le service est sur un hôte sensible, expose des fonctions d’administration ou facilite un mouvement latéral.
C’est pourquoi Silver Ticket doit être lu avec Chemins d'Attaque AD : Mauvaises Configurations en Chaîne. Même un ticket limité peut faire partie d’une chaîne plus large.
Détection
Détecter Silver Ticket est difficile pour une raison simple : l’attaquant peut ne jamais demander au KDC le ticket de service qu’il utilise.
Le bon modèle est donc détection d’anomalies plus détection des prérequis, pas un Event ID unique qui prouve tout.
Chercher une utilisation de service ticket qui ne colle pas au KDC
La stratégie de détection MITRE DET0241 recommande de rechercher une activité de ticket de service anormale, notamment une activité qui apparaît sans les patterns attendus de validation ou d’émission côté KDC.
Opérationnellement, investiguez les cas où :
- un compte de service est utilisé sur un hôte ou une ressource hors périmètre attendu
- le service cible voit une activité Kerberos qui ne s’aligne pas avec les patterns normaux d’émission TGS côté KDC
- des champs inhabituels ou malformés apparaissent dans les logs de logon ou de ticket
Ce n’est pas une règle triviale. Il faut connaître quels hôtes et ressources chaque compte de service doit réellement toucher.
Surveiller les attaques prérequis
MITRE pointe aussi l’accès suspect à LSASS et le credential dumping comme sources utiles. C’est logique : le secret du compte de service doit généralement être volé avant que le Silver Ticket existe.
Surveillez donc :
- accès suspect à LSASS
- comportement de credential dumping
- Kerberoasting : Cracker les Mots de Passe des Comptes de Service
- authentifications de comptes de service hors périmètre
Vous avez plus de chances de détecter la chaîne réelle en amont qu’en cherchant seulement le ticket final.
Utiliser le contexte Kerberos avec prudence
L’événement 4769 reste utile parce qu’il représente une demande normale de ticket de service côté KDC. Pour Silver Ticket, le point n’est pas d’alerter naïvement sur une absence de 4769. Le point est de comprendre qu’un ticket forgé peut ne pas suivre le chemin d’émission KDC normal. Cette détection exige une baseline, pas une règle isolée.
Surveiller les comptes de service hors de leur périmètre
MITRE cite explicitement les tentatives d’accès utilisant des comptes de service en dehors des hôtes ou ressources attendus. C’est souvent plus exploitable pour les défenseurs qu’une recherche purement protocolaire.
Corréler avec les actions privilégiées
Si le ticket atteint un service à impact administratif, les signaux suivants peuvent apparaître :
- accès inhabituel à des fonctions d’administration applicative
- logons ou accès sur l’hôte de service depuis des identités inattendues
- actions privilégiées en aval
- anomalies couvertes dans Supervision Sécurité AD : Événements Clés
Remédiation
La mitigation Silver Ticket est d’abord une hygiène de comptes de service. Si l’attaquant ne peut pas récupérer un secret de compte de service réutilisable, il ne peut pas forger le ticket.
1. Migrer les services éligibles vers gMSA
La documentation Microsoft sur les group Managed Service Accounts est la mitigation primaire la plus claire.
Les gMSA permettent à Windows de gérer les mots de passe de comptes de service, de faire tourner les clés et de réduire le besoin de synchronisation manuelle par les administrateurs. Cela attaque directement l’un des prérequis majeurs de Silver Ticket : les secrets statiques ou mal gérés.
2. Configurer AES pour les comptes de service managés
Microsoft indique que les Managed Service Accounts dépendent des types de chiffrement Kerberos supportés et recommande de toujours configurer AES pour les MSA. Si l’hôte ne supporte pas RC4, l’authentification échoue si le compte n’a pas de posture AES correcte.
3. Réinitialiser les vieux mots de passe de comptes de service
La guidance Microsoft sur RC4 explique que certains comptes créés avant l’adoption d’AES peuvent manquer de clés AES si leur mot de passe n’a jamais été changé après l’ajout du support AES. Microsoft précise que changer le mot de passe génère ces clés.
C’est important pour les comptes de service legacy.
4. Réduire RC4 quand c’est possible
Microsoft continue de fournir des étapes d’audit et de remédiation pour réduire RC4 dans Kerberos. Cela ne rend pas Silver Ticket impossible à lui seul, mais réduit une faiblesse legacy souvent présente sur les mêmes comptes de service. Cela complète AS-REP Roasting : collecter des hashes sans identifiants et les autres durcissements Kerberos.
5. Réduire les privilèges et le scope des comptes de service
Un ticket forgé n’est utile qu’à hauteur des droits du compte. Même si le compte doit exister, il ne devrait pas porter de droits locaux admin, groupes privilégiés ou accès à des systèmes sans rapport.
6. Inventorier SPN et ownership
Un programme sérieux doit connaître :
- quels SPN correspondent à quels comptes
- quels hôtes utilisent ces comptes
- qui possède opérationnellement chaque compte
- si le compte peut migrer vers gMSA
- si le compte dépend encore de RC4 ou de paramètres legacy
C’est le type de revue décrit dans Audit de sécurité Active Directory : checklist pratique.
7. Traiter Kerberoasting et credential dumping comme précurseurs
Si un attaquant peut dumper ou cracker le secret d’un compte de service, la voie Silver Ticket est ouverte. Relisez Kerberoasting : Cracker les Mots de Passe des Comptes de Service, Délégation Kerberos : Non Contrainte à RBCD et Golden Ticket : Les Clés de Votre Domaine.
Validation après durcissement
Ne fermez pas le risque Silver Ticket après un seul changement de mot de passe. Validez le modèle de comptes de service.
- confirmer quels services utilisent encore des comptes utilisateurs classiques au lieu de gMSA
- vérifier que les comptes ont des clés AES et que RC4 n’est plus nécessaire
- vérifier
msDS-SupportedEncryptionTypeslorsque c’est pertinent - comparer la configuration avec l’usage Kerberos observé sur les contrôleurs de domaine
- examiner les événements
4769pour comprendre quels comptes demandent encore des tickets et avec quels types de chiffrement - confirmer que les services sensibles ne reposent pas sur des identités partagées, anciennes ou non documentées
- réduire les privilèges qui dépassent les besoins réels du service
Le vrai succès n’est pas seulement une meilleure politique Kerberos. C’est qu’un compte de service compromis ne fournisse plus un secret stable et réutilisable avec forte valeur opérationnelle.
Comment EtcSec détecte l’exposition liée
Il n’existe pas de type exact Silver Ticket dans le catalogue actuel. Les findings les plus utiles sont donc les prérequis et faiblesses Kerberos qui rendent la technique pratique.
Les plus pertinentes sont :
KERBEROASTING_RISK, parce que la récupération hors ligne d’un secret de compte de service est un précurseur clairKERBEROS_RC4_FALLBACK, parce que la posture Kerberos legacy recoupe souvent les mêmes comptes de service non maîtrisés- les comptes de service trop privilégiés ou trop larges
- les conditions d’attack path couvertes dans Chemins d'Attaque AD : Mauvaises Configurations en Chaîne
Le bon modèle est celui-ci : Silver Ticket est une technique de ticket forgé, mais la surface de correction réelle est l’hygiène des comptes de service.
Contrôles associés
Si vous révisez le risque Silver Ticket, relisez Golden Ticket : Les Clés de Votre Domaine, Kerberoasting : Cracker les Mots de Passe des Comptes de Service, AS-REP Roasting : collecter des hashes sans identifiants, Délégation Kerberos : Non Contrainte à RBCD, Supervision Sécurité AD : Événements Clés, Chemins d'Attaque AD : Mauvaises Configurations en Chaîne, Audit de sécurité Active Directory : checklist pratique et Outils d’audit de sécurité Active Directory : quoi comparer avant de choisir.
