Silver Ticket : Attaque Kerberos Service Active Directory

Le Silver Ticket est une attaque post-exploitation sur Active Directory qui consiste à forger localement un ticket de service Kerberos (TGS) à partir du hash NTLM ou des clés AES d'un compte de service compromis, afin d'accéder à ce service ciblé sans solliciter le contrôleur de domaine. Référencée sous l'identifiant T1558.002 dans le framework MITRE ATT&CK (catégorie Steal or Forge Kerberos Tickets), la technique a été dévoilée publiquement en 2014 par Benjamin Delpy, créateur de Mimikatz, en complément de son Golden Ticket. Là où le Golden Ticket forge un TGT signé par krbtgt et ouvre tout le domaine, le Silver Ticket forge un TGS unique chiffré avec le hash du compte de service hébergeant la ressource (CIFS, MSSQLSvc, HOST, HTTP, LDAP). Sa redoutable furtivité provient d'un détail protocolaire majeur : aucun contact avec le KDC n'est nécessaire pour l'exploitation, le serveur applicatif validant lui-même la signature avec sa propre clé. Aucun Event 4768 (TGT request) ni 4769 (TGS request) n'est généré sur les contrôleurs de domaine, rendant la détection particulièrement difficile sans télémétrie endpoint avancée. Cette page entity-first détaille le principe cryptographique, les pré-requis (compromission du hash machine ou du compte de service via Kerberoasting, DCSync ou Pass-the-Hash), la fabrication du ticket avec Mimikatz, Rubeus et Impacket ticketer, les services typiquement ciblés, les stratégies de détection (Event 4624 LogonType 3, PAC validation, Defender for Identity) et les contre-mesures de mitigation (gMSA, AES-only, rotation des hashes). Que vous soyez analyste SOC, pentester certifié OSCP/OSEP, architecte AD ou RSSI, comprendre le Silver Ticket est essentiel pour défendre votre infrastructure Microsoft en 2026.

Définition du Silver Ticket

Le Silver Ticket est un TGS Kerberos forgé localement par un attaquant qui possède le hash NTLM (ou la clé AES) du compte de service propriétaire d'un Service Principal Name (SPN) donné. Une fois fabriqué, ce ticket est injecté dans la session courante via Pass-the-Ticket et présenté directement au service applicatif (CIFS, MSSQL, HTTP, LDAP) qui le déchiffre avec sa propre clé secrète et autorise l'accès, sans aucune vérification auprès du KDC.

Le terme "Silver Ticket" a été choisi par Benjamin Delpy en miroir du "Golden Ticket" : si l'or symbolise la maîtrise totale du domaine (TGT signé par krbtgt), l'argent évoque un accès précieux mais limité à un service unique. Cette terminologie est devenue standard dans la littérature offensive et défensive AD depuis 2014.

Référencée par MITRE ATT&CK sous l'identifiant T1558.002 (sous-technique de T1558 Steal or Forge Kerberos Tickets), tactique Credential Access et Defense Evasion, la technique se distingue par un compromis offensif particulier : moins puissante qu'un Golden Ticket en portée, elle est en revanche nettement plus furtive car le KDC n'est jamais sollicité. Pour un attaquant cherchant la persistance discrète sur un asset critique (serveur de fichiers, base SQL sensible, contrôleur de domaine via service HOST), le Silver Ticket est l'outil de prédilection.

Histoire et contexte d'apparition

L'origine du Silver Ticket remonte à 2014, dans le sillage immédiat de la révélation publique du Golden Ticket par Benjamin Delpy. Lors de ses présentations à BlueHat (Microsoft) et au PHDays moscovite, Delpy démontre que le module kerberos::golden de Mimikatz, modifié pour signer le TGS avec le hash d'un compte de service plutôt qu'avec celui de krbtgt, produit un ticket directement utilisable contre le service ciblé.

