En 2023, Crowdstrike relève dans son rapport d'investigation sur les menaces que les attaques par Kerberoasting ont augmentées de 583%. Depuis, de nombreux organismes tentent de sonner le signal d'alarme sur cette attaque, comme Microsoft en octobre 2024 avec un article succinct sur leur blog. C'est à notre tour de vous présenter cette attaque et les impacts qu'elle peut avoir sur votre système d'information.
Dans les environnements modernes basés sur Active Directory, le protocole Kerberos est un pilier de l'authentification réseau. Il garantit des échanges sécurisés entre utilisateurs et services grâce à un système de tickets cryptographiques. Cependant, sa complexité et certaines de ses configurations peuvent être exploitées pour des attaques sophistiquées. Parmi elles, le Kerberoasting est particulièrement redoutable : il exploite les mécanismes internes de Kerberos pour compromettre des comptes de service. Cet article propose de démystifier le protocole Kerberos et d'expliquer les bases de cette attaque pour mieux comprendre ses enjeux et comment tenter de s'en protéger.
Afin d'expliquer de façon simple et claire le fonctionnement du protocole Kerberos, je vais utiliser une métaphore, celle du manège forain.
Pour accéder au manège, il faut d'abord aller acheter un ticket, cela correspond à la demande de TGT dans Kerberos. Après avoir payé on récupère le ticket et va dans la file d'attente. Quand on souhaite accéder au manège, une personne va récupérer notre ticket pour vérifier qu'on a le droit de monter sur le manège. Cela correspond à la demande de TGS. Quand le forain récupère notre ticket, il nous donne l'accès au manège et nous avons donc le droit de faire le tour de manège. Cela correspond au droit d'accéder et d'utiliser le service que nous souhaitons.
L'attaque Kerberoasting repose sur l'exploitation du protocole Kerberos. Elle consiste en un attaquant disposant d'un compte utilisateur valide dans le domaine qui demande un ticket Kerberos. Ce ticket contient des informations chiffrées avec le mot de passe du compte de service ciblé, et il permet d'accéder au service ciblé par l'attaquant. Ce dernier va ensuite chercher à récupérer le mot de passe du compte de service, en hors-ligne, afin de ne pas être détecté.
Il est possible de retrouver le mot de passe dans un cas particulier, celui où le compte de service est un compte utilisateur et non un compte machine. Ce dernier détail est important, car les comptes machine possèdent des mots de passe très complexes (120 caractères générés aléatoirement) alors que les comptes utilisateur sont créés manuellement et le mot de passe défini est beaucoup plus facile à retrouver.
Rentrons un petit plus dans les détails techniques de ce protocole et de cette attaque pour en avoir une meilleure compréhension afin de se protéger de façon efficace par la suite. Je vous promets qu'après deux trois relectures, vous finirez par être des experts 😉
Le protocole Kerberos utilise des tickets pour permettre une authentification sécurisée sans transmettre de mots de passe en clair. Le processus d'authentification Kerberos comprend trois parties principales :
L'authentification commence lorsqu'un utilisateur tente de se connecter à un domaine Active Directory. Le client envoie une requête d'authentification au Service d'Authentification du KDC. Si l'utilisateur est authentifié avec succès (en utilisant par exemple un mot de passe), l'AS renvoie un Ticket Granting Ticket (TGT), qui est chiffré avec la clé secrète de l'utilisateur (généralement dérivée de son mot de passe).
Ce TGT est utilisé pour obtenir des tickets de service (TGS) auprès du Service de Délivrance de Tickets (TGS). Le TGT permet à l'utilisateur de demander un accès à des services spécifiques sans avoir à s'authentifier de nouveau avec son mot de passe.
Une fois en possession du TGT, le client peut envoyer une demande au TGS pour obtenir un Ticket de Service (TGS) pour un service spécifique. Cette demande comprend :
Le TGS contient un ticket d'authentification pour le service cible chiffré avec un dérivé du mot de passe du compte de service et un algorithme de chiffrement, souvent le RC4 pour un compte utilisateur. Ce ticket peut être utilisé par le client pour accéder au service demandé.
Voici un schéma qui récapitule ce que je viens d'expliquer pour que cela soit plus clair.
Passons à l'attaque kerberoasting !
L'attaquant peut lister les SPNs pour identifier des services susceptibles d'être attaqués. Cette étape peut être réalisée avec des outils comme Impacket ou Rubeus.
Exemple de commande pour lister les SPNs avec Impacket :
"python3 examples/GetUserSPNs.py domaine.local/utilisateur:motdepasse -dc-ip 192.168.1.1 -request > hash_spn.txt" Cette commande permet d'obtenir une liste des SPNs associés à un domaine et à un utilisateur, et de tenter une demande de TGT pour chaque SPN.
L'attaquant doit récupérer ensuite un TGT pour demander un TGS grâce au SPN identifié dans l'étape précédente.
Après avoir récupéré un TGT, l'attaquant peut utiliser ce dernier pour demander un TGS valide. Il va ensuite extraire le ticket de la mémoire pour l'utiliser hors-ligne.
Une fois que l'attaquant dispose du TGS et de quelques informations comme le nom de service, il peut utiliser des outils comme John the Ripper ou Hashcat pour tenter de cracker en mode hors-ligne le mot de passe utilisé pour chiffrer le ticket. Et ensuite, il va se connecter au compte de service et avoir tous les accès qui lui sont associés.
Voici une petite liste des outils pouvant être utilisés pour mener à bien cette attaque :
Maintenant que nous avons plus d'éléments, voyons comment nous pouvons détecter le kerberoasting. Partons d'abord sur les stratégies à activer au sein de votre Active Directory.
Ensuite, voici un tableau des événements qui nous intéressent.
ID de l'événement | Description |
---|---|
4103 | Détection de scripts Powershell/Module Logging. |
4104 | Détection de scripts Powershell grâce au Script Block Logging. |
4624 | Ouverture de session pour le compte utilisateur du domaine. |
4634 | Fermeture de session pour le compte utilisateur du domaine. |
4688 | Création de nouveaux processus pour exécuter des outils de cracking ou de collecte de SPNs (ex : Impacket). |
4768 | Enregistrement des demandes de TGT. |
4769 | Enregistrement des demandes de tickets de service (TGS). Une demande anormale pour plusieurs comptes peut signaler une attaque. De plus, le type de chiffrement du ticket (0x17 = RC4-HMAC) et le code d'échec (0x0 = réussite de la demande) sont des points importants. |
4776 | Validation des informations d'identification lors de l'exécution des outils de récupération de tickets Kerberos. |
Les éléments suivants sont nécessaires pour détecter une attaque Kerberoasting :
Pour détecter ces événements liés au Kerberoasting dans l'environnement Active Directory, plusieurs moyens peuvent être mis en place :
⚠️ Cependant, il faut faire attention car ces événements font beaucoup de bruits et peuvent provenir d'actions légitimes. ⚠️
Voici une liste non exhaustive de faux positifs potentiels.
Pour les réduire, le mieux serait de corréler les événements et de détecter un grand nombre sur une durée limitée.
Afin de vous donner plus de visibilité sur cette attaque, nous allons en simuler une.
Pour pouvoir exécuter une attaque Kerberoasting, nous avons besoin de deux machines virtuelles :
Nous utilisons une machine Kali Linux pour l'attaquant car elle possède déjà des outils d'attaque Kerberoasting comme Impacket. Pour le serveur AD, nous avons activé les stratégies citées plus haut.
Utilisation de l'outil GetUserSPNs d'Impacket : impacket-GetUserSPNs domain/user_ad -dc-ip IP_DC -request > hash_spn.txt
Dans ce cas-là, l'outil est utilisé pour obtenir un hash de mot de passe des comptes utilisateur qui possèdent un SPN (Service Principal Name). On ajoute la -request
pour que le script récupère le hash à cracker. Sans cette option, le script va seulement afficher les comptes SPN vulnérables et ne va pas demander le TGS. Dans la capture, vous retrouvez le hash entre les crochets rouges et c'est celui-ci que l'attaquant tentera de cracker avec un outil comme John The Ripper afin de retrouver le mot de passe du compte svc_SQL.
Maintenant, nous allons dans le contrôleur de domaine et nous recherchons les événements qui résultent de l'exécution précédente. On retrouve bien les événements cités plus tôt et qui donnent des indications qui vous permettront de déterminer la légitimité de la demande de TGS.
Même si vous êtes maintenant des experts sur le Kerberoasting, nous avons quand même quelques recommandations pour vous 😉
Un ticket Kerberos généré par le TGS (Ticket Granting Service) pour accéder à un service particulier. Ce ticket est chiffré avec la clé du service cible.
Un ticket délivré par le Service d'Authentification (AS) permettant de demander des TGS sans réauthentification.
Composant central de Kerberos qui authentifie les utilisateurs et délivre les tickets. Il inclut le Service d'Authentification (AS) et le Service de Délivrance de Tickets (TGS).
Nom unique identifiant un service spécifique dans un domaine, utilisé dans les demandes de TGS.
Il s’agit du service sur lequel l’utilisateur s’authentifie. Il délivre un TGT (Ticket Granting Ticket) en cas d’authentification réussie. Ce ticket est en fait une demande d’accès au TGS.
Écrit par Elise CHABENIUK
Restez informé de toutes les actus cyber & AISI.