Gérer les chemins d'attaque avec BloodHound en défense

La plupart des compromissions d'Active Directory suivent un chemin plutôt qu'une vulnérabilité unique. Un groupe du support peut réinitialiser le mot de passe d'un administrateur de serveurs. Cet administrateur a une session sur un serveur où un Domain Admin s'est aussi connecté. Un compte de service détient GenericWrite sur un groupe imbriqué dans un groupe qui contrôle une GPO liée à l'UO Domain Controllers. Chaque étape est une autorisation normale que quelqu'un a accordée volontairement. Ensemble, elles forment une route vers le contrôle du domaine, et les attaquants les trouvent avec les mêmes outils de graphe que ceux dont disposent les défenseurs.

BloodHound transforme les données de l'annuaire en ce graphe. Le guide de référence sur les ACL le présente comme un outil d'audit. Ce guide explique comment en faire un programme continu de gestion des chemins d'attaque : collecter en sécurité, définir précisément le Tier Zero, trouver les points de passage obligés, corriger dans l'ordre qui supprime le plus de chemins par changement, et mesurer les progrès.

Collecter en sécurité

BloodHound Community Edition ingère les données de SharpHound (AD local) et d'AzureHound (Entra ID). BloodHound Enterprise ajoute la collecte continue et la notation des points de passage obligés. Parmi les alternatives reposant sur des modèles similaires figurent Semperis Forest Druid (centré sur le Tier 0) et Adalanche. La méthode ci-dessous s'applique à tous.

Règles de collecte pour un programme défensif :

• Compte dédié. Un utilisateur de domaine normal, sans droits supplémentaires, suffit pour les données LDAP. La collecte des groupes locaux et des sessions fonctionne mieux avec des droits sur les ordinateurs membres, mais n'utilisez pas un Domain Admin pour les obtenir. Donnez au compte un mot de passe long et aléatoire, refusez-lui l'ouverture de session interactive et surveillez son utilisation.
• Hôte dédié. Lancez le collecteur depuis un hôte d'administration Tier 0 ou une VM d'évaluation durcie, jamais depuis un poste utilisateur.
• Prévenez le SOC. Le trafic de SharpHound (requêtes LDAP massives, énumération SAMR et des sessions sur de nombreux hôtes) est exactement ce sur quoi vos détections doivent alerter. Mettez l'hôte et le compte en liste d'autorisation pendant la fenêtre de collecte plutôt que d'affaiblir la détection.
• Protégez les résultats. Les fichiers ZIP et la base BloodHound sont une carte expliquant comment prendre le contrôle de votre domaine. Stockez-les chiffrés, limitez l'accès au Tier 0 et à l'équipe d'évaluation, et fixez une durée de conservation.
• Collectez les sessions à plusieurs reprises. Un instantané unique des sessions manque l'essentiel de l'exposition. Collectez plusieurs fois au cours d'une semaine, ou utilisez un collecteur continu.

Définir le Tier Zero avant d'examiner les chemins

Un chemin n'est un chemin d'attaque que s'il aboutit à quelque chose d'important. BloodHound balise d'office les objets Tier Zero évidents (Domain Admins, Enterprise Admins, contrôleurs de domaine, l'objet domaine, etc.). Dans les versions récentes, cette notion est devenue Privilege Zones, avec une zone Tier Zero. Le balisage par défaut est un point de départ, pas votre Tier Zero. Ajoutez tout ce qui exerce un contrôle sur le plan de contrôle :

• Les serveurs Entra Connect et leur compte de connecteur AD DS, ainsi que les serveurs ADFS.
• Les autorités de certification d'entreprise AD CS et les modèles de certificats qui permettent de s'authentifier en tant que n'importe qui (mauvaises configurations de type ESC1).
• Les serveurs et comptes de sauvegarde capables de restaurer ou de lire les sauvegardes des DC.
• La gestion des hyperviseurs et du stockage qui héberge des DC virtuels.
• Les systèmes de gestion de configuration et de PAM qui exécutent du code sur les DC ou détiennent des identifiants Tier 0.
• Les GPO liées à l'UO Domain Controllers ou à la racine du domaine, et les UO contenant des objets Tier 0.
• Les comptes détenant des droits de réplication, tels que révélés par l'audit des droits DCSync.

