Kerberoasting et attaques d'identifiants AD : detection et defense

Le Kerberoasting est l'une des techniques les plus courantes que les défenseurs observent contre Active Directory (AD), et pourtant elle reste largement mal comprise par les équipes chargées de l'arrêter. Cet article adopte un point de vue strictement défensif : nous expliquons ce qu'est la technique, comment fonctionne le protocole Kerberos sous-jacent, pourquoi certains comptes deviennent exposés et, surtout, comment les équipes bleues la détectent, la corrigent et se durcissent face à elle. L'objectif est comprendre pour défendre. Vous ne trouverez pas ici d'instructions opérationnelles d'attaque, mais la télémétrie, les contrôles et les listes de vérification dont un ingénieur de détection ou un administrateur AD a besoin pour augmenter le coût de l'attaque et réduire la fenêtre pendant laquelle elle peut réussir.

Ce qu'est le Kerberoasting

Le Kerberoasting est une technique d'accès aux identifiants qui abuse d'une fonctionnalité légitime de Kerberos : tout utilisateur de domaine authentifié peut demander un ticket de service pour un compte de service ayant un Service Principal Name (SPN) enregistré. Une partie de ce ticket est chiffrée avec une clé dérivée du mot de passe du compte de service. Comme la demande elle-même est un comportement normal du protocole, elle génère peu de bruit, et comme le craquage ultérieur du mot de passe se fait hors ligne, le contrôleur de domaine (DC) ne voit jamais les tentatives de devinette. Le risque se concentre donc sur les mots de passe faibles des comptes de service et le chiffrement hérité. Du point de vue du défenseur, la technique se comprend mieux comme un décalage entre une ancienne fonctionnalité de commodité et le matériel moderne de craquage. Elle est classée dans MITRE ATT&CK sous T1558.003, dans la tactique Accès aux identifiants.

Comment fonctionne l'authentification Kerberos

Pour vous défendre contre la technique, il vous faut un modèle mental opérationnel de Kerberos. Lorsqu'un utilisateur se connecte, il reçoit un Ticket-Granting Ticket (TGT) du Key Distribution Center (KDC), qui s'exécute sur le contrôleur de domaine. Quand cet utilisateur veut ensuite accéder à un service — un SQL Server, un pool d'applications web, un partage de fichiers — il présente le TGT et demande un ticket de service (TGS) pour le SPN spécifique. Le KDC renvoie un TGS dont la portion de service est chiffrée avec la clé à long terme du compte propriétaire du SPN. De manière légitime, le client transmet ce ticket au service cible, qui le déchiffre pour valider la demande. L'hypothèse de conception est que seul le service (qui connaît son propre mot de passe) peut lire la portion chiffrée. Cette hypothèse s'effondre lorsque le mot de passe du compte est assez faible pour être récupéré hors ligne, car quiconque obtient le ticket peut tenter d'en dériver la clé. Ce flux vous indique exactement où placer votre télémétrie : au KDC, sur les événements de demande de ticket.

Comment l'attaque fonctionne à haut niveau

À haut niveau, la technique comporte trois étapes conceptuelles qu'un défenseur doit reconnaître. Première, l'énumération : identifier quels comptes ont des SPN enregistrés, puisque seuls ceux-là sont ciblables. Deuxième, la demande de tickets : obtenir des tickets TGS pour ces SPN via des appels de protocole ordinaires et authentifiés qui ressemblent à un accès normal aux services. Troisième, la récupération hors ligne : emporter la portion chiffrée entièrement hors du réseau et tenter de récupérer le mot de passe sur le matériel propre de l'adversaire, sans autre contact avec votre domaine. Le constat crucial pour l'équipe bleue est que seules les deux premières étapes vous sont visibles ; la troisième se produit hors réseau. C'est pourquoi la prévention (mots de passe forts, chiffrement moderne, comptes gérés) compte autant que la détection : une fois qu'un ticket à mot de passe faible a quitté l'environnement, aucune alerte ne peut le rappeler.

Surface d'attaque et exposition

