Cartographier le domaine — Pentest Active Directory

Table des matières

Pourquoi cartographier avant d'exploiter

Un audit Active Directory qui saute directement à l'exploitation — Kerberoasting à l'aveugle, tentative de mouvement latéral sur la première machine venue — produit des résultats désordonnés et un rapport difficile à défendre devant le client. La cartographie est la phase qui transforme un accès initial anonyme en une compréhension structurée de l'environnement : combien de domaines, quelles relations de confiance existent avec l'extérieur, où sont les comptes à privilèges, quelles machines sont réellement en périmètre.

Cette étape a aussi une valeur contractuelle. Le scope d'un test d'intrusion AD précise généralement un ou plusieurs domaines autorisés — cartographier permet de vérifier qu'on reste dans ce périmètre, notamment lorsque des trusts mènent vers des forêts partenaires qui, elles, ne sont pas couvertes par l'autorisation signée.

Un trust externe ou inter-forêt découvert en cartographie ne doit jamais être suivi sans vérification préalable du scope contractuel. Franchir une frontière de confiance vers un système non autorisé transforme un test légal en intrusion non couverte, même si l'accès technique est trivial.

La forêt, les domaines et les trusts

Une forêt Active Directory regroupe un ou plusieurs domaines qui partagent un schéma, un catalogue global et une configuration commune. Le domaine racine (corp.local par exemple) peut avoir des domaines enfants (emea.corp.local), reliés par des trusts parent-enfant : bidirectionnels et transitifs par défaut. Deux forêts distinctes peuvent aussi être reliées par un trust inter-forêt ou par un trust externe, souvent utilisé pour connecter un partenaire, une filiale récemment acquise, ou un environnement legacy non migré.

La direction et la transitivité d'un trust déterminent ce qui est réellement exploitable :

Type de trust	Direction	Transitif	Cas d'usage typique
Parent-enfant	Bidirectionnel	Oui	Structure interne d'une même forêt
Arbre-racine	Bidirectionnel	Oui	Domaines de même forêt, arbres différents
Externe	Sens unique configurable	Non	Partenaire, ancien domaine legacy
Forêt	Bidirectionnel ou unique	Oui (au niveau forêt)	Fusion-acquisition, environnements séparés
Raccourci (shortcut)	Bidirectionnel ou unique	Oui	Optimisation de chemin d'authentification

Côté offensif, un trust sortant du domaine compromis vers un autre domaine signifie que des comptes de ce second domaine peuvent potentiellement s'authentifier sur des ressources du premier — et inversement selon la direction. Le SID filtering, activé par défaut sur les trusts externes et inter-forêts, limite l'usurpation de SID historiques (SID history) au travers de la frontière, mais reste mal configuré dans une proportion notable d'environnements audités.

Pour énumérer les trusts avec un compte de domaine standard :

Get-ADTrust -Filter * -Properties Direction, TrustType, ForestTransitive, SIDFilteringForestAware
nltest /domain_trusts /all_trusts

Lors d'un audit, la commande nltest /domain_trusts révèle un trust externe non transitif vers partner-ext.local, absent de la documentation fournie par le client. Signalé immédiatement au commanditaire avant toute tentative d'énumération de ce domaine tiers — c'est une découverte à traiter comme un finding de gouvernance, pas comme une invitation à pivoter.

Unités organisationnelles, utilisateurs, ordinateurs, groupes

L'arborescence des unités organisationnelles (OU) reflète en général l'organisation métier ou technique de l'entreprise : OU par direction, par site géographique, par type d'actif. Elle sert de support à la délégation d'administration et à l'application des GPO — deux informations précieuses pour un pentester.

Ce qu'il faut extraire en priorité :

Comptes à privilèges — membres directs et indirects de Domain Admins, Enterprise Admins, Administrators, mais aussi des groupes métiers custom qui portent des droits équivalents sans porter le nom
Comptes de service — souvent dotés de SPN, cibles naturelles du Kerberoasting traité au chapitre suivant
OU sensibles isolées (Tier 0) — quand elles existent, elles indiquent une tentative de tiering ; leur absence est en soi une information sur la maturité de la cible
Ordinateurs par type — contrôleurs de domaine, serveurs, postes de travail ; le ratio et la nomenclature donnent une idée de la taille réelle du parc
Groupes imbriqués — l'appartenance à un groupe via un autre groupe est une source fréquente de privilège caché, invisible en lisant uniquement l'appartenance directe

Get-ADUser -Filter * -Properties ServicePrincipalName,MemberOf | Where-Object {$_.ServicePrincipalName}
Get-ADGroupMember -Identity "Domain Admins" -Recursive
Get-ADComputer -Filter * -Properties OperatingSystem | Group-Object OperatingSystem

Croiser systématiquement l'appartenance récursive aux groupes à privilèges avec la liste des comptes ayant PasswordLastSet ancien ou PasswordNeverExpires activé. Un compte à privilèges dont le mot de passe n'a pas changé depuis des années est souvent le chemin le plus court vers un compromis complet, bien avant toute technique Kerberos avancée.

Vue synthétique d'un domaine cartographié : trusts, arborescence des OU, DNS intégré et sites AD.

DNS intégré à Active Directory

Dans la grande majorité des environnements, le DNS est intégré à Active Directory : les zones sont stockées dans l'annuaire et répliquées entre contrôleurs de domaine au lieu de fichiers de zone classiques. Ce détail a une conséquence directe pour la cartographie : le DNS révèle la topologie du domaine avant même d'ouvrir une session LDAP.

Les enregistrements SRV sous _msdcs.<domaine> listent les contrôleurs de domaine, les serveurs de catalogue global, et les rôles FSMO potentiels :

nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.local
nslookup -type=SRV _kerberos._tcp.dc._msdcs.corp.local
nslookup -type=SRV _gc._tcp.corp.local

Ces requêtes sont peu bruyantes — elles ressemblent à du trafic DNS légitime constant sur un réseau d'entreprise — mais elles ne sont pas invisibles pour autant : un serveur DNS journalisé et surveillé peut détecter un volume ou un motif de requêtes SRV inhabituel émis depuis un poste qui n'a normalement aucune raison de les émettre.

Le DNS intégré à AD accepte par défaut les mises à jour dynamiques sécurisées uniquement, mais des environnements legacy autorisent encore les mises à jour non sécurisées sur certaines zones. Ce point mérite d'être vérifié et documenté séparément — il ouvre la porte à des attaques de type usurpation ou empoisonnement DNS, hors du strict périmètre de la cartographie mais utile pour le rapport final.

Sites AD et topologie réseau

Les sites Active Directory, définis dans Active Directory Sites and Services, associent des sous-réseaux IP à des emplacements physiques ou logiques. Ils déterminent quel contrôleur de domaine un client contacte en priorité pour l'authentification, et gouvernent la réplication inter-sites.

Pour un pentester, la topologie des sites donne une carte du réseau sans avoir besoin d'accéder à la documentation infrastructure : elle indique combien de sites existent, quels sous-réseaux leur sont rattachés, et donc où chercher des contrôleurs de domaine additionnels ou des segments potentiellement moins surveillés.

Get-ADReplicationSite -Filter *
Get-ADReplicationSubnet -Filter * -Properties Site

Un domaine multi-sites avec un site distant faiblement doté en supervision — succursale, filiale récente, site industriel — est souvent un point d'entrée ou de rebond plus favorable qu'un siège social correctement instrumenté.

La topologie des sites conditionne également le choix du contrôleur de domaine ciblé pour une action donnée. Un DC situé sur un site distant, relié au reste de la forêt par une liaison de réplication planifiée plutôt qu'en temps réel, peut afficher un état légèrement désynchronisé par rapport au reste du domaine — utile à connaître si une action doit être menée avant qu'une modification (verrouillage de compte, changement de mot de passe) ne se propage partout.