L'arrière-plan technique repose sur la spécification RFC 4120 du protocole Kerberos v5 : tout TGS est chiffré avec la clé secrète du service principal cible (long-term key), et l'application valide localement cette signature via sa propre clé. Cette propriété, conçue pour des raisons de performance (éviter d'engorger le KDC), devient le talon d'Achille exploité par le Silver Ticket.

Les jalons historiques majeurs incluent :

• 2005 : RFC 4120 publie la spécification Kerberos v5 utilisée par Active Directory.
• 2014 : Benjamin Delpy démontre publiquement le Silver Ticket via Mimikatz à BlueHat IL et PHDays.
• 2014-2015 : Sean Metcalf (adsecurity.org) publie une série de référence sur les tickets forgés AD.
• 2016 : Alberto Solino intègre ticketer.py dans Impacket, portage Python multiplateforme.
• 2017 : Will Schroeder publie Rubeus (.NET) avec support Silver Ticket pour Cobalt Strike.
• 2018 : Microsoft Advanced Threat Analytics (ATA) intègre des heuristiques anti-Silver Ticket via PAC validation.
• 2019 : Microsoft introduit les gMSA (group Managed Service Accounts) avec rotation automatique 30 jours, contre-mesure structurelle.
• 2020-2022 : Defender for Identity généralise la détection comportementale des PAC anormaux.
• 2023-2024 : campagnes ransomware (LockBit, BlackCat) documentent l'usage massif de Silver Tickets sur CIFS pour exfiltration silencieuse.
• 2025-2026 : Microsoft renforce la PAC signature validation (KB5008380, suite Kerberos hardening) imposant la validation cryptographique stricte côté service.

Principe technique : forge d'un TGS chiffré avec le hash service

Le cœur de l'attaque exploite la cryptographie Kerberos sur deux clés distinctes : la clé du compte de service (qui chiffre le TGS) et la clé du compte krbtgt (qui signe la PAC interne). Dans une transaction Kerberos légitime, le client demande au KDC un TGS pour le SPN cible ; le KDC le génère, le chiffre avec la clé long-terme du service, le signe avec krbtgt et le retourne au client. Le service ciblé reçoit alors le TGS, le déchiffre avec sa propre clé et accorde l'accès.

Le Silver Ticket court-circuite cette transaction : l'attaquant, possédant déjà la clé du service compromis, fabrique lui-même un TGS valide. Il insère librement n'importe quel SID (security identifier) et n'importe quels group memberships (typiquement Domain Admins, Enterprise Admins) dans la PAC (Privilege Attribute Certificate) du ticket. Comme le service ne possède pas la clé krbtgt, il ne peut pas vérifier la signature interne de la PAC sauf si la PAC validation est explicitement activée — ce qui historiquement n'était pas le cas sur la majorité des services Microsoft.

Trois propriétés fondent la furtivité du Silver Ticket :

• Aucune communication avec le KDC : pas d'AS-REQ (Event 4768) ni de TGS-REQ (Event 4769) sur les DCs.
• Authentification locale : seul le serveur applicatif voit l'événement, sous forme d'un Event 4624 LogonType 3 (network logon).
• Durée de vie configurable : par défaut 10 ans dans Mimikatz, la longévité est illimitée tant que le hash service n'est pas changé.

L'algorithme de chiffrement choisi est typiquement RC4-HMAC (eType 23) historiquement utilisé avec le hash NTLM, ou AES256-CTS-HMAC-SHA1-96 (eType 18) avec une clé AES dérivée du mot de passe. Les environnements modernes AES-only compliquent significativement l'attaque car ils requièrent l'extraction de la clé AES (et non plus le simple hash NTLM) — une protection que les attaquants contournent via DCSync qui restitue les deux types de clés.

Pré-requis : compromission du hash compte de service

Le Silver Ticket nécessite la possession préalable de la clé long-terme du compte de service ciblé. Cette clé peut prendre plusieurs formes selon le niveau de chiffrement supporté :

• Hash NTLM (RC4) : 32 caractères hexadécimaux, format aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0.
• Clé AES128 (eType 17) : 32 caractères hex, dérivée via PBKDF2 de mot de passe + sel.
• Clé AES256 (eType 18) : 64 caractères hex, dérivée identiquement, recommandée pour AES-only.
• Clé DES (eType 1, 3) : obsolète, désactivée par défaut depuis Windows Server 2008 R2.

Les voies d'obtention de ces clés constituent la phase amont de l'attaque :

• Compte de service utilisateur (SPN-bound) : compromission via Kerberoasting (extraction TGS et cracking offline du hash NTLM si mot de passe faible) ou via DCSync sur le compte spécifique.
• Compte machine ($) : extraction du hash machine localement sur le serveur compromis (LSASS, registre HKLM\SECURITY, secrets DPAPI), via Mimikatz lsadump::secrets ou Impacket secretsdump en local.
• Stockage en clair : configuration applicative (web.config, app.config, fichiers Ansible/Puppet), Group Policy Preferences, scripts batch persistants.
• Vault Windows : credentials stockés via Credential Manager, exfiltrés par Mimikatz vault::cred.
• DCSync ciblé : extraction directe du hash via réplication AD si l'attaquant possède déjà les permissions DRS.

L'identification du SPN et de son compte propriétaire est typiquement réalisée via des outils tels que setspn -Q */*, Get-ADComputer/Get-ADUser -Properties servicePrincipalName ou via BloodHound qui modélise les relations SPN ↔ compte. Pour cibler un service CIFS sur SRV01, l'attaquant cherchera donc le hash machine de SRV01$.

Fabrication du ticket avec Mimikatz

L'implémentation historique du Silver Ticket reste celle du module kerberos::golden de Mimikatz (le nom du module n'a pas changé malgré la dualité golden/silver, le mode est défini par les paramètres). La syntaxe est concise et adaptée aux opérations red team.

Commande de référence :

• kerberos::golden /service:cifs /target:srv01.corp.local /sid:S-1-5-21-... /rc4:<ntlm-hash-machine> /user:Administrator /domain:corp.local /ptt — forge un Silver Ticket CIFS pour SRV01 et l'injecte dans la session.
• kerberos::golden /service:MSSQLSvc /target:sqlsrv.corp.local:1433 /sid:S-1-5-21-... /aes256:<aes-key> /user:Administrator /domain:corp.local /id:500 /ptt — Silver Ticket MSSQL avec clé AES256 (AES-only).
• kerberos::golden /service:HOST /target:dc01.corp.local /sid:S-1-5-21-... /rc4:<hash-dc01$> /user:Administrator /domain:corp.local /ptt — Silver Ticket HOST sur DC, équivalent à PsExec admin.
• kerberos::golden /service:LDAP /target:dc01.corp.local /sid:S-1-5-21-... /rc4:<hash-dc01$> /user:Administrator /domain:corp.local /groups:512,513,518,519,520 /ptt — Silver Ticket LDAP autorisant DCSync ultérieur.
• kerberos::golden /service:HTTP /target:web01.corp.local /sid:S-1-5-21-... /rc4:<hash-iis-svc> /user:Administrator /domain:corp.local /ptt — Silver Ticket pour IIS/SharePoint avec authentification Kerberos.

