Kerberoasting : comprendre et prévenir l’attaque
Comprenez le Kerberoasting, ses risques pour les comptes de service et les moyens de le détecter. Découvrez les mesures pour protéger votre domaine Windows.
Kerberoasting : comment protéger les comptes de service d'un domaine Windows ?
Un attaquant avec un simple compte utilisateur sur un domaine Windows peut demander des tickets Kerberos pour des services. Le contrôleur de domaine répond à une requête prévue par le protocole. Rien, sur le papier, n'a forcément l'air « malveillant ». Pourtant, ces tickets peuvent ensuite servir à tester hors ligne des mots de passe de comptes de service.
C'est exactement le principe du Kerberoasting. L'attaque ne « casse » pas Kerberos et elle ne donne pas automatiquement le contrôle d'un domaine. Elle joue plutôt sur un point très concret : si les mots de passe des comptes de service sont faibles, anciens ou réutilisés entre plusieurs services, des mécanismes d'authentification conçus pour être solides peuvent quand même être exploités. Et si le compte compromis a trop de privilèges, les dégâts peuvent vite devenir sérieux.
Pour évaluer le risque, il faut donc regarder trois choses : ce qu'il y a dans un ticket, ce que l'attaquant peut réellement en faire, et ce que les journaux permettent de repérer. Dans cet article, on détaille le mécanisme, les conditions qui rendent l'attaque efficace, les signaux à surveiller et les mesures qui réduisent durablement l'exposition.
Kerberoasting : le mécanisme, étape par étape
Les éléments Kerberos à connaître
Kerberos est un protocole d'authentification utilisé notamment dans les domaines Windows. Il permet à un utilisateur d'accéder à des services sans devoir redonner son mot de passe à chaque fois. Dans un environnement Windows, le centre de distribution de clés (KDC) est assuré par le contrôleur de domaine. Il émet des tickets cryptographiques qui prouvent qu'une identité a été authentifiée.
Après l'authentification, l'utilisateur obtient un ticket d'octroi de tickets (TGT). Avec ce TGT, il peut demander au KDC des tickets pour des services précis. Chaque service est identifié par un nom principal de service (SPN). Concrètement, un SPN relie une instance de service à un compte, par exemple pour un serveur Web ou une base de données.
Les services tournent souvent avec des comptes de service : des comptes dédiés à une application ou à un composant. Un compte peut, par exemple, exécuter un serveur SQL ou une application de reporting. Le mot de passe de ce compte sert notamment à produire les clés utilisées par Kerberos.
Ce qui se passe lors d'une demande de ticket
Quand un utilisateur veut accéder à un service, son ordinateur envoie son TGT au KDC et demande un ticket lié au SPN de ce service. Le contrôleur de domaine retrouve le compte associé et émet un ticket de service. Une partie du ticket est chiffrée avec une clé dérivée du secret du compte de service.
Le client reçoit le ticket, mais il n'a pas la clé nécessaire pour déchiffrer la partie réservée au service. C'est le service destinataire, qui connaît le secret correspondant, qui doit pouvoir traiter le ticket. Dans un scénario normal, le client transmet ensuite le ticket au service, lequel vérifie qu'il est valable.
Le point clé, c'est que la demande et l'émission du ticket font partie du fonctionnement normal. Kerberos ne peut pas « deviner » que chaque demande de ticket est une intention hostile : beaucoup d'applications et d'utilisateurs font ça tous les jours. L'attaque, elle, arrive quand quelqu'un récupère le ticket et exploite sa partie chiffrée pour tester des mots de passe hors du domaine.
Pourquoi les essais peuvent avoir lieu hors ligne
Un attaquant qui a déjà un compte valide sur le domaine peut repérer les comptes associés à des SPN, puis demander les tickets correspondants. Sur le plan du protocole, la requête peut être parfaitement acceptable, même si le comportement ne colle pas vraiment à ce qu'on attend de cet utilisateur.
Il peut ensuite conserver les données chiffrées et lancer des essais hors ligne. Pour chaque hypothèse de mot de passe, un outil calcule la clé attendue et vérifie si elle correspond au ticket. Si le mot de passe est faible ou facile à deviner, il peut être retrouvé sans avoir besoin d'envoyer une suite de tentatives au contrôleur de domaine.
C'est aussi pour ça que les politiques de verrouillage de compte ne suffisent pas. Elles limitent surtout les essais en ligne, où chaque échec est comptabilisé. Elles ne protègent pas contre ce qui se passe ensuite sur une copie des données, en dehors du réseau d'authentification.
Il ne s'agit pas de « déchiffrer Kerberos au hasard ». Le risque, c'est une attaque par devinettes sur un secret faible, rendue possible par les informations fournies dans le ticket. Un mot de passe aléatoire et suffisamment long rend ces essais irréalistes. À l'inverse, un mot de passe humain, court ou réutilisé devient beaucoup plus exposé.
Le rôle des algorithmes de chiffrement
Les tickets peuvent utiliser différents types de chiffrement. Dans certains environnements plus anciens (ou mal configurés), RC4 peut encore être accepté. Dans des configurations plus récentes, on privilégie généralement AES. Le coût de calcul des mécanismes de dérivation de clés influe sur la vitesse des essais hors ligne.
Mais attention : ce n'est pas « AES = sécurité magique » contre un mot de passe faible. Un chiffrement plus moderne peut ralentir chaque tentative, sans rendre un secret facile à deviner intraitable. Au final, la vraie priorité reste : un bon mot de passe (long et imprévisible), des privilèges réduits, et la suppression des configurations héritées quand elles ne sont plus nécessaires.
Quels risques pour l'organisation et comment détecter l'attaque ?
Récupérer le mot de passe n'est pas la fin de l'histoire
Imaginons un compte de service lié à une application de reporting, avec un mot de passe ancien et prévisible. Un attaquant commence par demander un ticket pour ce service, puis retrouve le mot de passe hors ligne. Ensuite, il peut tenter de s'authentifier en tant que compte de service.
Ce que ça permet dépend surtout des droits de ce compte. Si le compte ne peut accéder qu'à des ressources limitées, l'impact peut rester contenu. S'il appartient à des groupes puissants, dispose de privilèges administrateur sur plusieurs serveurs, ou s'il est réutilisé par plusieurs applications, le même incident peut ouvrir plusieurs chemins d'escalade.
Dans la vraie vie, les privilèges s'accumulent. Un accès donné pour une intervention « temporaire » peut être conservé. Un groupe peut rester en place après une migration. Un compte peut aussi finir par servir à plusieurs services. Le Kerberoasting ne garantit pas une élévation de privilèges, mais il peut transformer une compromission initiale plutôt limitée en accès beaucoup plus intéressant.
Au fond, c'est une règle simple : les mots de passe et les privilèges répondent à deux risques différents. Un secret solide réduit la probabilité de « récupération ». Un moindre privilège limite l'impact si malgré tout le secret est retrouvé.
Les événements à examiner
Sur Windows, l'événement de sécurité 4769 correspond à une demande de ticket de service Kerberos. Il donne des informations utiles : le compte demandeur, le service visé et le type de chiffrement utilisé. Une rafale de demandes vers plusieurs SPN, dans un laps de temps court, mérite au moins d'être investiguée.
Il faut aussi regarder d'autres incohérences : un compte qui demande soudain des tickets pour des services qui n'ont rien à voir avec son activité habituelle, une machine qui génère un volume inhabituel de requêtes, ou encore un type de chiffrement qui ne correspond pas à ce qu'on attend dans la configuration. Par exemple, l'utilisation de RC4 là où l'environnement devrait plutôt être en AES doit être expliquée.
Mais aucun signal, pris isolément, ne prouve qu'il y a une attaque. Les applications génèrent naturellement des demandes de tickets, et les équipes informatiques exécutent aussi des scripts d'administration et des opérations de maintenance. Une alerte basée uniquement sur le volume risque de produire trop de faux positifs pour être exploitable.
Pour bien détecter, il faut un référentiel de comportement normal : quelles machines et quels comptes demandent quels tickets, à quelles périodes, et dans quel contexte ? Le plus efficace, c'est de croiser les journaux Kerberos avec les événements sur les postes (changements de droits, alertes sécurité déjà identifiées, etc.). Un enchaînement d'accès atypiques juste après une campagne d'hameçonnage est plus parlant qu'un cas isolé.
Une méthode d'investigation pragmatique
En cas d'anomalie, l'idée est de trier vite entre activité légitime et comportement suspect. Un ordre de travail simple :
- Identifier le compte demandeur et le poste source. Vérifiez si ça correspond aux habitudes de l'utilisateur ou à une tâche planifiée connue.
- Examiner les services demandés. Plusieurs SPN sans lien avec le rôle de la personne peuvent indiquer une exploration.
- Comparer le type de chiffrement attendu au type observé. Une exception ou une config héritée peut expliquer la différence, mais elle doit être documentée.
- Vérifier les événements « voisins ». Cherchez d'autres signes : connexion inhabituelle, modification de groupe, activité suspecte sur le poste.
- Évaluer l'exposition des comptes concernés. Tout dépend des privilèges, des ressources accessibles et de la réutilisation éventuelle du compte.
Cette approche évite deux erreurs classiques : traiter toute demande de ticket comme une attaque, ou au contraire supposer qu'une requête « techniquement correcte » ne peut pas être malveillante. Pour aller plus loin sur la surveillance des identités, consultez aussi notre guide sur la journalisation de sécurité dans un domaine Windows et notre dossier consacré à la protection des comptes à privilèges.
Comment réduire le risque à la source
Remplacer les mots de passe humains par des secrets robustes
La mesure la plus directe, c'est d'utiliser, pour chaque compte de service, un mot de passe long, aléatoire et unique. Il ne doit pas être mémorisé par une personne. Il doit être généré, stocké et utilisé par les systèmes de manière maîtrisée.
Un mot de passe basé sur le nom du service, une année, ou une « règle » de complexité minimale peut rester prévisible. Ajouter une majuscule et un chiffre à un mot de passe courant ne compense pas un manque de longueur ni des habitudes évidentes. À l'inverse, un secret aléatoire suffisamment long ne sera pas testé efficacement par dictionnaire en un temps raisonnable.
Pensez aussi à éviter la réutilisation du même secret sur plusieurs applications. Sinon, la compromission d'un compte peut se diffuser, même si chaque service ne demande que des droits limités. Les rotations doivent être préparées : changer un mot de passe sans savoir à quels services il est lié peut casser des dépendances. Un inventaire fiable n'est donc pas « du papier en plus » : c'est ce qui évite les interruptions.
Utiliser des comptes de service gérés lorsque c'est possible
Quand c'est compatible avec votre environnement Windows, les comptes de service gérés de groupe (gMSA) permettent au domaine de gérer automatiquement un mot de passe robuste et sa rotation. Le secret n'est pas choisi par un humain avec une logique « facile à retenir ».
Les gMSA réduisent nettement le risque lié aux mots de passe faibles et aux renouvellements manuels. Mais ils ne remplacent pas la gestion des droits : un gMSA trop privilégié reste un compte à protéger. Il faut aussi vérifier la compatibilité des applications, les serveurs autorisés à utiliser le compte et le plan de migration avant de généraliser.
Dans un parc hétérogène, certains services anciens ne peuvent pas être convertis immédiatement. Dans ce cas, traitez ces exceptions comme une vraie migration planifiée (responsable identifié, droits revus, secret robuste, calendrier), pas comme une dérogation « pour toujours ».
Appliquer le moindre privilège et mettre l'inventaire à jour
Un compte de service doit avoir uniquement les droits nécessaires à son fonctionnement. Il ne devrait pas être administrateur du domaine, ni administrateur local sur trop de serveurs « par commodité ». Séparer par service ou par périmètre demande plus d'effort au départ, mais ça limite l'impact d'une compromission.
Il faut aussi savoir quels SPN sont encore utilisés, par quelle application, et sous la responsabilité de quelle équipe. Les comptes orphelins (liés à des services arrêtés ou à des systèmes remplacés) méritent une attention particulière. On les oublie lors des rotations et des revues, même s'ils restent visibles dans l'annuaire.
Un audit utile ne se contente pas d'exporter une liste. Pour chaque compte, documentez au minimum : le propriétaire, le service associé, les machines concernées, les droits accordés, la façon dont le secret est géré, et la date de la dernière revue. S'il n'y a personne capable d'expliquer à quoi sert un compte, commencez par confirmer son usage avant de le désactiver.
Durcir Kerberos sans casser les services
Quand c'est possible, privilégiez les types de chiffrement modernes, notamment AES. Garder RC4 peut parfois être nécessaire pour des équipements ou logiciels hérités, mais ça doit correspondre à un besoin identifié et à un plan de retrait. Tout changement « brutal » peut interrompre des applications : testez les dépendances et prévoyez un retour arrière.
La surveillance complète le durcissement. Établissez d'abord une référence de l'activité habituelle, puis déclenchez des alertes sur des écarts contextualisés : demandes nombreuses et inhabituelles, source inattendue, service atypique, ou combinaison avec d'autres indicateurs. Et surtout : regardez le bruit produit. Un dispositif que les équipes finissent par ignorer ne protège pas vraiment.
Désactiver Kerberos, ou bloquer globalement les demandes de tickets, n'est généralement pas réaliste. Le protocole est central pour l'authentification dans de nombreux environnements Windows ; une mesure indiscriminée risque de casser des services sans régler la faiblesse de fond. Pour structurer vos contrôles, vous pouvez aussi compléter ce guide par notre check-list de sécurisation d'Active Directory.
Conclusion : renforcer les comptes plutôt que bloquer Kerberos
Le Kerberoasting repose sur un mécanisme assez simple : une requête Kerberos « normale » fournit des données chiffrées qui peuvent servir à tester hors ligne le mot de passe d'un compte de service. Si ce secret est faible, ancien ou réutilisé, le risque augmente. Et si le compte a des privilèges trop élevés, l'impact potentiel suit.
La réponse n'est pas de désactiver Kerberos. L'objectif est de réduire les causes concrètes : adopter des secrets longs et aléatoires, passer aux gMSA quand c'est possible, limiter les privilèges, supprimer les comptes et les SPN inutilisés, puis surveiller les demandes de tickets avec un contexte (pas juste des volumes).
Commencez par inventorier les comptes associés à des SPN et identifiez ceux qui cumulent un secret géré manuellement, des droits étendus ou un propriétaire inconnu. C'est une première étape ciblée, vérifiable, et généralement plus utile qu'une politique générale difficile à appliquer sans casser quoi que ce soit.