Technique d'attaque Active Directory
Le Kerberoasting exploite une propriété parfaitement normale de Kerberos : un utilisateur déjà authentifié peut demander un ticket de service pour un service identifié par un SPN (Service Principal Name). Rien d'anormal jusque-là : c'est le fonctionnement attendu de l'authentification dans un domaine Active Directory.
Le problème apparaît lorsque le compte qui porte ce service repose sur un secret insuffisamment robuste ou mal gouverné. L'attaquant peut alors récupérer un élément lié au ticket et tenter de retrouver ce secret hors ligne, sans bruit et sans limite de tentatives côté annuaire.
La mécanique se résume en quelques étapes. Elle n'a rien d'exotique : elle emprunte uniquement des opérations légitimes de l'annuaire, ce qui explique sa discrétion.
Dans la plupart des environnements, ce ne sont pas les mécanismes Kerberos qui posent problème, mais l'état réel des comptes de service. Ils cumulent souvent plusieurs défauts hérités de l'histoire du système d'information.
Pris isolément, le Kerberoasting ne compromet pas Active Directory. Il devient dangereux lorsqu'il s'insère dans un enchaînement qui rapproche l'attaquant d'une ressource critique.
À technique identique, la suite dépend entièrement de ce que le compte compromis permet réellement de faire dans votre environnement :
Le risque réel d'un compte kerberoastable ne se mesure donc pas à l'existence d'un SPN, mais à ce que sa compromission permettrait d'atteindre ensuite. C'est exactement la logique de lecture par chemins d'attaque du cas d'usage parent.
Deux sujets distincts sont souvent confondus : mesurer l'exposition (un travail d'inventaire et d'analyse) et détecter une activité suspecte (un travail de supervision). Les deux sont nécessaires, mais ils ne se traitent pas avec les mêmes moyens.
L'objectif est de savoir quels comptes sont réellement attaquables et ce qu'ils permettraient d'obtenir.
La supervision s'appuie notamment sur les événements Kerberos liés aux demandes de tickets de service, dont l'Event ID Windows 4769 lorsqu'il est disponible et correctement collecté. Une demande de ticket de service est une activité Kerberos parfaitement normale : il n'existe pas d'équivalence entre un événement 4769 et une attaque. La détection doit donc chercher des écarts de comportement et des combinaisons de signaux.
Même prudence concernant RC4 : son usage n'est pas une preuve de Kerberoasting. Ce peut être un signal intéressant dans certains environnements, mais il doit être interprété avec la connaissance des applications héritées encore en production.
Les mesures utiles sont rarement spectaculaires. Elles consistent d'abord à reprendre la main sur les comptes de service, puis à réduire ce qu'une compromission permettrait de faire.
01
02
03
04
05
Un diagnostic pertinent ne se limite pas à produire la liste des comptes portant un SPN. Cette liste est facile à obtenir et n'indique pas où agir en priorité.
Les contenus Ariovis qui prolongent directement ce sujet.
La page mère : risques, diagnostic, priorisation et remédiation côté annuaire.
L'offre d'audit AD : délégations, comptes privilégiés, chemins d'attaque, durcissement.
Coffre-fort, rotation des secrets et encadrement des comptes techniques.
Vérifier par la pratique quels chemins d'attaque sont réellement exploitables.
Propriétaires, revues et cycle de vie, y compris pour les identités techniques.
La trajectoire de mise sous contrôle, du constat aux premières remédiations.
Pourquoi les privilèges permanents alimentent la plupart des chemins d'attaque.
Ce qu'un compte compromis peut atteindre, et comment limiter le rayon d'impact.
Ariovis analyse vos comptes de service, leurs secrets, leurs privilèges et leur position dans les chemins d'attaque de votre annuaire, puis vous remet un plan de remédiation priorisé.