Paramètres essentiels :

• /service : type de service Kerberos ciblé (CIFS, HOST, MSSQLSvc, LDAP, HTTP, etc.).
• /target : FQDN exact du serveur applicatif (port pour MSSQL si SQL nommée).
• /sid : SID du domaine, obtenu via whoami /user tronqué ou (Get-ADDomain).DomainSID.
• /rc4 ou /aes128 ou /aes256 : clé secrète selon eType supporté.
• /user : nom utilisateur impersonné dans le ticket (typiquement Administrator).
• /id : RID, par défaut 500 (Administrator local), 1106 ou autre selon l'usurpation.
• /groups : RID des groupes, par défaut 513 (Domain Users) — on ajoute 512 (Domain Admins), 519 (Enterprise Admins), 520 (Group Policy Creator Owners) selon l'objectif.
• /ptt : Pass-the-Ticket immédiat, injection dans la session courante.

Une fois injecté, le ticket apparaît dans klist et permet l'accès direct au service ciblé sans nouvelle authentification. Mimikatz reste l'outil de référence en environnement Windows mais déclenche désormais largement les EDR sur signature ; les opérations modernes lui préfèrent souvent Rubeus en .NET reflective load.

Fabrication avec Rubeus (.NET)

Rubeus, développé par Will Schroeder (harmj0y) chez SpecterOps, est l'outil .NET de référence pour la manipulation Kerberos sur AD. Conçu pour s'intégrer avec Cobalt Strike via execute-assembly, il offre une alternative plus discrète à Mimikatz pour la génération de Silver Tickets en opération red team.

Commandes signature :

• Rubeus.exe silver /service:cifs/srv01.corp.local /rc4:<hash> /sid:S-1-5-21-... /user:Administrator /domain:corp.local /ldap /ptt — Silver Ticket CIFS avec injection.
• Rubeus.exe silver /service:MSSQLSvc/sqlsrv.corp.local:1433 /aes256:<key> /sid:S-1-5-21-... /user:Administrator /domain:corp.local /ptt — équivalent AES-only.
• Rubeus.exe silver /service:HOST/dc01.corp.local /rc4:<hash> /sid:S-1-5-21-... /user:Administrator /domain:corp.local /groups:512,519 /ptt — service HOST (PsExec, WMI).
• Rubeus.exe ptt /ticket:<base64-ticket> — injection isolée d'un ticket préalablement généré.
• Rubeus.exe describe /ticket:<base64> — analyse du contenu d'un ticket forgé pour validation.

L'avantage principal de Rubeus est sa signature variable : étant un assembly .NET open source, il peut être recompilé avec obfuscation (ConfuserEx, Garble) pour évader les signatures statiques des EDR. Il s'intègre naturellement aux frameworks de C2 modernes (Cobalt Strike, Sliver, Mythic) via execute-assembly ou inline-execute, évitant le drop sur disque.

Rubeus offre également des sous-commandes complémentaires utiles dans la chaîne d'attaque : kerberoast (extraction TGS pour cracking), asreproast (AS-REP roasting), changepw (modification mot de passe via Kerberos), monitor (surveillance des authentifications).

Fabrication avec Impacket ticketer.py

Impacket ticketer.py, maintenu par la communauté SecureAuth/Fortra, est l'équivalent Python multiplateforme pour la fabrication de tickets Kerberos. Standard de facto en pentest depuis Kali ou Parrot Linux, il est apprécié pour sa portabilité et son intégration avec les autres modules Impacket (psexec, smbclient, mssqlclient).

Commandes signature :

• ticketer.py -nthash <hash-srv01$> -domain-sid S-1-5-21-... -domain corp.local -spn cifs/srv01.corp.local Administrator — génère Administrator.ccache Silver Ticket CIFS.
• ticketer.py -aesKey <aes256-key> -domain-sid S-1-5-21-... -domain corp.local -spn MSSQLSvc/sqlsrv.corp.local:1433 Administrator — version AES256.
• ticketer.py -nthash <hash-dc01$> -domain-sid S-1-5-21-... -domain corp.local -spn HOST/dc01.corp.local -groups 512,519,520 Administrator — Silver Ticket HOST sur DC.
• export KRB5CCNAME=Administrator.ccache && smbclient.py -k -no-pass corp.local/Administrator@srv01.corp.local — usage du ticket via Pass-the-Ticket Linux.
• ticketer.py -nthash <hash> -domain-sid <sid> -domain corp.local -spn HTTP/web01.corp.local -duration 87600 Administrator — durée de vie 10 ans (87600h).

L'argument -spn distingue ticketer en mode Silver Ticket (avec SPN) du mode Golden Ticket (sans SPN, signe avec krbtgt). L'export du ticket en .ccache (Credential Cache MIT) permet son usage via la variable d'environnement KRB5CCNAME et tous les outils Kerberos Linux/macOS, ainsi que les modules Impacket en mode -k.

L'avantage opérationnel d'Impacket est l'absence totale de binaire Windows : le pentester opère depuis sa machine d'attaque Linux, sans déposer le moindre fichier sur les machines compromises Windows, contournant l'essentiel des EDR endpoint.

Services typiquement ciblés et SPN courants

Le choix du service ciblé conditionne complètement l'impact opérationnel du Silver Ticket. Chaque type de SPN ouvre des possibilités spécifiques :

