Kerberos : Attaque Golden ticket
Attaque Golden ticket
Dans un précédent article, le fonctionnement du protocole Kerberos a été expliqué pour permettre de poser les bases à la compréhension de l’attaque Golden Ticket décrite dans ce nouvel article.
La sécurité de ce protocole repose sur l’utilisation de secrets partagés pour le chiffrement et la signature des messages. Certains de ces secrets sont partagés entre le KDC et les clients, mais un en particulier n’est connu que par le KDC, c’est le secret de l’utilisateur krbtgt, dont le hash du mot de passe est utilisé pour signer ou chiffrer les tickets Kerberos émis par le KDC.
En d’autres termes, compromettre le hash krbtgt peut faire des ravages dans une organisation car il peut être utilisé pour usurper l’identité de l’authentification dans toute l’organisation, de se comporter comme s’il était un Active Directory, donnant ainsi à un attaquant l’accès à des données sensibles.
À l’aide d’un Golden Ticket, les attaquants peuvent alors demander des tickets de (TGS), qui permettent d’accéder à des ressources spécifiques. Les golden tickets exigent que les attaquants interagissent avec le centre de distribution de clés (KDC) afin d’obtenir le TGS et de générer des éléments d’authentification pour n’importe quel compte dans Active Directory.
Le hash du mot de passe krbtgt peut être obtenu en utilisant un dump des informations d’identification du système d’exploitation pour avoir un accès privilégié à un contrôleur de domaine. Cette capacité est à la fois extrêmement puissante et difficile à détecter.
Plusieurs outils peuvent être utilisés à la fois par des attaquants et les auditeurs de sécurité. Des outils développés spécifiquement mais non publics existent probablement également.
Pour créer et utiliser un Golden Ticket, l’attaquant doit trouver un moyen d’accéder au réseau :
1. Compromettre un ordinateur cible avec un malware qui lui permettra d’utiliser des comptes utilisateur pour accéder à d’autres ressources réseau (souvent à partir d’un e-mail de phishing et l’exploitation d’une vulnérabilité)
2. Compromettre un utilisateur qui dispose des privilèges de réplication ou d’accès d’administrateurs à un contrôleur de domaine. Les membres des groupes Administrateurs, Administrateurs de Contrôleurs de domaine ont ces privilèges par défaut.
3. Se connecter au DC et obtenir via un dump le hash du mot de passe du compte Krbtgt afin de créer le Golden Ticket.
L’attaquant peut utiliser mimikatz, Impacket ou un autre outil d’exploitation de vulnérabilités similaire afin d’extraire le hash du mot de passe à partir d’un dump.
Mimikatz de base est un outil de sécurité offensive incroyablement efficace développée par Benjamin Delpy, cet outil a été créé pour démontrer les vulnérabilités de l’Active Directory de Microsoft. Ses fonctionnalités offrent aux auditeurs et aux attaquants un moyen facile de récupérer les informations d’identification d’un réseau cible. Depuis quelques années Delpy à ajouter une nouvelle fonctionnalité dans Mimikatz pour forger les golden ticket Kerberos, ce qui a donné plus d’avantages aux attaquants.
En utilisant Mimikatz, il est possible d’exploiter les informations de mot de passe du compte krbtgt pour créer des tickets Kerberos falsifiés (TGT) qui peuvent être utilisés pour demander des tickets TGS pour n’importe quel service sur n’importe quel ordinateur du domaine.
Pour créer un TGT particulier du compte admin du domaine, l’attaquant doit spécifier certaines informations pour mimikatz kerberos::golden
Utilisateur : Le nom du compte utilisateur pour lequel le ticket sera créé. Cela peut être un vrai nom de compte.
ID : Le RID du compte qui sera emprunté. Il peut s’agir d’un véritable ID de compte, tel que l’ID administrateur par défaut de 500, ou un faux ID.
Rc4 : le hash NTLM du mot de passe
Groupes : Une liste de groupes auxquels appartiendra le compte du ticket. Cela inclura les administrateurs de domaine par défaut, de sorte que le ticket soit créé avec les privilèges maximum.
SID : le SID du domaine. Ceci est utile pour s’authentifier sur plusieurs domaines
Ptt (optionnel) : pour injecter immédiatement le faux ticket dans la session en cours
NB : Le golden ticket peut être généré depuis n’importe quelle machine, même hors du domaine
4. Il ne reste qu’à charger le ticket Kerberos.
Comment détecter une attaque Golden ticket ?
En cas de compromission, un ticket Golden Ticket Kerberos est difficile à détecter. Cette difficulté repose sur le fait de distinguer des utilisateurs légitimes au sein d’un réseau. L’analyste doit supposer que toutes les données d’un domaine compromis auraient pu être exposées.
Pour commencer, il est nécessaire de différencier tous les tickets légitimes de ceux qui ne le sont pas sur le réseau de l’organisation. Une tâche complexe, surtout dans les grands systèmes d’information. Il faut examiner tous les accès suspects des comptes d’utilisateurs aux systèmes ciblés, puis chercher la présence de logiciels malveillants ou de vulnérabilités exploitables.
La détection d’une attaque Golden Ticket dépend aussi de la méthode utilisée. Si l’outil Mimikatz a été déposé dans votre environnement, un antivirus peut l’identifier et le bloquer. Cependant, Mimikatz étant très simple à modifier, il est facile de changer son empreinte et ainsi la détection par hash devient obsolète. Une surveillance comportementale peut détecter Mimikatz malgré les modifications.
Dans le cas où l’utilisation d’un tel outil passe sous les radars de la cybersurveillance, la détection de l’utilisation d’un golden ticket nécessite d’analyser tous les tickets Kerberos en détails afin de trouver des indices indiquant un ticket compromis. Pour cela, un analyste doit vérifier :
- Nom d’utilisateur : s’il correspond à la nomenclature standard de l’organisation, incompatibilités de nom d’utilisateur et de RID et la modification dans les groupes à privilèges.
- Durée de vie du ticket TGT : sur un Active Directory la durée de vie standard d’un ticket utilisateur est de 10 heures.
Par défaut, Mimikatz génère des tickets valides pour 10 ans. Cependant, seuls les attaquants motivés prendront des mesures pour ne pas se faire détecter en adaptant les paramètres par défaut de l’outil.
- Types de chiffrement : par exemple, RC4 utilisé à la place d’AES-256
- Nom de domaine : vérifier que le nom de domaine existe dans l’organisation. Si la version mimikatz utilisée est ancienne, le nom de domaine peut être une chaîne aléatoire contenant « eo.oe »
Il est possible d’explorer également les informations du journal Windows pour les contrôleurs de domaine. Pour cela, il est important que la journalisation appropriée soit activée avec les GPOs suivantes :
- Account login : Audit Kerberos Authentication Service
- Detailed Tracking : Process Creation
- Logon/Logoff : Audit Special Logon
Pour Détecter des signes des golden tickets, les évènements suivants sont nécessaires pour bien mener l’investigation.
| Event.id | Nom de l’évènement | Description |
| 4768 | Un ticket d’authentification Kerberos (TGT) a été demandé | Quand un golden ticket est utilisé, cet évènement n’est pas enregistré |
| 4769 | Un ticket de service Kerberos a été demandé | Lorsqu’un service est accessible en utilisant un TGT incluant le golden ticket, cet événement est enregistré |
| 4688 | Un nouveau processus a été créé | Contient toutes les informations relatives aux processus, y compris les commandes d’attaque exécutées |
| 4672 | Privilèges spéciaux affectés à la nouvelle connexion. | Contient des informations sur les comptes qui utilisent des privilèges administratifs |
| 4738 | Un compte utilisateur a été modifié | Contient des informations sur les comptes modifiés. Cet event.id peut être utilisé pour surveiller la modification du mot de passe du compte krbtgt |
Certaines informations peuvent être vérifiées dans l’évènement 4769. Par exemple, des utilisateurs, des domaines qui n’existent pas dans l’environnement ou le type de chiffrement du ticket (0x17). Windows a ajouté le chiffrement Kerberos AES, ce qui signifie que la plupart des demandes Kerberos seront chiffrées AES sur n’importe quel système d’exploitation Windows à jour. Toute demande de ticket Kerberos avec un chiffrement RC4 doit être considérée comme suspecte et investiguée.
Les attaquants peuvent utiliser le compte krbtgt afin d’établir la persistance de l’attaque, et c’est pourquoi, il est recommandé de changer le mot de passe du compte krbtgt régulièrement. Lors d’un changement de mot de passe du compte krbtgt, Microsoft-AD garde en cache l’ancien hash pour permettre de garantir que le changement de mot de passe puisse être répliqué vers l’ensemble des contrôleurs de domaine. Il existe deux scénarios de changement de mot de passe krbtgt :
- Maintenance : la modification du mot de passe du compte krbtgt une fois, ensuite, attendre la fin de la réplication et la durée égale ou supérieure à la durée de vie maximale du ticket Kerberos, puis la modification du mot de passe une deuxième fois, pour supprimer efficacement l’historique des mots et garantir que le compte krbtgt est protégé.
- Breach Recovery : la modification du mot de passe du compte krbtgt deux fois de suite (avant la fin de la réplication AD). Par contre, cela va rendre tous les tickets TGT de Kerberos existants invalides, ce qui obligera les clients/services à se réauthentifier car le service KDC ne pourra plus déchiffrer les TGT existants.
L’ANSSI recommande actuellement de changer le mot de passe du compte krbtgt tous les 40 jours.
Comment se protéger contre l’attaque Golden Ticket ?
La protection contre une attaque du type « Golden Ticket » n’est pas si différente de la protection contre tout autre malware ou attaque d’infiltration. En fin de compte, un attaquant a besoin d’un accès privilégié pour créer le golden ticket. Pour atténuer le risque, il est nécessaire de se concentrer sur les activités qui empêchent les attaquants de compromettre l’accès privilégié à Active Directory.
- Restreindre les droits de connexion du contrôleur de domaine. Il doit y avoir le nombre minimum absolu d’admins de domaine.
- Réinitialiser le compte KRBTGT régulièrement.
- Appliquer une politique de moindres privilèges pour les comptes de services et les comptes utilisateurs, notamment les comptes utilisateurs à pouvoirs (administrateurs).
- Prévenir les attaques et détecter les compromissions au plus tôt avant qu’elles n’aboutissent. Notamment en renforçant la sensibilisation à la sécurité, sur la réutilisation des mots de passe et les attaques de phishing, et en menant une gestion vigilante des correctifs.
- Protéger les Endpoints, il existe de nombreuses nouvelles solutions (Next-Gen AV, EDR, XDR …) pour les protéger. Cela évitera que les attaquants installent des outils comme mimikatz.
Conclusion
Kerberos est un protocole de sécurité de réseau informatique qui authentifie les demandes de service entre deux hôtes de confiance ou plus sur un réseau non approuvé, comme Internet. Il utilise la cryptographie à clé secrète et un tiers de confiance pour authentifier les applications client-serveur et vérifier l’identité des utilisateurs. Les utilisateurs, les machines et les services qui utilisent Kerberos dépendent uniquement du KDC, qui fonctionne comme un processus unique offrant deux fonctions : l’authentification et l’octroi de tickets.
Malgré cela, Kerberos reste le meilleur protocole d’authentification sécurisé disponible aujourd’hui. Il est suffisamment flexible pour adopter de nouveaux algorithmes de chiffrement en fonction de ses évolutions afin d’en renforcer la fiabilité et la sécurité. Mais, des contournements du protocole reste toujours possible comme les golden tickets et silver tickets. Les attaquants ont eu l’occasion au fil des ans de trouver des moyens de le contourner, comme par exemple en forgeant des tickets en utilisant des outils comme Mimikatz.
L’attaque Golden Ticket est particulièrement dévastatrice car elle permet aux attaquants de falsifier des tickets Kerberos en compromettant le service krbtgt qui génère et valide les tickets Kerberos dans Active Directory.
Cette attaque donne à un attaquant un accès étendu et à long terme sur le réseau de l’organisation. Elle laisse souvent très peu d’artefacts et d’indices aux analystes pour identifier et atténuer l’attaque. Cependant, se concentrer sur les bonnes pratiques de sécurisations de l’active directory peut éviter la compromission et de devoir déclencher son plan de gestion de crise, … quand il existe.