BloodHound et cartographie des chemins d'attaque AD : guide equipe bleue

BloodHound est l'un des outils les plus influents dans le monde de la sécurité Active Directory (AD), et le comprendre est désormais une compétence essentielle pour toute équipe bleue. Il n'exploite rien par lui-même ; c'est un moteur de graphes qui ingère les relations entre utilisateurs, groupes, ordinateurs et permissions, puis révèle les chemins d'attaque les plus courts qu'un intrus pourrait emprunter depuis un point d'ancrage peu privilégié jusqu'à Administrateur du domaine. Les défenseurs étudient BloodHound pour la même raison qu'un serrurier étudie les crochets : voir le bâtiment comme le voit un adversaire et fermer les routes avant que quelqu'un d'autre ne les trouve. Cet article adopte une posture strictement défensive, celle de comprendre pour défendre. Nous expliquons ce qu'est la cartographie des chemins d'attaque, comment le graphe est construit, quelles télémétries et ID d'événements exposent la collecte et l'abus, et comment durcir votre annuaire pour que les arêtes dangereuses disparaissent tout simplement. Il n'y a ici aucune instruction opérationnelle d'attaque, seulement l'ingénierie de détection et le durcissement dont un défenseur a besoin.

Ce qu'est BloodHound et pourquoi les défenseurs l'étudient

Au fond, BloodHound est une plateforme de visualisation et d'analyse de données bâtie sur une base de données de graphes. Les nœuds représentent des objets AD — utilisateurs, groupes, ordinateurs, unités d'organisation, objets de stratégie de groupe, domaines — et les arêtes représentent des relations telles que MemberOf, AdminTo, HasSession, GenericAll, WriteDacl et CanRDP. Un collecteur (historiquement SharpHound, et dans les déploiements modernes les éditions community et enterprise) lit ces informations dans l'annuaire à l'aide de requêtes LDAP et RPC ordinaires et authentifiées, puis les injecte dans le graphe. Une fois les données chargées, un analyste peut poser une seule question qui prendrait des jours à la main : quel est le chemin le plus court de ce compte ordinaire vers un compte très privilégié ?

Pour les défenseurs, la valeur est énorme. Les environnements AD modernes accumulent les permissions comme des sédiments : un groupe de support reçoit des droits sur un serveur pour une tâche ponctuelle, un compte de service est surprovisionné pour faire fonctionner un installeur, un ancien admin se retrouve imbriqué à trois groupes de profondeur. Individuellement, chaque octroi paraît inoffensif. Ensemble, ils forment une toile qu'aucun humain ne peut garder en tête. BloodHound transforme cette toile invisible en image, et cette image est exactement ce qu'une équipe violette ou bleue utilise pour prioriser la remédiation. Étudier l'outil, ce n'est pas apprendre à attaquer, c'est apprendre à voir le même graphe que l'attaquant et à le briser en premier.

Comment fonctionne la cartographie des chemins d'attaque à haut niveau

La cartographie des chemins d'attaque traite l'annuaire comme un graphe orienté et applique la recherche de chemins. L'idée centrale est que l'élévation de privilèges dans AD est rarement une vulnérabilité unique ; c'est une chaîne de permissions légitimes, chacune autorisée séparément. Un utilisateur peut appartenir à un groupe, ce groupe peut avoir l'admin local sur un poste, un administrateur peut y avoir une session active, et cet administrateur peut à son tour avoir des droits sur un objet plus sensible. Aucune de ces étapes n'est un bug — toutes fonctionnent comme configurées. Le danger est la composition transitive de la chaîne.

BloodHound encode chacune de ces relations comme une arête typée, puis exécute des requêtes de plus court chemin (classiquement des parcours de type Dijkstra) entre un nœud de départ et des cibles de grande valeur comme le groupe Admins du domaine ou l'objet domaine lui-même. La sortie est un ensemble ordonné de routes. Du point de vue défensif, chaque arête d'un chemin retourné est un point de contrôle : supprimer ou rétrograder une seule arête coupe tout le chemin. C'est pourquoi l'outil est si puissant pour le durcissement — il ne vous dit pas seulement qu'un risque existe, il vous indique la permission exacte dont la suppression élimine le plus grand nombre de chemins d'un coup.