• CIFS : accès aux partages SMB/Windows shares. Permet exfiltration de fichiers, lecture de configurations sensibles, dépôt de payloads sur shares administratifs (\\srv\C$, \\srv\ADMIN$). Le plus utilisé en pratique offensive.
• HOST : couvre plusieurs services Windows dont WMI, PsExec, SC Manager, Task Scheduler. Un Silver Ticket HOST sur un serveur permet l'exécution de commandes via wmiexec.py, psexec.py, smbexec.py — équivalent à un compte admin local.
• MSSQLSvc : accès à SQL Server avec authentification Kerberos. Ciblé pour exfiltration de bases de données sensibles, exécution de xp_cmdshell, mouvement latéral via SQL trust.
• LDAP : accès à l'annuaire AD via le compte machine du DC. Ouvre la voie à des opérations LDAP privilégiées, et même à un DCSync ultérieur si les groupes Domain Admins sont injectés dans le ticket.
• HTTP : authentification Kerberos pour IIS, SharePoint, OWA Exchange, applications web internes. Permet de s'authentifier en tant qu'administrateur sur des portails métier.
• HTTPS : variante TLS du précédent.
• WSMAN : Windows Remote Management, exécution PowerShell remote via WinRM.
• RPC/RPCSS : Remote Procedure Call services, mouvement latéral RPC.
• TERMSRV : Remote Desktop Services, accès RDP authentifié Kerberos (rare en pratique, exige aussi accès console).
• FTP, IMAP, POP3, NNTP, AGPM : services moins courants mais valides selon environnement.

L'attaquant choisit le service en fonction de son objectif : pour exfiltrer un partage de fichiers RH, CIFS ; pour piller une base SQL clients, MSSQLSvc ; pour persister sur un DC, HOST + LDAP. Combiner plusieurs Silver Tickets sur les SPN d'un même compte machine multiplie la surface d'accès tout en restant invisible côté KDC.

Propriétés caractéristiques : pas de contact DC, furtivité maximale

Les propriétés distinctives du Silver Ticket méritent une analyse détaillée car elles structurent à la fois sa puissance offensive et les contre-mesures défensives.

Propriété 1 — Aucune sollicitation du KDC. C'est la caractéristique cardinale. Le ticket étant pré-signé avec la clé du service, le serveur applicatif valide localement sans contacter aucun DC. Conséquence directe : aucun Event 4768 (Kerberos AS Request) ni 4769 (Kerberos TGS Request) n'est émis sur les contrôleurs de domaine. Toutes les détections natives basées sur l'analyse des logs DC sont aveugles à l'attaque.

Propriété 2 — Authentification locale uniquement visible. Le seul événement généré est sur le serveur applicatif lui-même : un Event 4624 (successful logon) avec LogonType 3 (network logon) et Authentication Package = Kerberos. Sans corrélation cross-machine et sans enrichissement contextuel (host distant, compte impersonné), cet événement est indistinguable d'une authentification légitime.

Propriété 3 — Durée de vie illimitée par défaut. Mimikatz et ticketer.py forgent par défaut des tickets valides 10 ans (87600 heures). Tant que le hash du compte de service n'est pas modifié, le ticket reste utilisable indéfiniment, conférant une persistance silencieuse remarquable.

Propriété 4 — Possibilité d'injecter des groupes arbitraires. La PAC inclut les RID de groupe (Domain Admins 512, Enterprise Admins 519, etc.) que l'attaquant fixe librement. Si le service ne réalise pas la PAC validation auprès du DC, ces appartenances usurpées sont acceptées telles quelles.

Propriété 5 — Scope strictement limité au service. Contrairement au Golden Ticket, le Silver Ticket ne donne pas accès à d'autres services : il faut un nouveau ticket par SPN ciblé. Cette limitation est exploitée défensivement (segmentation Tier) mais aussi offensivement (ciblage chirurgical pour réduire les traces).

Propriété 6 — Bypass partiel des Authentication Policies/Silos. Selon configuration, certaines politiques d'authentification ne sont évaluées qu'au TGS issuance par le KDC ; un Silver Ticket pré-forgé peut les contourner.

Différences avec Golden Ticket et Pass-the-Ticket

Comprendre les différences fines entre Silver Ticket, Golden Ticket et Pass-the-Ticket est essentiel pour analyser correctement les compromissions et choisir les contre-mesures adaptées.

Silver Ticket vs Golden Ticket :

• Type de ticket : Silver = TGS (service ticket), Golden = TGT (ticket granting ticket).
• Clé de signature : Silver = hash du compte service ciblé, Golden = hash du compte krbtgt.
• Scope : Silver = un service unique sur un serveur unique, Golden = tout le domaine sur tous les services.
• Pré-requis : Silver = compromission compte service (souvent obtenu via Kerberoasting), Golden = compromission krbtgt (typiquement via DCSync sur DA).
• Détection : Silver = très difficile (pas d'event DC), Golden = possible via Event 4769 anormaux (TGS forgés à partir d'un TGT non émis par DC).
• Furtivité : Silver >> Golden (Silver totalement transparent au KDC).
• Mitigation : Silver = rotation hashes service / gMSA, Golden = double rotation krbtgt.

Silver Ticket vs Pass-the-Ticket :

• Origine du ticket : Silver = ticket forgé localement à partir d'un hash, Pass-the-Ticket = ticket volé depuis la mémoire (LSASS) d'un utilisateur authentifié.
• Pré-requis : Silver = hash du service, PtT = accès LSASS d'une session active.
• Identités possibles : Silver = n'importe quel utilisateur impersonné, PtT = identité du compte volé uniquement.
• Détection : Silver = via PAC validation et event endpoint, PtT = via détection LSASS access.

