Active Directory délégations et chemins d’attaque

Active Directory concentre l’identité, l’autorisation et une partie considérable de l’administration Windows. Cette concentration rend l’annuaire très efficace, mais transforme chaque délégation mal bornée en relation potentielle vers le contrôle du domaine. Le compromis est net : déléguer localement accélère l’exploitation, mais multiplie les chemins de privilèges qu’il faut démontrer inexistants.

→ Lire l’explication complète de la marmotte

Forêt, domaines, unités organisationnelles et objets Active Directory

Active Directory est le service d’annuaire de Microsoft pour les environnements Windows. Une forêt est sa frontière de sécurité et de schéma : elle partage un catalogue global, une configuration et des relations d’approbation entre domaines. Un domaine fournit un espace de noms, une base de comptes et ses propres contrôleurs de domaine. Compromettre les privilèges d’administration du domaine racine ne donne pas automatiquement tous les droits sur chaque domaine enfant, mais donne souvent les moyens de les atteindre. La nuance compte, même si certaines présentations commerciales préfèrent dessiner une grande forteresse avec trois cadenas.

Les unités organisationnelles structurent les objets pour l’administration et l’application des stratégies de groupe. Elles ne sont pas des frontières de sécurité. Une unité organisationnelle contenant des serveurs critiques ne devient pas protégée parce qu’elle s’appelle Production, Tier0 ou NE-PAS-TOUCHER-FINAL-v4. La protection provient des droits effectifs, des groupes, des stratégies appliquées et de l’isolement des comptes qui administrent ces ressources.

Les objets incluent notamment les utilisateurs, groupes, ordinateurs, comptes de service, stratégies de groupe et unités organisationnelles. Chaque objet porte un descripteur de sécurité, qui contient un propriétaire, une liste de contrôle d’accès discrétionnaire et, plus rarement dans les usages courants, une liste d’audit. Une ACL (Access Control List) associe des identités à des droits précis. Ces droits peuvent viser l’objet entier, un attribut particulier, un type d’objet enfant ou une propriété étendue.

Le danger réel ne se limite pas au droit GenericAll, qui donne un contrôle total et alerte même les inventaires les plus paresseux. Un droit WriteProperty sur l’attribut servicePrincipalName, un droit de réinitialisation de mot de passe, la possibilité d’ajouter un membre à un groupe, ou le droit de modifier un lien de stratégie de groupe suffisent souvent. La sécurité d’Active Directory se lit comme un graphe, pas comme une liste de groupes administrateurs.

L’interface LDAP (Lightweight Directory Access Protocol) permet de consulter et modifier cette structure. La découverte des métadonnées exposées mérite un contrôle distinct, notamment lorsque des services répondent sans authentification : énumérer les métadonnées LDAP anonymes détaille ce point. Un annuaire qui révèle sa topologie à une identité non autorisée réduit le coût de préparation d’une attaque, même s’il ne livre pas immédiatement un privilège.

Délégations Active Directory : le graphe avant la liste des droits

La délégation permet de confier une opération sans remettre le contrôle complet du domaine. C’est indispensable. Interdire toute délégation revient à transformer l’équipe d’annuaire en goulot d’étranglement permanent, puis à voir apparaître des comptes surpuissants créés dans l’urgence. Le bon choix n’est pas l’absence de délégation : c’est la délégation minimale, traçable, périodiquement recalculée.

Une délégation doit être évaluée avec quatre questions :

Quelle identité reçoit le droit, directement ou via un groupe ?
Sur quels objets, attributs et descendants s’applique-t-il ?
Quelle modification cette identité peut-elle produire ?
Quelle relation cette modification ouvre-t-elle ensuite ?

Le quatrième point sépare l’audit sérieux de la lecture décorative d’une console. Un groupe de support peut disposer du droit de réinitialiser les mots de passe dans une unité organisationnelle. Si cette unité contient un compte capable de modifier l’appartenance d’un groupe d’administration de serveurs, la délégation devient un chemin indirect. Si un de ces serveurs héberge une session d’un administrateur de domaine, le chemin atteint le domaine. Chaque maillon paraît défendable isolément. Ensemble, ils constituent un escalier vers la cave à clés.

Les droits hérités sont particulièrement traîtres. Une ACL posée sur une unité organisationnelle peut s’appliquer aux objets enfants existants et futurs selon ses indicateurs d’héritage. Créer ultérieurement un compte de service sensible sous cette unité peut donc lui attribuer, sans action supplémentaire, un droit de modification détenu depuis longtemps par un groupe technique. La création d’un objet est alors une modification de la surface d’attaque, pas une banalité administrative.

Les groupes imbriqués compliquent encore le calcul. Un droit accordé à un groupe local de domaine peut être effectif pour un utilisateur membre d’un groupe global, lui-même alimenté par une synchronisation RH ou un processus d’approbation applicatif. L’audit doit résoudre l’appartenance effective, y compris les groupes protégés, les groupes de distribution convertis à tort en groupes de sécurité et les délégations accordées à des identités désactivées mais non supprimées.