La surface de collecte : ce qui est lu

Pour bâtir le graphe, un collecteur interroge l'annuaire à peu près comme le pourrait tout utilisateur de domaine authentifié. Il énumère les appartenances aux groupes, les listes de contrôle d'accès (ACL/DACL) sur les objets, les relations d'approbation, les liens de stratégie de groupe et — élément important — les informations de session : quels utilisateurs sont ou ont été récemment connectés à quelles machines. Les données de session proviennent généralement de l'énumération à distance des utilisateurs connectés et des API de session réseau. Comprendre cette surface importe car elle indique au défenseur exactement où le bruit apparaîtra dans sa télémétrie : une rafale de requêtes LDAP contre l'annuaire, suivie de connexions RPC/SMB s'éventaillant vers de nombreux hôtes pour recueillir des données de session et de groupes locaux.

L'enseignement défensif clé est que la collecte ressemble à de la reconnaissance à grande échelle. Une seule machine qui interroge soudain tout l'annuaire par LDAP puis touche les API de session de centaines d'autres machines dans une courte fenêtre est la signature à surveiller. Les outils d'administration légitimes font des choses similaires, si bien que le contexte — le compte source, l'hôte, l'heure et l'ampleur de l'éventail — est ce qui distingue un balayage d'une opération de routine.

Chemins d'attaque courants que le graphe révèle

Plusieurs catégories d'arêtes dangereuses reviennent sans cesse dans les environnements réels. Les arêtes d'abus d'ACL (GenericAll, GenericWrite, WriteDacl, WriteOwner, AddMember) signifient qu'un objet peut réécrire la sécurité d'un autre — par exemple, un groupe de bas niveau qui peut s'ajouter lui-même à un groupe privilégié. Les arêtes d'exposition d'identifiants (HasSession) signifient qu'un compte privilégié a laissé des identifiants en mémoire sur une machine que des utilisateurs de niveau inférieur peuvent atteindre. Les arêtes de délégation (délégation Kerberos non contrainte et contrainte) permettent à un hôte d'usurper d'autres utilisateurs. Les marqueurs kerberoastable et AS-REP roastable signalent des comptes de service dont les tickets peuvent être demandés et cassés hors ligne si le mot de passe est faible.

Reconnaître ces classes est tout l'enjeu pour un défenseur : chacune correspond à une remédiation concrète. Les arêtes d'ACL se corrigent en resserrant les permissions déléguées ; les arêtes de session, par une administration en niveaux pour que les identifiants de Niveau 0 n'atterrissent jamais sur des hôtes de Niveau 1 ou 2 ; les arêtes de délégation, en supprimant la délégation non contrainte et en marquant les comptes sensibles comme non délégables ; les comptes roastables, avec des mots de passe longs, aléatoires et gérés (gMSA) et en ne mettant pas de noms de principal de service sur des comptes utilisateur ordinaires.

Détection : journaux, ID d'événements et télémétrie EDR

La collecte génère des signaux observables. Côté annuaire, activer et surveiller l'audit d'accès au service d'annuaire permet de voir un volume anormal de lectures LDAP ; cherchez une source unique énumérant une très grande fraction des objets. L'ID d'événement 4662 de sécurité Windows (une opération a été effectuée sur un objet) est central pour repérer les lectures massives de l'annuaire et, notamment, les requêtes de réplication de type DCSync lorsque vous filtrez sur les droits d'accès de réplication. L'ID d'événement 4661 (un handle vers un objet a été demandé) et le 5136 (un objet d'annuaire a été modifié) aident à attraper les changements d'ACL qui créent de nouvelles arêtes privilégiées.

Pour l'énumération des sessions et des groupes locaux, surveillez l'ID d'événement 4624 (ouverture de session) et le 4672 (privilèges spéciaux attribués) sur les hôtes membres, ainsi que l'accès aux canaux nommés SMB/RPC vers srvsvc et wkssvc. Une machine qui se connecte aux interfaces de session de centaines d'hôtes en quelques minutes est anormale. Les plateformes EDR ajoutent la filiation des processus — en signalant un binaire inhabituel qui effectue de larges appels LDAP et SMB — et les capteurs réseau ajoutent la forme de l'éventail. Déployer des objets honeytoken (un compte leurre d'apparence privilégiée ou une fausse ACL) est l'une des détections au signal le plus fort et au bruit le plus faible : aucun processus légitime ne devrait jamais les toucher, donc toute requête contre un honeytoken est une alerte immédiate à haute fidélité. Microsoft Defender for Identity et les capteurs de menaces d'identité similaires se spécialisent exactement dans cette télémétrie de reconnaissance et de mouvement latéral.

La corrélation est ce qui rend ces signaux exploitables. Un seul 4662 n'a aucun sens ; une source unique produisant des milliers de 4662 à travers l'annuaire, suivie de 4624 se propageant vers de nombreux hôtes, suivie d'un pic de demandes de tickets de service Kerberos (ID d'événement 4769 avec des types de chiffrement faibles), forme une histoire cohérente. Construire cette corrélation dans votre SIEM sous forme de règle multi-étapes transforme un bruit épars en une alerte claire.

Atténuation et durcissement