Une chaîne classique combine les trois : compromission initiale → vol de TGT légitime via PtT → escalade vers compte avec droits DRS → DCSync pour extraire krbtgt → forge Golden Ticket → mouvement latéral → forge de Silver Tickets pour persistance discrète sur assets critiques. Chaque étape utilise la technique la plus adaptée à son contexte de risque/détection.

Détection : Event 4624 LogonType 3 et corrélation

La détection du Silver Ticket constitue l'un des défis majeurs de la défense AD moderne, précisément en raison de l'absence d'événement KDC. Les approches efficaces combinent télémétrie endpoint, corrélation cross-machine et heuristiques de PAC anormales.

Event 4624 (logon endpoint). Sur le serveur ciblé, l'authentification réussie par Silver Ticket génère un Event 4624 avec :

• LogonType 3 (network logon).
• Authentication Package = Kerberos.
• SubjectUserName / TargetUserName = utilisateur impersonné dans le ticket (souvent Administrator).
• WorkstationName = nom de la machine attaquante (peut être falsifié).
• LogonGUID = GUID de la session Kerberos.

La règle de détection canonique consiste à corréler Event 4624 avec absence de Event 4769 préalable sur les DCs pour le même utilisateur et le même SPN dans une fenêtre temporelle proche (5-15 minutes). Toute authentification Kerberos réussie sans TGS-REQ correspondante sur le KDC est un indicateur fort de Silver Ticket.

PAC Signature Validation. La contre-mesure cryptographique fondamentale est la PAC validation : le service applicatif soumet la PAC du ticket reçu au DC via NetrLogonSamLogonEx, qui re-vérifie cryptographiquement la signature avec krbtgt. Si l'attaquant a forgé arbitrairement les groupes, la signature ne correspond pas et le DC répond avec un échec. Côté détection, une augmentation des Events 4769 d'échec ou des appels NetrLogon refusés indique des tentatives Silver Ticket.

Microsoft a renforcé cette validation via la suite de patches Kerberos hardening (KB5008380, KB5020805 et suivants en 2022-2024), forçant la PAC signature stricte sur tous les services par défaut depuis octobre 2024. Cette évolution réduit drastiquement l'efficacité du Silver Ticket en environnements à jour.

Heuristiques avancées. Plusieurs indicateurs comportementaux complètent la détection :

• Durée de vie anormale : tickets de 10 ans là où les tickets légitimes ont une durée de 10 heures par défaut.
• eType RC4 (eType 23) dans des environnements AES-only — toute apparition de RC4 doit être suspecte.
• Compte machine source incohérent : Silver Ticket usurpant Administrator depuis une workstation utilisateur.
• Volumétrie d'accès CIFS/MSSQL inhabituelle depuis un host non habilité.

Détection avancée : Defender for Identity et Sentinel

Les solutions XDR/SIEM modernes intègrent des heuristiques spécifiques anti-Silver Ticket allant au-delà de la corrélation native Windows.

Microsoft Defender for Identity (anciennement Azure ATP) inclut depuis 2018 des règles dédiées à la détection des tickets forgés. La règle Suspected Kerberos golden ticket usage couvre techniquement aussi les Silver Tickets via l'analyse des PAC anormales et des sessions Kerberos sans authentification préalable. L'intégration avec Microsoft Defender XDR remonte l'alerte dans le SOC unifié et corrèle avec les événements MDE et Sentinel cross-machine.

Microsoft Sentinel propose des analytic rules KQL natives, exemples :

• SecurityEvent | where EventID == 4624 | where LogonType == 3 | where AuthenticationPackageName == "Kerberos" | join kind=leftanti (SecurityEvent | where EventID == 4769) on $left.TargetUserName == $right.TargetUserName
• Détection des tickets avec lifetime > 24h via parsing de TicketOptions.

Splunk Enterprise Security fournit des correlation searches dans le Security Content Update (SCU) catégorie endpoint_credential_access couvrant les patterns Silver/Golden Ticket via les sourcetypes WinEventLog:Security.

QRadar, Elastic Security, Sumo Logic, Exabeam, ArcSight incluent tous des règles équivalentes basées sur l'absence de 4768/4769 corrélée à 4624 Kerberos, ainsi que sur l'analyse PAC.

Au niveau réseau, les solutions NDR (Vectra, Darktrace, ExtraHop) inspectent les flux Kerberos pour identifier les tickets dont les caractéristiques (lifetime, eType, signature) sortent de la baseline. Zeek avec scripts Kerberos dédiés permet une analyse open-source équivalente.

Mitigation : gMSA, AES-only, rotation et PAC validation

La défense contre le Silver Ticket s'organise autour de quatre axes structurels : élimination du facteur "hash compromettable", durcissement cryptographique, validation systématique et segmentation.

Group Managed Service Accounts (gMSA). Introduits en Windows Server 2012, les gMSA remplacent les comptes de service classiques par des comptes dont le mot de passe est géré et tourné automatiquement par AD tous les 30 jours. L'attaquant qui aurait extrait un hash gMSA dispose d'une fenêtre d'exploitation maximale de 30 jours, après quoi le hash est obsolète et tout Silver Ticket forgé devient inopérant. Tous les comptes de service (SQL, IIS, Tâches planifiées critiques) doivent migrer vers gMSA via Add-KdsRootKey et New-ADServiceAccount -DNSHostName ... -ManagedPasswordIntervalInDays 30.

Politique AES-only. Désactiver explicitement le support RC4 sur les comptes critiques via la propriété msDS-SupportedEncryptionTypes (valeur 24 = AES128 + AES256, sans RC4). Combinée à des mots de passe complexes et longs (>25 caractères) sur les comptes machine, cette mesure rend le Kerberoasting offline impraticable et complique l'extraction de la clé AES.

Rotation manuelle des hashes service. Pour les comptes ne pouvant pas migrer vers gMSA, planifier une rotation périodique (90 jours maximum) du mot de passe via Set-ADAccountPassword ou outils LAPS étendus. Toute suspicion de compromission impose une rotation immédiate.

Activation PAC Signature Validation. Forcer la PAC validation côté service via la clé registre HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\ValidateKdcPacSignature = 1 et appliquer les patches Kerberos hardening Microsoft (KB5020805 et suivants). Depuis octobre 2024, le mode strict est forcé par défaut sur les services Microsoft modernes.

Modèle Tier 0/1/2. Les comptes de service Tier 0 (DC, ADCS, AD Connect) doivent être strictement isolés via Authentication Policies/Silos, empêchant toute usurpation depuis Tier inférieur. La compromission d'un service Tier 2 (workstation, application métier) ne doit pas permettre la forge d'un Silver Ticket sur un service Tier 0.

Surveillance Kerberoasting amont. Bloquer la chaîne d'attaque en amont via détection des TGS-REQ avec eType RC4 sur des SPN à haute valeur, et durcissement des mots de passe service (taille > 25 caractères, complexité maximale) qui rend le cracking offline irréalisable.

Indicateurs de compromission (IoC) typiques

Lors d'une réponse à incident, plusieurs IoC orientent vers une exploitation de Silver Ticket :

• Event 4624 Kerberos LogonType 3 sans Event 4769 corrélé sur les DCs dans une fenêtre de 30 minutes.
• Tickets klist avec EndTime à plusieurs années dans le futur (lifetime > 24h sur poste utilisateur).
• eType 23 (RC4) dans des environnements AES-only, sur services critiques.
• Process Sysmon Event 1 : exécution de mimikatz.exe, Rubeus.exe, ou ticketer.py sur poste compromis.
• Accès LSASS anormaux : Event 10 Sysmon avec GrantedAccess 0x1010 ou 0x1410 ciblant lsass.exe.
• Connexions CIFS/MSSQL inhabituelles depuis une workstation utilisateur vers serveur sensible, sans 4769 préalable.
• PAC signature failures remontées par les services en mode strict (Kerberos hardening).
• Comptes Administrator apparaissant authentifiés sur des serveurs depuis hosts inhabituels.
• Fichiers résiduels : .kirbi, .ccache, tickets.txt, dump de hashes machine sur disque.
• Mimikatz signatures : présence de samlib.dll, vaultcli.dll, cryptdll.dll chargés sur process anormaux.
• Connexions BloodHound préalables : SharpHound + recherche de chemins Kerberoast/Silver Ticket.

La corrélation temporelle de ces événements (Kerberoasting → cracking offline → forge Silver Ticket → accès CIFS/MSSQL/HOST sous 24-48h) est le pattern canonique des attaques humaines documentées dans les rapports Mandiant M-Trends et CrowdStrike Global Threat Report.

Chaîne d'attaque typique : Kerberoasting → Silver Ticket

Le Silver Ticket s'inscrit rarement isolément ; il fait partie d'une chaîne offensive bien établie. Le pattern canonique observé en compromission AD documente :

1. Compromission initiale : phishing, exploitation web exposée, supply chain — obtention d'un compte utilisateur basique.
2. Énumération : SharpHound + BloodHound pour identifier les comptes de service avec SPN.
3. Kerberoasting : extraction des TGS via Rubeus kerberoast ou GetUserSPNs.py.
4. Cracking offline : hashcat mode 13100 (Kerberos 5 TGS-REP eType 23) sur les hashes extraits.
5. Identification du SPN cible : recherche du compte service possédant le SPN du serveur sensible.
6. Forge Silver Ticket : kerberos::golden /service:CIFS /target:srv01 /rc4:<hash-cracké> /sid:... /user:Administrator /ptt.
7. Accès au service : dir \\srv01\C$, exfiltration silencieuse.
8. Persistance : Silver Ticket valide pour la durée de vie du mot de passe (souvent années sur services legacy).

Une variante chaînée combine Silver Ticket sur le compte machine d'un DC pour simuler un DC légitime et préparer un DCSync furtif via LDAP. D'autres scénarios exploitent la combinaison Pass-the-Hash sur compte utilisateur → extraction LSASS → hash machine → Silver Ticket HOST → mouvement latéral discret.

Cette chaîne explique pourquoi la défense doit traiter le Silver Ticket non comme une attaque isolée mais comme un maillon de persistance dans une séquence : couper l'amont (durcissement Kerberoasting, gMSA) ou l'aval (PAC validation stricte) reste la priorité.

Mapping MITRE ATT&CK et frameworks de référence

Le Silver Ticket est officiellement référencé dans MITRE ATT&CK sous l'identifiant T1558.002, sous-technique de T1558 (Steal or Forge Kerberos Tickets), tactique Credential Access (TA0006) et Defense Evasion (TA0005). La fiche officielle attack.mitre.org/techniques/T1558/002 documente :

• Procedure examples : APT32 (OceanLotus), APT41, FIN6, Indrik Spider (Evil Corp), LockBit affiliates.
• Software : Mimikatz (S0002), Impacket (S0357), Rubeus (S0683).
• Mitigations : M1015 (Active Directory Configuration), M1027 (Password Policies), M1041 (Encrypt Sensitive Information), M1026 (Privileged Account Management).
• Detections : DS0002 (User Account), DS0026 (Active Directory Object Access), DS0028 (Logon Session Creation).

Au niveau frameworks complémentaires, le Silver Ticket apparaît dans :

• NIST SP 800-53 Rev.5 : contrôles AC-2 (Account Management), AC-6 (Least Privilege), IA-5 (Authenticator Management), AU-2 (Audit Events).
• CIS Controls v8 : Control 4 (Secure Configuration), Control 5 (Account Management), Control 6 (Access Control Management), Control 8 (Audit Log Management).
• ANSSI guide ADM : recommandations spécifiques sur la gestion des comptes de service et l'usage de gMSA.
• Microsoft Securing Privileged Access (SPA) : roadmap incluant la migration gMSA et la PAC validation.

CVE et incidents documentés

Comme pour le Golden Ticket et DCSync, le Silver Ticket lui-même n'a pas de CVE associé car il abuse une fonctionnalité protocolaire légitime de Kerberos plutôt qu'une vulnérabilité corrigeable. Cependant, plusieurs CVE concernent la chaîne en amont (compromission du hash service) ou les contournements de la PAC validation :

• CVE-2014-6324 (MS14-068) : élévation de privilèges Kerberos via PAC forgée — patche un bug de validation PAC qui aurait facilité les Silver Tickets, désormais comblé.
• CVE-2020-17049 (Kerberos Bronze Bit) : contournement de la délégation contrainte via flag Forwardable, technique apparentée.
• CVE-2022-37966 et CVE-2022-37967 : Kerberos elevation via RC4-MD4 (Kerberos hardening), corrigés par KB5020805.
• CVE-2024-20674 : Kerberos security feature bypass, renforce la stricte validation des tickets.

Sur le plan des incidents documentés, plusieurs campagnes ransomware d'envergure ont publiquement utilisé Silver Ticket dans leur chaîne :

• NotPetya (2017) : combinaison Mimikatz + tickets forgés pour propagation latérale.
• Ryuk / Conti (2019-2022) : Silver Tickets CIFS pour exfiltration avant chiffrement.
• LockBit 3.0 (2022-2024) : usage massif de Silver Tickets HOST pour persistance discrète.
• BlackCat/ALPHV (2023) : combinaison Kerberoasting → Silver Ticket MSSQL pour piller bases métier.

Les rapports Mandiant M-Trends 2024 et CrowdStrike GTR 2025 confirment que le Silver Ticket figure dans le top 10 des techniques observées en intrusion AD, avec une croissance de 35% sur les deux dernières années portée par la généralisation de Rubeus et Cobalt Strike.

FAQ — Questions fréquentes sur le Silver Ticket

Quelle est la principale différence entre Silver Ticket et Golden Ticket ?

La différence fondamentale réside dans le type de ticket Kerberos forgé et dans la clé de signature utilisée. Le Golden Ticket est un TGT (Ticket Granting Ticket) signé avec le hash du compte krbtgt, qui ouvre l'accès à tous les services du domaine car il permet de demander n'importe quel TGS au KDC. Le Silver Ticket est un TGS (Ticket Granting Service) signé avec le hash du compte de service propriétaire d'un SPN spécifique, qui n'ouvre l'accès qu'à ce service unique sur ce serveur unique. Pré-requis et furtivité diffèrent également : Golden exige la compromission de krbtgt (typiquement via DCSync et donc un compte Domain Admin), tandis que Silver exige seulement le hash d'un compte de service (souvent obtenu via Kerberoasting). En revanche, Silver est nettement plus furtif que Golden car il ne sollicite jamais le KDC et ne génère aucun Event 4768/4769 sur les DCs.

Le Silver Ticket fonctionne-t-il encore en 2026 avec les patches Kerberos hardening ?

Oui mais avec une efficacité significativement réduite sur les environnements à jour. Les patches Microsoft Kerberos hardening (KB5008380 de 2021, KB5020805 de novembre 2022, et la suite de 2023-2024) imposent progressivement la PAC signature validation stricte, qui force le service applicatif à vérifier auprès du DC la signature interne de la PAC avec la clé krbtgt. Depuis octobre 2024, ce mode strict est activé par défaut sur la majorité des services Microsoft. Conséquence : un Silver Ticket forgé arbitrairement (avec groupes Domain Admins injectés) est rejeté car la signature ne peut pas correspondre. Toutefois, l'attaque reste exploitable dans plusieurs cas : (1) services tiers ou legacy ne supportant pas la nouvelle PAC validation, (2) environnements non patchés, (3) Silver Tickets sans escalation de groupes (juste impersonation simple), (4) contournements via downgrade RC4 sur comptes mal configurés. La défense moderne combine donc patches à jour, gMSA, AES-only et monitoring comportemental.

Comment détecter un Silver Ticket si aucun log DC n'est généré ?