La recommandation est ferme : réserver les droits d’écriture sur les objets de niveau 0, notamment contrôleurs de domaine, comptes d’administration, groupes privilégiés, stratégies de groupe critiques et comptes de service d’infrastructure, à des groupes d’administration dédiés. Aucun groupe de support généraliste ne doit pouvoir modifier directement ou par héritage ces objets. La séparation des niveaux d’administration reste plus utile qu’un nouveau tableau de bord violet promettant de « réduire la complexité identitaire par intelligence augmentée ».

Kerberoasting et délégation non contrainte

Kerberos est le protocole d’authentification principal des domaines Active Directory. Un compte de service peut posséder un SPN (Service Principal Name), identifiant qui associe un service à une identité. Lorsqu’un utilisateur demande un ticket pour ce service, le contrôleur de domaine remet un ticket chiffré avec une clé dérivée du secret du compte de service. Une identité de domaine authentifiée peut généralement demander ce ticket.

Le Kerberoasting consiste à récupérer ces tickets puis à tenter de retrouver hors ligne le mot de passe du compte de service. L’attaque ne dépend pas de l’accès interactif au compte ciblé. Sa résistance dépend donc directement de l’entropie du secret, du type de chiffrement autorisé et de l’exposition des comptes dotés d’un SPN. Un mot de passe humain, même long selon un tableur de conformité, reste une cible de craquage hors ligne si son modèle est prévisible.

Les comptes de service privilégiés doivent utiliser des mots de passe générés, longs et rotatés automatiquement, ou des gMSA (group Managed Service Accounts) lorsque l’application et le système les supportent. Désactiver RC4, algorithme historique faible, réduit des opportunités mais ne remplace pas cette mesure : un ticket chiffré avec AES reste attaquable hors ligne si le secret est devinable. La page sur les protocoles NTLM et leur durcissement complète ce travail sur les mécanismes hérités, souvent présents dans les mêmes environnements.

La délégation non contrainte autorise un serveur à recevoir et réutiliser les informations d’authentification Kerberos d’un utilisateur vers d’autres services. Elle est historiquement pratique pour certains scénarios anciens, mais constitue une dette de sécurité toxique. Si un administrateur de domaine s’authentifie sur une machine ainsi configurée et que cette machine est compromise, l’attaquant peut obtenir de quoi agir au nom de cet administrateur. La règle opérationnelle est d’éliminer la délégation non contrainte, sauf exception documentée, temporaire et isolée des comptes privilégiés.

La délégation contrainte avec transition de protocole réduit le périmètre, mais doit être traitée comme un privilège de déplacement latéral. Les services autorisés doivent être explicitement limités, les comptes doivent être sensibles et ne pas pouvoir être délégués lorsque nécessaire, et les comptes d’administration de niveau 0 ne doivent jamais ouvrir de session sur des hôtes de niveau inférieur. Aucun paramètre Kerberos ne compense une discipline de session inexistante.

Exemple : identifier des délégations et ACL à risque

L’inventaire initial doit collecter les ordinateurs configurés pour la délégation non contrainte et les objets dont les ACL accordent des droits d’écriture sensibles. Le module PowerShell ActiveDirectory est requis, avec un poste d’administration joint au domaine et des droits de lecture sur l’annuaire. L’exécution depuis un compte très privilégié est inutile et augmente seulement la gravité d’une erreur de manipulation.

# Requiert RSAT et le module ActiveDirectory.
Import-Module ActiveDirectory