La surface exposée est l'ensemble des comptes portant des SPN. Dans la plupart des environnements, cela inclut des comptes de service pour bases de données (MSSQLSvc), serveurs web, applications métier sur mesure et divers produits d'éditeurs qui exigeaient historiquement un utilisateur de domaine pour s'exécuter. Deux catégories méritent un examen particulier. La première, les comptes de service privilégiés — tout compte porteur de SPN également membre de Domain Admins, Enterprise Admins ou d'autres groupes de haut niveau. Ce sont les expositions de plus grande valeur, car récupérer leur mot de passe procure un privilège immédiat. La seconde, les comptes obsolètes : des comptes de service créés il y a des années avec un mot de passe choisi par un humain et jamais renouvelé. Inventorier cette surface est un projet défensif en soi. Vous devriez pouvoir répondre, à tout moment, combien de comptes à SPN existent, lesquels sont privilégiés, lesquels utilisent le chiffrement hérité et quand chaque mot de passe a changé pour la dernière fois. Si vous ne le pouvez pas, cette lacune est votre première conclusion.

Détection : journaux, Event IDs et télémétrie

La détection se concentre sur les événements de ticket de service Kerberos sur les contrôleurs de domaine. Le signal clé est l'Event ID 4769 ("Un ticket de service Kerberos a été demandé"). À lui seul, cet événement est d'un volume extrêmement élevé et bénin, donc une alerte naïve est inutile ; l'art réside dans l'enrichissement. Priorisez les événements 4769 où le Ticket Encryption Type est 0x17 (RC4-HMAC) plutôt que 0x12 (AES256), car une rétrogradation vers RC4 sur un compte censé prendre en charge AES est un fort indicateur. Corrélez sur le volume et la diversité : un seul principal demandant des tickets de service pour un nombre inhabituellement grand de SPN distincts en peu de temps est bien plus suspect que le simple décompte d'événements. Surveillez l'Event ID 4768 (TGT demandé) pour le contexte d'authentification initial et associez le 4769 au compte demandeur, à l'hôte source et à une base horaire. Les plateformes modernes d'EDR et de détection des menaces d'identité (par exemple Microsoft Defender for Identity) livrent des analyses dédiées au Kerberoasting ; si vous en exploitez une, réglez et validez ses alertes. Enfin, envisagez un compte de service leurre (honeypot) : un SPN factice au mot de passe long et aléatoire sans usage légitime, câblé pour que toute demande 4769 le concernant déclenche une alerte de haute fidélité.

Atténuation et durcissement

C'est dans la prévention que l'on gagne. Le contrôle le plus efficace est d'éliminer les mots de passe de comptes de service choisis par des humains : migrez vers des Group Managed Service Accounts (gMSA) ou des Managed Service Accounts déléguées, dont les mots de passe sont des valeurs aléatoires de plus de 120 caractères, renouvelées automatiquement par AD et connues d'aucun humain. Un mot de passe gMSA est calculatoirement irrécupérable hors ligne, ce qui retire entièrement le compte du risque. Là où un gMSA n'est pas encore possible, imposez des mots de passe longs et aléatoires (25+ caractères) sur chaque compte à SPN, car la longueur est le levier direct contre le craquage hors ligne. Désactivez RC4 et exigez le chiffrement AES pour Kerberos, tant au niveau de la stratégie de domaine que dans les attributs de chaque compte (msDS-SupportedEncryptionTypes), en testant d'abord les dépendances héritées. Appliquez le cloisonnement par niveaux (tiering) : aucun compte de service ne devrait être à la fois porteur de SPN et membre d'un groupe très privilégié — séparez les rôles. Imposez un calendrier de rotation pour les comptes manuels restants et retirez les SPN des comptes qui n'en ont plus besoin.

Attaques d'identifiants AD apparentées

Le Kerberoasting est rarement isolé ; il appartient à une famille de techniques d'identifiants AD qu'un défenseur doit traiter ensemble. L'AS-REP Roasting (T1558.004) cible les comptes dont la préauthentification Kerberos est désactivée, produisant du matériel craquable sans même nécessiter un compte de domaine valide — auditez le drapeau DONT_REQ_PREAUTH et retirez-le partout où il n'est pas strictement requis. Les techniques Pass-the-Ticket et Pass-the-Hash réutilisent des authentifiants volés plutôt que de les craquer, d'où l'importance des contrôles d'hygiène des identifiants comme Credential Guard, la protection de LSASS et la restriction des lieux de connexion des comptes privilégiés. Les falsifications de Golden et Silver Ticket abusent respectivement des clés de KRBTGT et de comptes de service, une raison de plus de renouveler KRBTGT régulièrement et de protéger les secrets des comptes de service. Les voir comme une surface connectée, et non comme des alertes isolées, aide à prioriser les contrôles — secrets forts, chiffrement moderne, tiering et gestion des accès privilégiés — qui en réduisent plusieurs à la fois.