La détection efficace combine plusieurs signaux endpoint et heuristiques cross-machine : (1) corrélation négative entre Event 4624 Kerberos LogonType 3 sur le serveur applicatif et l'absence d'Event 4769 correspondant sur les DCs dans la fenêtre temporelle proche, (2) analyse des caractéristiques anormales du ticket (lifetime > 24h, eType RC4 dans environnement AES-only, groupes incohérents), (3) déploiement de Defender for Identity qui inclut nativement des heuristiques anti-Silver Ticket via PAC analysis, (4) activation de la PAC signature validation stricte qui, en cas d'échec, génère des événements détectables, (5) monitoring endpoint via Sysmon (Event 1 pour mimikatz/Rubeus, Event 10 pour accès LSASS), (6) corrélation BloodHound préalable + Kerberoasting + accès anormal sur asset critique. Aucune méthode unique ne couvre 100% des cas, d'où la recommandation de défense en profondeur via SIEM avec règles cumulatives.

Les gMSA protègent-ils vraiment contre le Silver Ticket ?

Oui, les gMSA (group Managed Service Accounts) constituent la mitigation structurelle la plus efficace contre le Silver Ticket. Le mécanisme fondamental est la rotation automatique du mot de passe tous les 30 jours par AD lui-même, sans intervention manuelle ni risque d'oubli. Concrètement, même si un attaquant extrait le hash NTLM ou la clé AES d'un compte gMSA via DCSync ou compromission machine, sa fenêtre d'exploitation est limitée à 30 jours maximum. Tout Silver Ticket forgé avec ce hash devient inopérant après la rotation. Couplé à l'usage de mots de passe gMSA de 240 caractères aléatoires (impossibles à cracker offline), la protection est très forte. La migration des comptes de service classiques vers gMSA est donc une recommandation majeure des guides Microsoft, ANSSI et CIS pour 2026. Limitations : tous les services applicatifs ne supportent pas encore gMSA nativement (notamment certains services tiers anciens), mais la majorité des produits Microsoft (SQL Server, IIS, Tâches planifiées, ADFS, Exchange) sont compatibles.

Combien de temps reste valide un Silver Ticket ?

Par défaut, Mimikatz et Impacket ticketer.py forgent des Silver Tickets avec une durée de vie de 10 ans (87600 heures), valeur arbitrairement choisie par Benjamin Delpy en 2014 pour démontrer le caractère illimité de la persistance. En pratique, la validité réelle du ticket dépend uniquement de la non-modification du hash du compte de service ciblé : tant que le mot de passe n'est pas changé, le ticket reste utilisable. Sur des comptes de service classiques sans rotation (cas malheureusement fréquent en environnement legacy), un Silver Ticket peut donc effectivement persister plusieurs années. Sur comptes gMSA, la rotation 30 jours invalide automatiquement le ticket. Sur comptes machine ($), la rotation par défaut Windows est de 30 jours également (configurable via MaximumPasswordAge) mais nombre d'environnements ont désactivé cette rotation pour éviter des problèmes opérationnels — créant alors une fenêtre infinie pour un Silver Ticket. La recommandation 2026 est de laisser activée la rotation automatique du mot de passe machine et de migrer tout compte de service vers gMSA.

Peut-on forger un Silver Ticket pour DCSync ultérieur ?

Oui, c'est une technique avancée documentée. Le principe consiste à forger un Silver Ticket pour le SPN LDAP ou HOST du compte machine d'un DC (par exemple DC01$), en injectant dans la PAC les groupes Domain Admins (512), Enterprise Admins (519) et BUILTIN\Administrators. Une fois ce ticket injecté via /ptt, l'attaquant possède une session apparemment légitime auprès du DC avec privilèges de réplication, lui permettant d'invoquer DRSGetNCChanges et donc d'effectuer un DCSync. Cette approche est particulièrement furtive car le DCSync est alors réalisé via une session pré-autorisée Kerberos, sans qu'aucun Event 4768/4769 ne précède l'opération. La défense passe par : (1) PAC validation stricte côté DC qui rejette les groupes injectés non signés correctement, (2) audit Event 4662 sur les opérations DRS pour identifier toute réplication initiée par un host non-DC, (3) déploiement Defender for Identity qui détecte les sessions Kerberos suspectes vers les DCs.

Pour aller plus loin : ressources et articles approfondis

Pour approfondir la maîtrise des attaques Kerberos et la défense contre le Silver Ticket, consultez nos guides spécialisés :

• Active Directory : annuaire Microsoft et sécurité — fondamentaux indispensables.
• Golden Ticket : attaque Kerberos et persistance AD — l'attaque sœur ciblant krbtgt.
• Mimikatz : extraction de credentials Active Directory — l'outil emblématique de forge de tickets.
• Kerberoasting : attaque et défense — phase amont fréquente vers Silver Ticket.
• DCSync : attaque de réplication Active Directory — voie alternative d'extraction des hashes.
• Pass-the-Hash : attaque NTLM et Active Directory — technique connexe d'usurpation.
• BloodHound : cartographie des chemins d'attaque AD — identifier les SPN exploitables.
• Microsoft Defender XDR et sécurité unifiée — détection Silver Ticket via Defender for Identity.
• Service de pentest Active Directory — audit professionnel par notre équipe.

Ressources externes officielles :

• attack.mitre.org/techniques/T1558/002 — fiche MITRE ATT&CK officielle Silver Ticket.
• adsecurity.org/?p=2011 — référence Sean Metcalf sur Silver Ticket et défense AD.
• github.com/gentilkiwi/mimikatz — dépôt officiel de Mimikatz par Benjamin Delpy.
• learn.microsoft.com — Kerberos authentication overview — documentation officielle Microsoft.