Localiser les rôles FSMO et le catalogue global

Cinq rôles à maître unique (FSMO — Flexible Single Master Operations) sont répartis dans une forêt : Schema Master et Domain Naming Master au niveau forêt, PDC Emulator, RID Master et Infrastructure Master au niveau de chaque domaine. Leur localisation n'est pas indispensable à toutes les phases suivantes, mais elle a deux usages concrets en cartographie.

D'abord, le PDC Emulator est la référence de synchronisation horaire et le point de traitement prioritaire des changements de mot de passe récents dans le domaine — une information utile si une attaque par verrouillage ou une réinitialisation vient d'avoir lieu. Ensuite, un rôle FSMO hébergé sur un contrôleur de domaine isolé, à l'écart des autres DC en matière de patching ou de durcissement, peut signaler une dette technique intéressante à documenter pour le rapport.

Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

Le catalogue global (Global Catalog), hébergé sur un sous-ensemble des contrôleurs de domaine, mérite une identification séparée : il centralise un sous-ensemble d'attributs de tous les objets de la forêt, ce qui en fait une cible de choix pour des requêtes transversales à plusieurs domaines sans avoir à interroger chaque domaine individuellement.

Construire un inventaire sans bruit excessif

La cartographie complète d'un grand domaine peut générer un volume de requêtes LDAP conséquent. Deux réflexes réduisent l'exposition sans sacrifier la qualité de la collecte :

Prioriser avant d'énumérer en masse — commencer par les objets à forte valeur (comptes à privilèges, SPN, trusts, OU Tier 0) plutôt que de tirer un dump exhaustif dès la première requête
Espacer les requêtes automatisées — les outils de collecte massifs (type collecteurs SharpHound) génèrent des motifs de requêtes LDAP reconnaissables ; les lancer en une seule salve depuis un poste isolé est un signal fort pour une équipe de détection outillée
Privilégier LDAP/LDAPS natif à un compte authentifié plutôt que des null sessions, quand elles sont désactivées côté cible — les null sessions restent parfois actives sur des domaines anciens mais leur usage est en net recul et souvent surveillé spécifiquement
Documenter chaque requête significative — pour le rapport final, mais aussi pour pouvoir reconstruire une chronologie si l'équipe défense détecte une activité et demande des comptes

Un compte de service compromis utilisé pour une énumération massive et non maîtrisée peut déclencher un verrouillage de compte (account lockout) s'il existe une politique stricte, ou une alerte SIEM sur un volume anormal de requêtes LDAP/Kerberos depuis un même poste. Un audit qui provoque un incident de production non planifié abîme la relation de confiance avec le client, même si l'objectif technique est atteint.

Checklist de cartographie

Liste des domaines et forêts, avec direction et type de chaque trust
Filtrage SID vérifié sur les trusts externes et inter-forêts
Arborescence des OU principales et OU Tier 0 si elle existe
Membres directs et récursifs des groupes à privilèges
Comptes avec SPN, comptes à mot de passe ancien ou n'expirant jamais
Enregistrements SRV DNS des contrôleurs de domaine et du catalogue global
Sites AD et sous-réseaux associés, avec identification des sites distants
Journal horodaté des requêtes de reconnaissance effectuées, pour le rapport

Ce que la cartographie ne remplace pas

Cartographier donne une vue statique à un instant donné. Un domaine change en permanence — ajout de comptes, rotation de mots de passe, modification de GPO. Une cartographie réalisée en début de mission doit être révisée si l'audit s'étend sur plusieurs semaines, en particulier avant les phases d'exploitation les plus sensibles. Elle ne remplace pas non plus l'énumération LDAP et SMB détaillée, traitée au chapitre suivant, qui va plus loin dans la lecture des ACL et des partages.

La valeur de cette étape se mesure à la qualité des décisions qu'elle permet ensuite : quelles cibles Kerberoasting sont réellement rentables, quel chemin de mouvement latéral a le plus de chances d'aboutir à un compte à privilèges, quels trusts méritent d'être signalés comme risque de gouvernance indépendamment de toute exploitation technique.

L'essentiel à retenir

Ce chapitre présente la cartographie d'un domaine Active Directory comme préalable méthodologique à toute phase d'exploitation. Il détaille la lecture des trusts entre domaines et forêts, l'arborescence des unités organisationnelles, l'exploitation du DNS intégré à AD et la topologie des sites, puis propose une méthode d'inventaire qui limite le bruit journalisé côté défense. L'objectif est de produire, à partir d'un compte à faibles privilèges, une représentation exploitable du terrain sans déclencher d'alerte évitable.

Questions fréquentes

Faut-il toujours un compte de domaine pour cartographier, ou peut-on tout faire en anonyme ?

Une part significative de la cartographie DNS et réseau se fait sans authentification, mais l'énumération fine des OU, groupes et attributs utilisateur nécessite en général un compte de domaine, même à faibles privilèges. Les null sessions LDAP existent encore sur certains environnements anciens mais sont de moins en moins disponibles et souvent spécifiquement surveillées.

Comment savoir si un trust est réellement exploitable et pas seulement présent dans la configuration ?

La présence d'un trust ne garantit pas qu'il soit utilisable en pratique. Il faut vérifier sa direction, sa transitivité, l'état du SID filtering, et surtout tester si des comptes ou groupes du domaine de confiance ont effectivement des droits sur des ressources du domaine cible — un trust configuré mais jamais utilisé pour accorder des permissions a un intérêt limité pour l'exploitation, mais reste pertinent pour le rapport de gouvernance.

Quelle est la différence pratique entre un site AD et un simple sous-réseau IP ?

Un sous-réseau IP est une notion purement réseau, tandis qu'un site AD est un objet d'annuaire qui associe un ou plusieurs sous-réseaux à une localisation logique utilisée par Active Directory pour optimiser l'authentification et la réplication. Un site peut regrouper plusieurs sous-réseaux physiquement séparés si l'administrateur les considère comme un même emplacement logique.

Un outil de collecte automatisé type BloodHound remplace-t-il cette phase manuelle de cartographie ?

Ces outils accélèrent la collecte et la visualisation des chemins d'attaque, mais ils ne remplacent pas la compréhension manuelle du contexte : lecture des trusts en termes contractuels, identification des sites faiblement supervisés, ou décision sur le rythme des requêtes. La collecte automatisée est traitée en détail dans le chapitre dédié à BloodHound, plus loin dans la formation.

Comment limiter concrètement le bruit journalisé pendant la cartographie ?

En priorisant les objets à forte valeur avant toute collecte exhaustive, en espaçant les requêtes automatisées plutôt qu'en les envoyant en une seule salve, en évitant les comptes de service partagés pour l'énumération quand un compte dédié à faible impact est disponible, et en documentant chaque action pour pouvoir répondre rapidement si l'équipe défense détecte une activité et interroge le client.

Que faire si la cartographie révèle une configuration DNS avec mises à jour dynamiques non sécurisées ?

C'est une observation à documenter séparément pour le rapport final, car elle constitue un vecteur d'attaque en soi (usurpation ou empoisonnement DNS), mais elle sort du strict périmètre de la cartographie du domaine. Il ne faut pas l'exploiter sans validation explicite du scope, même si l'opportunité technique est immédiate.

Pourquoi documenter les OU Tier 0 a-t-il de l'importance si elles n'existent pas dans l'environnement audité ?

L'absence de séparation Tier 0 est elle-même une information utile : elle indique un niveau de maturité de sécurité relativement faible en matière de tiering d'administration, ce qui alimente directement les recommandations du rapport final, indépendamment de toute technique d'exploitation ultérieure.

Progression sauvegardée dans votre navigateur.

Quiz de validation

Quiz indisponible (données invalides).

Prêt à passer à la pratique ? Audit ou pentest de votre infrastructure — devis gratuit, résultat en 48h.

Devis gratuit