Pièges courants

Plusieurs erreurs récurrentes minent des programmes par ailleurs solides. La première est d'alerter sur le volume brut de 4769 : sans enrichissement par type de chiffrement et diversité, le bruit enterre le signal et la règle est désactivée en une semaine. La deuxième est de supposer qu'AES est imposé alors qu'une seule application héritée force silencieusement RC4 pour tout le compte — vérifiez toujours le type de chiffrement négocié dans des événements réels, pas seulement dans la stratégie. La troisième est le compte de service privilégié laissé en place parce que "l'appli en a besoin" — c'est précisément l'exposition qui transforme une conclusion de faible gravité en chemin vers la compromission du domaine. La quatrième est de considérer une migration gMSA comme terminée alors qu'une poignée de services hérités tenaces tournent encore sous des comptes manuels ; c'est là que le risque se concentre. La cinquième est de désactiver la préauthentification pour dépanner et d'oublier de la réactiver, ouvrant silencieusement l'AS-REP Roasting. Suivez chacun comme une tâche d'hygiène permanente.

Liste de vérification du défenseur

Utilisez cette liste comme revue récurrente. Inventaire : tenez une liste vivante de tous les comptes à SPN, en signalant les privilégiés et ceux à chiffrement hérité. Chiffrement : exigez AES et désactivez RC4 là où les dépendances le permettent, vérifié sur des événements 4769 réels. Comptes gérés : migrez les comptes de service vers gMSA/dMSA ; fixez une date cible pour retirer les manuels restants. Mots de passe : pour tout compte manuel, imposez des secrets aléatoires de 25+ caractères et un calendrier de rotation. Tiering : assurez-vous qu'aucun compte à SPN n'appartient à un groupe de haut niveau. Détection : déployez des analyses enrichies de 4769 (type de chiffrement + diversité de SPN + base) et validez leur déclenchement dans un test contrôlé. Honeypot : mettez en place un compte SPN leurre avec alerte de haute fidélité. Drapeaux adjacents : auditez et retirez le DONT_REQ_PREAUTH inutile et confirmez que la rotation de KRBTGT est planifiée. Réponse : documentez le playbook d'une détection confirmée — renouveler le secret affecté, chasser l'usage ultérieur et revoir l'exposition des accès privilégiés.

Foire aux questions

Le Kerberoasting peut-il être totalement prévenu ou seulement détecté ? Il peut être efficacement prévenu en tant que menace pratique. Migrer les comptes à SPN vers gMSA/dMSA, ou imposer des mots de passe aléatoires très longs avec chiffrement AES uniquement, rend la récupération hors ligne calculatoirement irréalisable. La détection reste précieuse comme défense en profondeur et pour attraper les exceptions mal configurées, mais ce sont les secrets forts qui suppriment le risque à la source.

Pourquoi l'Event ID 4769 est-il si bruyant, et comment le rendre utile ? Chaque accès normal à un service génère un 4769, donc les décomptes bruts ne signifient rien. Il devient utile par l'enrichissement : filtrez les demandes RC4 (0x17) sur les comptes compatibles AES, corrélez un demandeur unique touchant rapidement de nombreux SPN distincts, établissez une base par compte et réservez les alertes de haute fidélité aux SPN leurres qu'aucun processus légitime ne devrait jamais demander.

Conclusion

Le Kerberoasting persiste non parce qu'il est sophistiqué, mais parce que tant d'environnements traînent encore des mots de passe faibles de comptes de service et du chiffrement RC4 hérité. Pour les défenseurs, la voie est claire et durable : inventoriez vos comptes à SPN, déplacez-les vers des comptes gérés, imposez AES, séparez le privilège de l'identité de service et bâtissez une détection enrichie sur les événements de ticket Kerberos avec un honeypot comme fil-piège. Traitez-le avec ses cousins — AS-REP Roasting, falsification de tickets et réutilisation d'identifiants — comme une seule surface connectée de sécurité des identités. Faites cela et vous transformerez un favori fiable des attaquants en une technique bruyante lorsqu'on la tente et sans valeur lorsqu'elle réussit. Comprenez-la, et vous pourrez vous en défendre.