Silver Ticket

Définition

Un Silver Ticket est une attaque Active Directory consistant à forger directement un ticket de service Kerberos (TGS) en le signant avec le hachage NTLM du compte de service ciblé, sans jamais solliciter le KDC (Key Distribution Center) pour son émission, contrairement à un TGS légitime obtenu via une authentification réelle. Cette technique nécessite que l'attaquant connaisse préalablement le hachage NTLM du compte associé au service visé, obtenu par exemple via credential dumping ou Kerberoasting sur un compte de service disposant d'un SPN. Une fois ce hachage en sa possession, l'attaquant peut construire un TGS arbitraire, en s'attribuant lui-même les privilèges et l'appartenance à des groupes de son choix, mais uniquement exploitable sur le service précis dont il détient le hachage — un serveur CIFS, une instance MSSQL, un service HTTP — sans possibilité d'extension à d'autres services du domaine, contrairement au Golden Ticket qui offre un accès total. La furtivité du Silver Ticket constitue son atout offensif majeur : puisqu'aucune requête n'atteint jamais le contrôleur de domaine lors de sa création ni de son utilisation, le service cible validant le ticket localement à partir de sa propre clé, aucun événement Kerberos classique de type 4769 n'est généré côté KDC. Sa détection repose donc principalement sur la surveillance côté service ciblé plutôt que sur les journaux du contrôleur de domaine.

Fonctionnement technique du Silver Ticket

Le protocole Kerberos repose sur une faiblesse structurelle : un serveur applicatif ne vérifie jamais auprès du KDC la validité d'un ticket de service (TGS) qui lui est présenté. Il se contente de déchiffrer la partie chiffrée du ticket avec le secret de son propre compte de service. Quiconque détient le hash NTLM (ou la clé AES) de ce compte peut donc fabriquer un TGS parfaitement valide, hors ligne et sans aucune interaction réseau avec le contrôleur de domaine.

Pour forger le ticket, l'attaquant a besoin de quatre éléments : le hash du compte de service, le SID du domaine, le SPN ciblé et un nom d'utilisateur arbitraire. Il insère ensuite un PAC falsifié déclarant l'appartenance aux groupes privilégiés (Domain Admins, RID 512), puis injecte le ticket en mémoire.

Cas d'usage et exemples concrets

CIFS : accès complet aux partages de fichiers d'un serveur, exfiltration de données sensibles.
HOST : création de tâches planifiées et exécution de commandes à distance sur la machine ciblée.
MSSQLSvc : authentification en tant que sa sur une base de données, souvent après un Kerberoasting réussi sur le compte de service SQL.
HTTP / WSMAN : détournement d'applications web internes ou de sessions PowerShell Remoting.
Persistance discrète : le hash d'un compte machine change tous les 30 jours par défaut, celui d'un compte de service applicatif reste souvent inchangé pendant des années.

Détection et indicateurs

La détection est plus délicate que pour un Golden Ticket, car aucune trace n'apparaît sur le contrôleur de domaine. Les indicateurs se trouvent sur le serveur cible :

Event ID 4624 (ouverture de session réseau, type 3) sans Event ID 4768/4769 correspondant côté KDC : signature typique d'un ticket forgé.
Incohérences dans le PAC : nom d'utilisateur inexistant dans l'annuaire, durée de vie anormale (10 ans par défaut avec Mimikatz).
Chiffrement RC4 (0x17) alors que le domaine impose AES256.
Corrélation impérative des journaux serveurs et DC dans un SIEM.

Contre-mesures et remédiation

Activer PAC validation sur les serveurs sensibles afin de forcer la vérification du ticket auprès du KDC.
Migrer les comptes de service vers des gMSA ou des comptes machine, dont les mots de passe complexes tournent automatiquement.
Imposer des mots de passe de plus de 25 caractères et désactiver RC4 au profit d'AES.
Limiter les droits des comptes de service (principe du moindre privilège) pour réduire l'impact d'une élévation de privilèges.
Protéger les secrets LSASS avec Credential Guard afin d'empêcher l'extraction initiale du hash.

Outils recommandés

Côté offensif, Mimikatz (kerberos::golden /service:) et la suite Impacket (ticketer.py) restent les références. Côté défensif, BloodHound cartographie les comptes de service exposés et PingCastle identifie les mots de passe obsolètes, deux prérequis d'un audit Active Directory sérieux.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis