Énumération LDAP et SMB

Pourquoi l'énumération conditionne toute la suite

Dans un engagement Active Directory, la phase d'énumération n'est pas une formalité avant l'exploitation : c'est elle qui détermine si vous trouvez un chemin d'escalade en deux heures ou en deux semaines. LDAP et SMB sont les deux protocoles qui exposent le plus d'informations exploitables sur un domaine Windows, souvent avant même d'avoir obtenu des identifiants valides. Un contrôleur de domaine mal durci laisse filtrer via LDAP la structure complète de l'annuaire — utilisateurs, groupes, unités d'organisation, ACL, relations de délégation — et via SMB l'accès à des partages qui contiennent fréquemment des scripts de connexion, des fichiers de configuration ou des sauvegardes oubliées.

Ce chapitre couvre l'énumération non authentifiée et faiblement authentifiée : session nulle, compte invité, et le cas le plus fréquent en mission réelle, un compte utilisateur standard obtenu par phishing, par un mot de passe faible ou fourni directement par le client en mode assumed breach. L'objectif n'est pas seulement de lister des objets : c'est de transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire une liste brute d'utilisateurs et de partages en une hypothèse de chemin d'attaque testable, avant même d'avoir lancé le moindre outil d'exploitation.

Deux protocoles, deux logiques différentes. LDAP donne une vue structurelle de l'annuaire — qui existe, qui appartient à quoi, qui peut modifier quoi. SMB donne une vue opérationnelle — ce que les administrateurs et les utilisateurs ont concrètement déposé, scripté ou oublié sur le réseau. Les deux se complètent : une ACL LDAP indique qu'un compte peut modifier une GPO, un partage SMB accessible en écriture montre parfois que cette même GPO pointe vers un script que vous pouvez altérer directement.

La majorité des missions actuelles démarrent avec un compte utilisateur standard plutôt qu'en boîte noire totale. C'est le scénario le plus représentatif d'une intrusion réelle : un attaquant obtient presque toujours un accès initial modeste avant de chercher à escalader. Calibrez votre méthodologie d'énumération sur ce cas, pas sur l'hypothèse optimiste d'un accès administrateur.

Session nulle et compte invité : ce qui reste exploitable

Historiquement, la session nulle (anonymous logon) permettait d'énumérer sans identifiant la quasi-totalité d'un domaine Windows NT/2000. Depuis Windows Server 2003, RestrictAnonymous est activé par défaut et limite fortement cette exposition. Mais « par défaut » ne veut pas dire « toujours » : environnements hérités, migrations incomplètes, GPO mal appliquées ou domaines de test promus en production laissent encore des sessions nulles fonctionnelles.

Le test coûte quelques secondes et doit être systématique en début de mission :

smbclient -L //10.10.10.10 -N
rpcclient -U "" -N 10.10.10.10
ldapsearch -x -H ldap://10.10.10.10 -s base

Si la session nulle répond, rpcclient seul permet déjà de lister les utilisateurs (enumdomusers), les groupes (enumdomgroups) et la politique de mot de passe (getdompwinfo) — de quoi préparer un password spraying ciblé sans avoir touché un seul identifiant.

Beaucoup de testeurs sautent ce test parce qu'ils considèrent le null session comme obsolète depuis quinze ans. C'est une erreur qui coûte cher : sur un parc de plusieurs milliers de postes et plusieurs domaines enfants, il suffit d'un seul contrôleur mal configuré pour rouvrir la fenêtre. Le test étant gratuit en temps et en bruit, il n'y a aucune raison de l'omettre.

Interroger LDAP : de la racine à l'arborescence complète

LDAP est le protocole natif de l'annuaire Active Directory ; c'est par lui que transitent la quasi-totalité des lectures effectuées par les contrôleurs de domaine eux-mêmes, ce qui en fait la source la plus riche et la plus structurée. La première étape consiste à interroger le RootDSE, qui ne nécessite aucune authentification et révèle le ou les naming contexts (base DN, configuration, schéma) :

ldapsearch -x -H ldap://dc01.corp.local -s base namingcontexts

Une fois le base DN connu (par exemple DC=corp,DC=local), un bind anonyme ou avec un compte low-priv permet de parcourir l'annuaire avec des filtres LDAP ciblés. Les outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire manuels (ldapsearch, windapsearch) conviennent pour des requêtes précises ; pour une collecte exhaustive, ldapdomaindump ou bloodhound-python (BloodHound.py) produisent directement des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire exploitables hors ligne.

