Énumérer un environnement Active Directory : voir les chemins

Un annuaire de 5 000 comptes ne se lit pas comme une liste de courses. L'énumération est l'étape qui transforme ce volume d'informations en une carte lisible. Dans cette leçon, vous comprenez ce que l'on cherche, pourquoi la représentation en graphe est devenue la norme, et comment les défenseurs utilisent exactement les mêmes méthodes pour se protéger.

Énumérer, c'est faire l'inventaire

Dans la méthodologie d'un test d'intrusion, l'énumération suit la reconnaissance. On ne cherche pas encore à entrer : on cherche à comprendre ce qui existe. Dans un annuaire, on veut savoir :

• quels comptes existent, lesquels sont privilégiés, lesquels sont anciens ou inactifs ;
• quels groupes existent et qui en est membre, y compris par imbrication ;
• quels ordinateurs sont enregistrés, quels systèmes ils utilisent, qui y est administrateur ;
• quelles stratégies de groupe s'appliquent et à quoi ;
• quelles approbations et délégations sont configurées.

Pensez à un inspecteur qui visite un grand bâtiment avant d'évaluer sa sécurité : il relève les portes, les badges, les couloirs, les clés qui ouvrent plusieurs pièces. Il ne force aucune serrure pour autant.

Pourquoi c'est possible avec un compte ordinaire

Comme nous l'avons vu, l'annuaire est conçu pour être interrogé par tous les comptes authentifiés. Il utilise pour cela le protocole LDAP, un protocole d'interrogation d'annuaire. Un simple utilisateur peut donc obtenir une partie importante de la structure de l'organisation. Ce n'est pas un défaut de configuration : c'est un compromis entre fonctionnalité et confidentialité, et c'est ce qui rend l'énumération très rentable pour qui a obtenu un premier accès.

Pour le défenseur, la conséquence est claire : partez du principe que n'importe quel compte compromis permettra de cartographier l'annuaire. La protection ne consiste donc pas à cacher l'inventaire, mais à s'assurer que même en le connaissant, il n'existe pas de chemin facile vers les comptes privilégiés.

Du tableau au graphe

Pendant longtemps, l'inventaire se faisait avec des listes : exports de comptes, de groupes, de machines. Le problème est que la dangerosité d'une situation ne se lit pas dans une liste, mais dans les relations entre les éléments. Par exemple :

• Le compte de Camille est membre du groupe Support.
• Le groupe Support est administrateur local des postes du service comptable.
• Sur l'un de ces postes, une session ouverte appartient à un administrateur de domaine.

Chaque phrase, prise seule, paraît anodine. Mises bout à bout, elles forment un chemin de Camille vers un compte tout-puissant. Une liste ne le montre pas ; un graphe le montre immédiatement. Dans un graphe, les éléments (comptes, groupes, machines) sont des nœuds et les relations (« est membre de », « est administrateur de », « a une session sur ») sont des arêtes. Trouver un chemin d'attaque revient alors à chercher un chemin entre deux nœuds, ce qu'un algorithme fait en quelques instants.

Des outils de ce type existent, BloodHound étant le plus connu : il collecte des informations d'annuaire, les stocke sous forme de graphe et permet de poser des questions comme « quel est le chemin le plus court depuis ce compte vers le groupe des administrateurs du domaine ? ». Nous ne détaillerons pas leur utilisation offensive. Retenez le principe : ce sont des outils de visualisation et d'analyse, utilisés aussi bien par les auditeurs que par les équipes de défense.

Un même outil, deux usages

La force de l'approche graphe est qu'elle sert les deux camps :

Couper un chemin est souvent simple une fois qu'il est visible : retirer un groupe d'une liste d'administrateurs locaux, interdire aux comptes d'administration de se connecter aux postes ordinaires, supprimer un droit hérité d'une ancienne organisation. Le coût est faible, le gain de sécurité est élevé.

Un exemple de lecture défensive, dans votre laboratoire

Dans un annuaire de laboratoire que vous administrez, des commandes d'administration standard, en lecture seule, permettent de dresser un premier inventaire. Voici un exemple pédagogique à lancer sur un contrôleur de domaine de laboratoire, avec le module d'administration d'annuaire de PowerShell :

# Lister les membres du groupe des administrateurs du domaine (laboratoire)
Get-ADGroupMember -Identity "Admins du domaine" | Select-Object Name, SamAccountName

# Repérer les comptes dont le mot de passe n'expire jamais
Get-ADUser -Filter 'PasswordNeverExpires -eq $true' | Select-Object Name

Ces commandes sont celles d'un administrateur qui fait son ménage. Elles montrent que la frontière entre administration et énumération est une question d'autorisation, pas de technique. Dans un vrai audit, vous disposez d'une lettre de mission qui précise qui autorise quoi, et sur quel périmètre.

Ce que l'on retient dans un rapport

Énumérer n'est pas une fin en soi. Un bon auditeur ne remet pas un export de 20 000 lignes : il remet des constats hiérarchisés. Par exemple :

• « Sept comptes de service disposent de droits d'administration sur des serveurs sans nécessité apparente. »
• « Le groupe Support est administrateur local de 400 postes, dont ceux de la direction. » (chiffres fictifs, donnés à titre d'illustration)
• « Des comptes inactifs depuis longtemps restent membres de groupes privilégiés. »

Chaque constat décrit une situation, un risque, et une recommandation. Nous reviendrons sur cette structure dans le chapitre consacré au rapport.

À vous de jouer

Exercice sur papier, à intégrer à votre portfolio. Voici les relations d'un petit annuaire fictif :

• Camille est membre de Support.
• Hugo est membre de Comptabilité.
• Support est administrateur local de PC-COMPTA-01.
• Sur PC-COMPTA-01, une session est ouverte par le compte adm-nadia.
• adm-nadia est membre du groupe Admins du domaine.
• Hugo est administrateur local de son propre poste, PC-COMPTA-02.

Dessinez le graphe et trouvez le chemin le plus court de Camille vers Admins du domaine. Proposez ensuite une seule modification qui supprime ce chemin sans gêner le travail du service.