Cette liste provient de votre inventaire Tier 0. Si le graphe et l'inventaire divergent, l'un des deux est faux, et les deux erreurs sont des constats. Tout ce qui est atteignable depuis le Tier Zero par une arête de contrôle fait aussi partie du Tier Zero, que vous l'ayez voulu ou non.

Mesurer : les requêtes qui comptent

La recherche de chemins intégrée est utile pour explorer. Un programme repose sur un ensemble fixe de requêtes enregistrées dont on peut compter les résultats. Ces exemples Cypher fonctionnent dans la vue de requêtes de BloodHound CE. Adaptez la cible à votre propre balisage du Tier Zero :

// Principals with a direct control edge onto Domain Admins or the domain object.
// Expect built-in admin groups and DCs; everything else needs an owner.
MATCH (n)-[r:GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns|AddMember|AllExtendedRights|DCSync|GetChangesAll]->(t)
WHERE t:Domain OR (t:Group AND t.objectid ENDS WITH '-512')
RETURN n.name, type(r), t.name

// Domain Admins with sessions on computers that are not domain controllers
MATCH (c:Computer)-[:HasSession]->(u:User)-[:MemberOf*1..]->(g:Group)
WHERE g.objectid ENDS WITH '-512'
  AND NOT (c)-[:MemberOf]->(:Group {name: 'DOMAIN CONTROLLERS@CORP.EXAMPLE.COM'})
RETURN DISTINCT c.name, u.name

// Shortest paths from Domain Users to Domain Admins
MATCH p = shortestPath((s:Group)-[*1..]->(t:Group))
WHERE s.objectid ENDS WITH '-513' AND t.objectid ENDS WITH '-512'
RETURN p

Suivez aussi, chaque semaine : le nombre de principaux ayant un chemin quelconque vers le Tier Zero, la proportion d'utilisateurs activés disposant d'un tel chemin, et le nombre d'arêtes distinctes de premier degré entrant dans le Tier Zero. Ces trois chiffres sont les indicateurs clés de votre programme.

Trouver les points de passage obligés

Un point de passage obligé est une arête ou un nœud par lequel passent de nombreux chemins. Supprimer une seule arête de ce type peut rompre des centaines de chemins. Supprimer l'arête de départ d'un chemin n'en rompt généralement qu'un seul. BloodHound Enterprise calcule cela. Dans CE, vous pouvez en faire une approximation :

1. Exportez tous les plus courts chemins depuis les grands groupes sources (Domain Users, Authenticated Users, Domain Computers) vers vos cibles Tier Zero.
2. Comptez combien de fois chaque arête apparaît dans ces chemins.
3. Triez par nombre d'occurrences, puis par proximité de l'arête avec le Tier Zero.

Pondérez ce décompte par la taille de la source. Un chemin qui part de Domain Users place chaque compte d'employé à un e-mail de phishing du Tier Zero. Un chemin qui part d'un seul compte de service désactivé est bien moins urgent, même s'il est plus court. Notez aussi quelles arêtes sont structurelles (appartenance aux groupes, ACL, liaisons de GPO) et lesquelles sont transitoires (sessions). Les arêtes structurelles se corrigent une fois. Les arêtes transitoires exigent de changer la manière dont les personnes et les outils travaillent.

Les arêtes situées à un saut du Tier Zero l'emportent presque toujours. Elles se trouvent sur chaque chemin qui atteint la cible par leur intermédiaire, et les supprimer se résume généralement à une seule modification d'ACL ou d'appartenance sur un objet bien identifié.

Ordre de correction

Procédez dans cet ordre. Chaque étape supprime plus d'exposition par changement que la suivante.