ldapsearch -x -H ldap://dc01.corp.local -D "corp\\jdupont" -w 'MotDePasse!' \
  -b "DC=corp,DC=local" "(&(objectCategory=person)(admincount=1))" sAMAccountName

Ce filtre remonte les comptes ayant hérité un jour de droits privilégiés — y compris ceux dont l'appartenance au groupe Domain Admins a été retirée sans que le flag adminCount soit nettoyé. Ce sont souvent des cibles négligées par les équipes défensives.

Quand le temps de mission est compté, préférez bloodhound-python -u user -p pass -d corp.local -ns 10.10.10.10 -c All à une série de requêtes ldapsearch manuelles. La collecte automatisée couvre les ACL, les sessions, les appartenances et les délégations en une seule passe, et alimente directement l'analyse graphique.

Un point souvent négligé : le port utilisé change ce que vous pouvez observer. Le port 389 transporte du LDAP en clair, éventuellement signé ; le port 636 transporte du LDAPS, chiffré via TLSTLSRéseauxProtocole cryptographique assurant confidentialité et intégrité des communications applicatives (notamment HTTPS).Voir dans le glossaire. Depuis les correctifs liés à la vulnérabilité de relais NTLM sur LDAP (2023), de plus en plus de domaines imposent la signature LDAP et le channel binding sur LDAPS, ce qui bloque certains outils de relais mais n'affecte pas l'énumération en lecture simple. Vérifiez systématiquement les deux portsportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire : un contrôleur peut répondre différemment selon que la connexion est signée ou non, et l'écart lui-même est une information à consigner pour la partie relais du rapport.

ACL : le véritable trésor de l'énumération LDAP