La solution stratégique aux chemins d'attaque est l'administration en niveaux. Divisez identités et actifs en niveaux — Niveau 0 (contrôleurs de domaine, le plan d'identité et tout ce qui le contrôle), Niveau 1 (serveurs et applications) et Niveau 2 (postes de travail) — et imposez que les identifiants d'un niveau supérieur ne s'authentifient jamais sur un niveau inférieur. Ce seul principe fait s'effondrer la grande majorité des chemins HasSession, car un identifiant d'Administrateur du domaine n'atterrit jamais sur un poste où un utilisateur peu privilégié pourrait le récolter. Associez cela à des postes de travail à accès privilégié (PAW) pour les administrateurs et à des comptes d'administration distincts utilisés uniquement pour leur niveau.

Côté permissions, auditez et élaguez les arêtes d'ACL que le graphe révèle. Supprimez les octrois GenericAll/WriteDacl ajoutés de façon improvisée ; remplacez la délégation large par des délégations restreintes et documentées. Éliminez entièrement la délégation non contrainte lorsque c'est possible et utilisez à la place la délégation contrainte basée sur les ressources. Marquez les comptes de grande valeur comme sensibles et non délégables, et ajoutez-les au groupe Utilisateurs protégés pour que le système d'exploitation traite leurs identifiants de façon plus défensive. Remplacez les comptes de service autonomes par des comptes de service administrés de groupe (gMSA) afin que les mots de passe soient longs, aléatoires et pivotés automatiquement, ce qui supprime le risque de kerberoasting. Imposez LAPS pour que les mots de passe d'administrateur local soient uniques par machine, brisant les chaînes latérales de pass-the-hash.

Enfin, utilisez l'analyse de type BloodHound en tant que défenseur : exécutez le graphe sur votre propre environnement de façon planifiée, suivez comme métrique le nombre de principaux ayant un chemin vers le Niveau 0 et faites-le baisser version après version. Traitez toute réduction des chemins vers l'Administrateur du domaine comme un gain de sécurité mesurable. Cela transforme l'outil, de carte de l'attaquant en KPI du défenseur.

Pièges et erreurs courantes

L'erreur la plus courante est de courir après des découvertes individuelles au lieu de points d'étranglement à fort impact. Comme les chemins se chevauchent, un groupe surprivilégié se trouve souvent sur des milliers de routes ; le corriger vaut plus que corriger cent problèmes de feuille. Un deuxième piège est d'ignorer les arêtes de session parce qu'elles semblent éphémères — mais l'habitude d'un admin de se connecter aux postes pour dépanner recrée la même arête dangereuse chaque jour. Un troisième est de traiter les comptes de service comme inoffensifs ; un compte de service surprivilégié avec un mot de passe faible et jamais pivoté est l'une des routes d'escalade les plus fiables.

Côté détection, une erreur fréquente est d'auditer tout et de n'alerter sur rien, noyant les analystes sous des événements 4662 bruts. Réglez sur le volume et l'ampleur, pas sur des événements isolés, et appuyez-vous sur les honeytokens pour un signal à haute fidélité. Une autre erreur est de supposer que, parce que la collecte utilise des protocoles légitimes, elle ne peut être détectée — la forme de l'activité (une source, éventail énorme, courte fenêtre) est très détectable même si chaque requête individuelle est normale.

Liste de vérification défensive

1. Mettre en œuvre l'administration en niveaux et interdire les identifiants de Niveau 0 sur les hôtes de niveaux inférieurs. 2. Déployer des PAW et des comptes d'administration distincts par niveau. 3. Inscrire les comptes de grande valeur dans Utilisateurs protégés et les marquer comme non délégables. 4. Supprimer la délégation non contrainte ; utiliser RBCD. 5. Remplacer les comptes de service par gMSA ; retirer les SPN inutiles. 6. Déployer LAPS pour des mots de passe d'admin local uniques. 7. Auditer et élaguer les arêtes d'ACL (GenericAll/WriteDacl/WriteOwner). 8. Activer l'audit d'accès au service d'annuaire ; construire une corrélation SIEM pour le volume et l'éventail de 4662/4661/5136/4769. 9. Planter des comptes honeytoken et surveiller tout accès. 10. Exécuter régulièrement l'analyse de graphes sur son propre annuaire et suivre les chemins vers le Niveau 0 comme KPI.

Foire aux questions

Est-il sûr d'exécuter BloodHound contre mon propre annuaire ? La collecte est intensive en lecture et généralement à faible risque lorsqu'elle est réalisée par des défenseurs autorisés durant une évaluation planifiée, mais traitez les données résultantes comme sensibles — elles constituent une carte littérale de la façon de compromettre votre domaine. Stockez-les chiffrées, restreignez l'accès et supprimez les jeux de données obsolètes. Coordonnez-vous avec votre SOC pour que la collecte elle-même ne déclenche pas de faux incident, et opérez toujours sous autorisation écrite et exclusivement dans votre propre environnement.

Les chemins d'attaque peuvent-ils atteindre zéro ? En pratique, non — une certaine administration est toujours requise et les administrateurs créent toujours des sessions. L'objectif réaliste est de minimiser le nombre de principaux ayant un quelconque chemin vers le Niveau 0, de garder les chemins restants courts et fortement surveillés, et de s'assurer que chaque étape est instrumentée avec une détection à haute fidélité pour que parcourir le chemin soit bruyant plutôt que silencieux.

Conclusion

BloodHound et la cartographie des chemins d'attaque recadrent la sécurité Active Directory : d'une liste de mauvaises configurations isolées à un graphe connecté de conséquences. Pour les défenseurs, ce basculement est habilitant : la même analyse qu'un adversaire utiliserait pour trouver la route la plus courte vers l'Administrateur du domaine est celle que vous pouvez exécuter en premier pour couper ces routes. Combinez le durcissement piloté par le graphe — administration en niveaux, nettoyage de la délégation, gMSA, LAPS, Utilisateurs protégés et élagage des ACL — avec une détection en couches bâtie sur l'audit de l'annuaire, la télémétrie de session, la filiation EDR et les honeytokens, et la surface d'attaque qui semblait autrefois insaisissable devient une métrique mesurable et décroissante. Comprenez le graphe, et vous pourrez le défendre.