1. Les arêtes de contrôle entrant dans le Tier Zero depuis l'extérieur. GenericAll, WriteDacl, WriteOwner, Owns, AddMember et les droits de réplication détenus par des principaux hors Tier Zero sur des objets Tier Zero. Supprimez-les, ou intégrez le principal au Tier Zero et protégez-le en conséquence. Vérifiez d'abord AdminSDHolder et la racine du domaine.
2. L'exposition des identifiants Tier Zero. Les arêtes HasSession d'utilisateurs Tier Zero vers des ordinateurs de niveau inférieur. La correction est opérationnelle : PAW, restrictions d'ouverture de session et stratégies d'authentification, pas des modifications d'ACL.
3. Les principaux larges disposant d'un contrôle. Toute arête partant d'Everyone, Authenticated Users, Domain Users ou Domain Computers. Elles font de chaque compte un point de départ.
4. Le contrôle des GPO et des UO sur le Tier Zero. Les droits d'écriture sur les GPO liées au-dessus d'objets Tier Zero, et l'écriture de gPLink sur ces UO.
5. La prolifération des administrateurs locaux. L'éventail AdminTo créé par des mots de passe d'administrateur local partagés ou par des groupes larges dans les Administrateurs locaux. Déployez Windows LAPS et retirez les groupes du domaine des administrateurs locaux.
6. Les arêtes de délégation et de certificats. AllowedToDelegate, AllowedToAct, AddKeyCredentialLink et les arêtes ESC d'AD CS, traitées dans les guides des domaines correspondants.

Pour les arêtes d'ACL, supprimez l'ACE précise plutôt que l'ensemble des accès du principal. Sauvegardez le SDDL de l'objet avant de le modifier :

$dn  = 'CN=Tier0-Servers,OU=Groups,OU=Tier0,DC=corp,DC=example,DC=com'
$acl = Get-Acl "AD:\$dn"
$acl.Sddl | Out-File "C:\Tier0\Backup\$(Get-Date -f yyyyMMdd)-Tier0-Servers.sddl"

$acl.Access | Where-Object {
    $_.IdentityReference -eq 'CORP\Helpdesk-L2' -and -not $_.IsInherited -and
    $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty'
} | ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl "AD:\$dn" -AclObject $acl

Si l'arête est héritée, corrigez-la sur l'UO parente où elle est définie. Vérifiez aussi si l'objet a l'héritage bloqué, ce qui est typique des comptes touchés par SDProp.

Vérifier

Chaque sprint de correction se termine par une nouvelle collecte, pas par une case cochée :

• Relancez les requêtes enregistrées. Les arêtes précises que vous avez supprimées doivent avoir disparu, et le nombre de chemins doit baisser.
• Vérifiez qu'aucune nouvelle arête de premier degré entrant dans le Tier Zero n'est apparue. Les régressions viennent généralement de nouvelles installations d'applications ou d'assistants de délégation.
• Suivez les indicateurs dans le temps. Une baisse du nombre de « principaux ayant un chemin vers le Tier Zero » est la preuve la plus claire que le programme fonctionne.

Entre deux collectes, détectez les mêmes changements en temps réel. L'événement 5136 sur les objets Tier Zero (modifications d'ACL et de member) et les événements 4728/4732/4756 pour l'appartenance aux groupes doivent alimenter le même pipeline d'alertes que vos autres détections Tier 0.

Ce que cela casse

• Les délégations dont on avait oublié dépendre. Les équipes du support ou applicatives perdent les droits qui sous-tendaient un chemin. Convenez d'un propriétaire et d'un retour arrière (le SDDL sauvegardé) avant chaque changement, et procédez par petits lots.
• Les habitudes des administrateurs. Supprimer les sessions Tier Zero des serveurs membres signifie que les administrateurs cessent d'utiliser des comptes Domain Admin pour le travail sur les serveurs. Fournissez d'abord des comptes d'administration hiérarchisés et des PAW, sinon les sessions reviendront.
• Les outils d'éditeurs aux droits étendus. Les produits de sauvegarde, d'IAM et de supervision demandent souvent GenericAll sur de grandes UO. Réduisez leur périmètre avec l'éditeur, ou intégrez le produit au Tier Zero et protégez-le.
• Le volume d'alertes du SOC pendant les fenêtres de collecte, en l'absence de coordination.

Pour aller plus loin : le guide de référence sur les ACL, Tier 0 et accès privilégiés, et mener une évaluation PingCastle pour une vision complémentaire fondée sur un score.