Chaque objet AD porte une DACL (liste de contrôle d'accès discrétionnaire) composée d'ACE qui définissent qui peut faire quoi sur cet objet précis. C'est souvent là, plutôt que dans une appartenance de groupe visible, que se cache le chemin d'escalade : un utilisateur standard disposant de GenericAll sur un compte de service, de WriteDACL sur une OU, ou de GenericWrite sur un objet GPO peut obtenir un contrôle total sans jamais toucher à un mot de passe administrateur.

Les droits à surveiller en priorité :

• GenericAll — contrôle total sur l'objet (reset de mot de passe, ajout à un groupe, etc.)
• GenericWrite — modification d'attributs, y compris scriptPath ou le contenu d'une GPO liée
• WriteDACL — possibilité de s'octroyer soi-même n'importe quel autre droit sur l'objet
• WriteOwner — prise de possession de l'objet, puis modification libre de sa DACL
• ForceChangePassword — réinitialisation du mot de passe d'un compte cible sans le connaître
• AddMember — ajout à un groupe, y compris un groupe privilégié mal surveillé

SharpHound (côté Windows) et BloodHound.py (Linux) collectent ces ACE et les injectent dans un graphe Neo4j exploré ensuite via l'interface BloodHound. Le graphe révèle des chemins qu'aucune lecture manuelle de l'annuaire ne ferait apparaître de façon fiable, en particulier quand l'escalade nécessite d'enchaîner trois ou quatre relations distinctes.

SMB : partages, permissions effectives et fichiers sensibles

SMB expose un autre type d'information : ce que les utilisateurs ont réellement écrit et laissé traîner. smbclient -L et smbmap -H listent les partages accessibles ; crackmapexec smb <cible> -u user -p pass --shares (ou son successeur netexec) ajoute directement les droits de lecture/écriture effectifs par partage, ce qui évite de perdre du temps sur des partages visibles mais inaccessibles.

Trois partages méritent une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire systématique :

• SYSVOL et NETLOGON — répliqués sur tous les contrôleurs de domaine, ils contiennent scripts de connexion, GPO et parfois des identifiants codés en dur dans un .bat ou un .vbs oublié
• Partages métier ouverts en écriture pour "Utilisateurs authentifiés" — souvent le résultat d'une configuration initiale jamais resserrée
• Partages administratifs (C$, ADMIN$) — accessibles seulement avec des droits élevés, mais leur seule accessibilité en dit long sur le niveau de compte obtenu

smbmap -H 10.10.10.10 -u jdupont -p 'MotDePasse!'
crackmapexec smb 10.10.10.10 -u jdupont -p 'MotDePasse!' --shares
smbclient //10.10.10.10/NETLOGON -U jdupont

Une fois un partage accessible en lecture, une recherche ciblée sur les extensions à risque (.xml, .ps1, .bat, .vbs, .config, .kdbx) est plus rentable qu'une exploration manuelle exhaustive. Sur un grand nombre de partages, monter les volumes en local (mount -t cifs ou un client SMB en mode script) puis lancer une recherche récursive avec grep -ril sur des motifs comme password, pwd= ou identifiant reste souvent plus rapide que n'importe quel outil dédié, à condition de garder une trace précise de chaque fichier ouvert pour la traçabilité de mission. Des outils spécialisés comme snaffler automatisent cette recherche en appliquant des règles de scoring sur le contenu et les noms de fichiers, ce qui aide à prioriser sur un partage de plusieurs dizaines de milliers de fichiers.

Avant le correctif MS14-025, les GPO Preferences pouvaient stocker des identifiants (comptes de service, mappages de lecteurs, tâches planifiées) chiffrés en AES dans un fichier Groups.xml sous SYSVOL — avec une clé AES statique publiée par Microsoft et donc triviale à inverser. Le correctif bloque la création de nouvelles GPP avec mot de passe, mais ne supprime pas les fichiers déjà déployés. Cherchez systématiquement cpassword dans l'arborescence SYSVOL ; sa présence, même dans une GPO ancienne et non appliquée, reste une vulnérabilité active tant que le fichier existe.

OPSEC pendant l'énumération

Contrairement à une idée répandue, l'énumération n'est pas une phase silencieuse. Chaque bind LDAP, chaque connexion SMB génère des événements dans les journaux Windows — 4624 (ouverture de session), 4661 (accès à un objet), 5140 (accès à un partage réseau) — et une collecte SharpHound en mode All produit un volume de requêtes LDAP qui constitue une signature reconnue par Microsoft Defender for Identity et par la plupart des EDR modernes.

Quelques réflexes limitent l'empreinte sans sacrifier la qualité de la collecte :

• Préférer un compte authentifié low-priv à des sessions nulles répétées, moins bruyantes statistiquement et plus cohérentes avec un usage légitime
• Cibler la collecte (-c DCOnly ou des méthodes spécifiques) plutôt que systématiquement All, surtout en présence de Microsoft Defender for Identity
• Espacer les requêtes de reconnaissance plutôt que de saturer le contrôleur de domaine en quelques secondes
• Se méfier des comptes honeypot (honeytokens) : un compte visiblement privilégié mais jamais utilisé en production est souvent un piège de détection déposé par l'équipe défensive

Le rythme d'exécution compte autant que le volume de requêtes. Un scan qui interroge chaque attribut de chaque objet en quelques secondes produit un pic statistique facile à corréler, même sans règle de détection dédiée à BloodHound ; le même volume de requêtes réparti sur plusieurs heures, mêlé à un usage légitime du compte, se fond beaucoup mieux dans le bruit de fond. Sur les missions où la furtivité est un objectif explicite du client, discutez en amont avec l'équipe défensive de la fenêtre de tolérance acceptée plutôt que de découvrir en cours de test qu'un SOC a déclenché une procédure de crise sur la base de votre collecte.

Un client mature ne se contente pas d'un rapport de vulnérabilités : il veut savoir si son SOC aurait dû détecter votre passage. Consignez précisément quelles commandes ont généré quels types d'événements, à quelle heure, depuis quelle IP. Cette traçabilité alimente directement l'exercice de purple teaming qui suit souvent un test d'intrusion AD.

Ce qu'il faut consigner pour le rapport

L'énumération produit des données qui n'ont de valeur que si elles sont correctement documentées et priorisées. Pour chaque cible, notez au minimum : l'état des sessions nulles/invitées, les ACE dangereuses identifiées et sur quels objets, les partages accessibles avec leur niveau de droit effectif, la présence de cpassword ou d'identifiants en clair, ainsi que la liste des comptes Kerberoastables et AS-REP roastables repérés via LDAP. Ces éléments seront repris et exploités dans les chapitres suivants consacrés au roasting et aux mouvements latéraux ; les documenter au fil de l'eau évite de devoir tout recollecter en fin de mission.

Checklist opérationnelle

• Tester la session nulle sur 445 et le bind anonyme sur 389
• Récupérer le base DN via le RootDSE
• Énumérer utilisateurs, groupes et OU via LDAP
• Lancer une collecte BloodHound ciblée et analyser les ACE critiques
• Lister les partages SMB accessibles et leurs droits effectifs
• Fouiller SYSVOL/NETLOGON à la recherche de cpassword et de scripts sensibles
• Repérer les comptes Kerberoastables et AS-REP roastables via LDAP
• Consigner les événements de sécurité générés par chaque étape