SOC managé - surveillance continue  ·  veille cyber : CERT-FR / CISA / NVD  ·  réponse à incident : dispositif sous contrat
Tous les contenus Terrain

Durcissement · Guide pratique

BloodHound CE : comprendre les chemins d’attaque AD et Entra ID

Validation Rejeu confirmé par Kenawek le 10 octobre 2026.Versions testées Non précisées dans cette publication.À revoir Lors de toute évolution des versions, des outils ou du périmètre.

Un compte peu privilégié peut parfois atteindre une ressource sensible par une succession de relations : appartenance à un groupe, droit sur une machine, contrôle d’un autre compte. BloodHound représente ces relations sous forme de graphe. Son intérêt défensif est de rendre visibles des combinaisons difficiles à repérer dans des listes séparées, puis d’aider à choisir une correction.

En résumé

  • Un chemin dans un graphe décrit des relations observées et des hypothèses, pas une intrusion déjà réussie.
  • SharpHound et AzureHound collectent des données complémentaires sur AD et les environnements Microsoft cloud.
  • La qualité et l’âge de la collecte limitent la portée des conclusions.
  • Les données de graphe sont sensibles et doivent être protégées comme une cartographie d’accès.
  • La remédiation doit être confirmée par une nouvelle collecte et un test du fonctionnement légitime.

1. Lire un graphe sans jargon

Un nœud représente un objet, par exemple un utilisateur, un groupe ou un ordinateur. Une arête représente une relation, comme une appartenance ou une capacité de contrôle. Un chemin relie plusieurs nœuds. Certaines relations sont directement observées ; leur effet dépend aussi de conditions que le graphe ne connaît pas toujours, comme la joignabilité réseau, une session récente ou des contrôles complémentaires.

Exemple pédagogique de chemin à examiner
  1. Compte prestatairePoint de départ fictif
  2. Groupe déléguéAppartenance à vérifier
  3. Serveur sensibleDroit local à qualifier
  4. Identité privilégiéeRelation et conditions à confirmer
  5. Correction cibléeRetirer le droit inutile, puis recollecter

Ce schéma est conceptuel : il ne correspond pas à un incident client ni à une chaîne automatiquement exploitable. L’objectif est de trouver où une permission non nécessaire crée un passage. Le chemin le plus court n’est pas toujours le plus probable ou le plus important pour le métier.

2. Préparer la collecte autorisée

Définissez les domaines, tenants, plages horaires et méthodes permises. Désignez les personnes à prévenir si la collecte déclenche une alerte. Les méthodes ne demandent pas toutes les mêmes droits ni les mêmes accès réseau. Une collecte autorisée ne justifie pas de lui donner systématiquement un compte administrateur du domaine.

La documentation BloodHound Community Edition distingue notamment SharpHound CE pour les données AD et AzureHound CE pour les données Microsoft cloud. Choisissez des versions compatibles avec votre serveur BloodHound et consignez les options réellement utilisées. Ce guide ne suppose pas que toutes les fonctions d’une édition commerciale sont disponibles en CE.

PréparationRésultat attendu
PérimètreDomaines, tenants et exclusions autorisés
VersionsBloodHound et collecteurs identifiés
IdentitésPermissions justifiées et durée d’usage
ChargeMéthodes et fenêtre adaptées au réseau
DonnéesStockage chiffré, accès et suppression prévus

3. Vérifier la qualité avant l’analyse

Importez les résultats dans une instance dédiée et protégée. Relevez les heures de début et de fin, les erreurs et les objets attendus absents. Si une méthode n’a pas pu accéder à certaines machines, ne présentez pas le graphe comme exhaustif. Une collecte de sessions vieillit particulièrement vite ; l’âge de la donnée doit accompagner son interprétation.

Comparez quelques comptes, groupes et relations avec les sources d’administration. Ce contrôle par échantillon aide à repérer une collecte incomplète ou une erreur de périmètre. Dans un environnement hybride, ne fusionnez pas deux identités uniquement parce qu’elles ont le même nom : la relation doit être établie par les identifiants et les mécanismes supportés.

Commencez par quelques cibles à forte valeur : administration de l’annuaire, gestion du tenant ou système métier essentiel. Ajoutez des points de départ représentatifs, comme un groupe d’utilisateurs standards ou un prestataire. Cette sélection rend l’analyse plus lisible qu’un export massif de tous les chemins possibles.

4. Qualifier chaque relation importante

Ouvrez la description de la relation dans la documentation correspondant à votre version. Vérifiez sa source, ses prérequis et les conditions qui pourraient l’empêcher de produire l’effet envisagé. Demandez au propriétaire du système pourquoi le droit existe. Une permission dangereuse peut être nécessaire temporairement ; elle doit alors être limitée et surveillée.

Pour une frontière hybride, examinez les comptes et applications de synchronisation, les rôles cloud et les délégations locales. La présence d’un serveur Entra Connect ne prouve pas à elle seule un chemin de prise de contrôle du tenant. Documentez précisément les autorisations et mécanismes impliqués.

Le livrable utile explique le chemin en langage métier : qui pourrait atteindre quoi, grâce à quelle permission, sous quelles conditions et avec quel impact. Évitez de réduire le rapport à une capture de graphe illisible ou à un nombre d’arêtes.

5. Choisir une correction et la vérifier

Privilégiez la suppression d’un droit inutile ou la séparation d’une identité qui réduit plusieurs chemins, tout en évaluant l’impact métier. Un retrait aveugle de groupe peut casser une tâche planifiée ou un service. Préparez un ticket avec la relation exacte, le propriétaire, le changement, le retour arrière et la preuve attendue.

Après correction, relancez la collecte adaptée et vérifiez la disparition de la relation visée. Testez aussi le parcours légitime qui utilisait ce droit. Si le chemin disparaît parce que le collecteur a perdu son accès, ce n’est pas une preuve de remédiation. La comparaison doit porter sur des collectes comparables.

6. Recette et fin de mission

  • Créer dans un laboratoire une relation de groupe connue et vérifier sa présence.
  • Prévoir un objet volontairement hors périmètre et vérifier que l’exclusion est documentée.
  • Supprimer une délégation fictive, recollecter et comparer les résultats.
  • Tester un échec de collecte pour vérifier qu’il reste visible dans le rapport.
  • Rétablir la seule configuration de test nécessaire au fonctionnement attendu.
  • Retirer les comptes temporaires et appliquer la durée de conservation aux archives et exports.

Consignez les versions, durées et sorties observées à chaque rejeu. Les exports révèlent des relations sensibles : limitez leur diffusion et évitez de les joindre sans protection à un ticket public.

Sources et références

Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.

Cadrer votre besoin

Besoin de relier ces contrôles à votre environnement ? Parler de votre projet avec Kenawek.