# Liste les ordinateurs marqués pour la délégation non contrainte.
Get-ADComputer -LDAPFilter "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" `
  -Properties DNSHostName, OperatingSystem |
  Select-Object Name, DNSHostName, OperatingSystem

# Examine les droits non hérités sur une unité organisationnelle ciblée.
# Remplacer le Distinguished Name par l'unité auditée.
$ou = "OU=Servers,DC=example,DC=local"
(Get-Acl "AD:$ou").Access |
  Where-Object {
    $_.IsInherited -eq $false -and
    $_.ActiveDirectoryRights.ToString() -match "GenericAll|GenericWrite|WriteDacl|WriteOwner|WriteProperty"
  } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType, InheritanceType

Cette commande ne prouve pas une compromission. Elle révèle des arêtes de graphe à qualifier : identité source, cible, portée héritée, attribut réellement modifiable et privilège atteignable. Les droits WriteDacl et WriteOwner méritent une priorité maximale, car ils permettent respectivement de modifier la liste de contrôle d’accès ou d’en prendre le contrôle. Une ACL peut donc devenir la machine qui fabrique l’ACL suivante. C’est moins spectaculaire qu’un rançongiciel avec une tête de mort, mais nettement plus durable.

Les résultats doivent être exportés, versionnés et comparés à une base approuvée. Une revue manuelle unique ne détecte pas la dérive introduite par les créations de comptes, les modifications de groupes ou les changements d’héritage.

BloodHound, cartographie des chemins et exploitation durable

BloodHound collecte les relations Active Directory et les représente sous forme de graphe. Il relie comptes, groupes, sessions, droits ACL, délégations, stratégies de groupe et hôtes pour calculer des chemins vers des groupes ou actifs sensibles. Son intérêt n’est pas de révéler un droit inconnu, mais de démontrer la conséquence combinée de droits connus. C’est précisément ce que les revues par équipe ratent : chaque équipe connaît son morceau de corde, personne ne voit le nœud coulant.

La collecte doit être réalisée depuis une identité de lecture dédiée, limitée et supervisée. Les données extraites contiennent une cartographie extrêmement exploitable : groupes, relations de confiance, systèmes, sessions et délégations. Les stocker sur un poste personnel ou les déposer dans un outil collaboratif généraliste revient à publier le plan de l’immeuble avec les clés marquées au feutre. Chiffrer les exports, limiter leur accès et définir une durée de conservation sont des exigences minimales.

Les équivalents de BloodHound peuvent compléter l’analyse, mais aucun outil ne remplace la décision d’architecture. Il faut définir les cibles interdites, généralement les groupes d’administration de domaine, les contrôleurs de domaine, les autorités de certification et les comptes qui administrent les postes d’administration. Ensuite, traiter les chemins selon leur coût réel : supprimer une délégation, déplacer un objet vers une unité organisationnelle protégée, modifier une appartenance, isoler les sessions d’administration ou remplacer un compte de service.

La supervision doit suivre les modifications d’ACL, des attributs de délégation, des SPN, des membres de groupes privilégiés et des liens de stratégies de groupe. Les événements ne suffisent pas sans centralisation et corrélation : une modification légitime et une escalade peuvent produire le même événement, seule la relation entre l’auteur, la cible et le changement permet de trancher. La gestion des identités doit donc inclure l’annuaire comme système de contrôle d’accès, pas seulement comme source de comptes pour les applications.

Active Directory ne garantit ni l’absence de mot de passe faible, ni l’isolement des sessions administratives, ni la pertinence d’une délégation. Il applique les règles qui lui sont confiées, avec une fidélité presque vexante. Le reste dépend de l’architecture de niveaux, de la rotation des secrets, des sauvegardes testées des contrôleurs de domaine, de la surveillance et d’une reprise documentée. Restaurer un annuaire sans maîtriser son état de sécurité peut restaurer aussi le chemin d’attaque, ce qui est une forme coûteuse de nostalgie.

🐝 Ce qui arrive si on s’en passe

Sans inventaire des délégations ni cartographie des chemins, la persistance devient silencieuse : une arête ajoutée dans une ACL survit à la réinitialisation des mots de passe, au renouvellement des secrets de comptes de service et même à la rotation du krbtgt, puisque le droit d’écriture suffit à recréer un accès. Le périmètre de remédiation cesse d’être calculable : après incident, rien ne permet de distinguer une délégation légitime d’un droit posé par un attaquant, ce qui prolonge indéfiniment la fenêtre d’investigation. Les dépendances avals héritent du problème : applications adossées à l’annuaire, autorités de certification et accès aux serveurs de fichiers font confiance à des appartenances de groupe dont la provenance n’est plus traçable. Enfin, faute d’état de référence approuvé, la reconstruction après compromission se discute en semaines, pas en heures.

🦫 Explication de la marmotte 🍫

Active Directory conserve les comptes des personnes, des ordinateurs et des services d’une entreprise. Il les range dans une structure composée d’une grande séparation, de domaines, de dossiers administratifs et d’objets. Chaque objet porte des règles indiquant qui peut le lire ou le modifier. Ces règles peuvent aussi s’appliquer aux objets placés plus tard dans un dossier administratif.

Une délégation donne une partie de l’administration à une personne ou à un groupe. Le risque apparaît lorsqu’un droit permet de modifier un compte, un groupe ou une règle qui donne ensuite accès à une autre ressource. Plusieurs autorisations limitées peuvent alors former une chaîne complète jusqu’aux comptes qui contrôlent le domaine. Il faut donc étudier les liens entre les autorisations, pas seulement vérifier qu’aucune personne n’est directement administratrice.

Certains comptes de service utilisent un mot de passe pour chiffrer des preuves d’accès. Une personne déjà connectée au domaine peut demander une copie de cette preuve et essayer de retrouver le mot de passe hors ligne. Un mot de passe généré automatiquement résiste bien mieux. D’autres réglages permettent à un serveur de réutiliser l’identité d’une personne connectée : si ce serveur est compromis, cette identité peut être volée.

Des outils construisent une carte des comptes, droits, groupes et connexions. Cette carte révèle les chaînes dangereuses. Après correction, il faut surveiller les changements, renouveler les secrets et tester la restauration des données de l’annuaire.

Pages voisines

La citent

Active Directory délégations et chemins d’attaque

Elle cite

: les deux pages se citent l’une l’autre.

Active Directory délégations et chemins d’attaque

Active Directory délégations et chemins d’attaque

Forêt, domaines, unités organisationnelles et objets Active Directory

Délégations Active Directory : le graphe avant la liste des droits

Kerberoasting et délégation non contrainte

Exemple : identifier des délégations et ACL à risque

BloodHound, cartographie des chemins et exploitation durable

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines