Active Directory : les chemins de compromission qu’on retrouve partout

Dans la quasi-totalité des attaques par rançongiciel qui aboutissent à un chiffrement massif, l’attaquant est passé par l’annuaire. Ce n’est pas un hasard : Active Directory concentre l’authentification, les droits et la distribution de configuration. Le compromettre, c’est obtenir en une fois ce qu’il faudrait sinon arracher machine par machine.

Le point important est que ces compromissions n’exploitent presque jamais une vulnérabilité logicielle inédite. Elles empruntent des chemins ouverts par des décisions d’administration accumulées sur dix ou quinze ans.

Le principe : un graphe, pas une liste

La plupart des organisations évaluent leur annuaire en comptant les membres des groupes d’administration. C’est insuffisant. Ce qui compte n’est pas qui est administrateur, mais qui peut le devenir — en une étape ou en cinq.

Un compte sans privilège apparent qui peut réinitialiser le mot de passe d’un second compte, lequel a un droit d’écriture sur un objet de groupe, lequel contient un troisième compte administrateur local sur un serveur où une session privilégiée est ouverte, est un compte administrateur du domaine. Il l’ignore, et l’équipe qui l’a créé aussi.

C’est la logique du graphe de relations : les outils d’analyse de chemins d’attaque ne découvrent pas des failles, ils rendent visible une transitivité que personne n’avait calculée.

Les cinq chemins les plus fréquents

1. Les sessions privilégiées sur des machines non protégées

Un administrateur du domaine qui ouvre une session sur un poste bureautique ou un serveur applicatif y laisse des éléments d’authentification réutilisables. L’attaquant qui contrôle cette machine les récupère. C’est le chemin le plus court et le plus courant.

La réponse est le cloisonnement par niveaux : les comptes d’administration du domaine ne s’authentifient que sur des machines dédiées à l’administration, jamais sur le parc courant. Microsoft l’a formalisé sous le nom de modèle de niveaux, puis d’Enterprise Access Model. L’ANSSI recommande la même séparation dans son guide sur la sécurisation d’Active Directory.

C’est la mesure la plus efficace et la plus coûteuse organisationnellement, parce qu’elle change les habitudes de travail des équipes d’exploitation.

2. Les comptes de service

Ils cumulent trois défauts : un mot de passe qui ne change jamais, des privilèges souvent excessifs « pour que ça marche », et un attribut qui les rend interrogeables par n’importe quel compte du domaine. Un attaquant authentifié peut demander un ticket pour ces comptes et tenter de casser le secret hors ligne, sans déclencher de blocage de compte.

Les contre-mesures existent et sont sous-utilisées : mots de passe longs et aléatoires, comptes de service gérés dont le secret est renouvelé automatiquement par l’annuaire, et retrait des comptes de service des groupes d’administration — où ils n’ont presque jamais de raison d’être.

3. Les délégations mal maîtrisées

La délégation permet à un service de s’authentifier auprès d’un autre au nom d’un utilisateur. Configurée sans restriction, elle autorise le serveur délégué à se faire passer pour n’importe qui — y compris un administrateur. Ces configurations sont posées lors d’un déploiement applicatif, validées parce que « ça fonctionne », et jamais revues.

Un inventaire des délégations est un exercice court : il tient en une requête sur l’annuaire. Il produit presque toujours des résultats que personne n’assume.

4. Les droits sur les objets

Les listes de contrôle d’accès de l’annuaire sont modifiées à chaque projet, chaque migration, chaque outil qui demande « juste un droit d’écriture ». Au bout de dix ans, des groupes créés pour un usage disparu conservent des droits d’écriture sur des conteneurs sensibles.

Ces droits sont invisibles dans les interfaces d’administration courantes. Ils n’apparaissent que dans une analyse dédiée — et c’est précisément ce que fait un attaquant dans les heures qui suivent son premier accès.

5. Les stratégies de groupe

Une stratégie de groupe est un fichier appliqué par toutes les machines de son périmètre, avec des privilèges système. Qui peut la modifier peut exécuter du code partout où elle s’applique. Les droits de modification sur les GPO sont donc des droits d’administration déguisés, rarement traités comme tels.

Ce qui rend le chantier faisable

Un projet de sécurisation d’annuaire échoue quand il commence par un audit exhaustif dont le rapport fait cent pages. Il réussit quand il est découpé.

• Mesurer d’abord. Cartographier les chemins existants avant de décider quoi que ce soit. Le résultat sert aussi à obtenir l’arbitrage : un chemin en trois étapes d’un compte de stagiaire vers l’administration du domaine est un argument plus efficace qu’une note de synthèse.
• Couper les chemins, pas les symptômes. Supprimer un compte inutile ne sert à rien si la relation qui le rendait dangereux subsiste ailleurs.
• Traiter les sessions privilégiées en premier. C’est le chemin le plus emprunté, et sa fermeture invalide plusieurs autres.
• Réévaluer périodiquement. Un annuaire propre se redégrade en dix-huit mois si aucun contrôle n’est intégré aux processus de projet.

La partie qui n’est pas technique

La plupart des configurations décrites ici ont été posées par des équipes compétentes, sous contrainte de délai, pour faire fonctionner une application. Aucune n’est une faute individuelle. Elles deviennent un risque parce que rien, dans le cycle de vie d’un projet, ne prévoit leur retrait quand le besoin disparaît.

C’est pour ça qu’un durcissement d’annuaire qui ne s’accompagne pas d’un point de contrôle en fin de projet se refait à l’identique trois ans plus tard.

Sources

• ANSSI — Recommandations de sécurité relatives à Active Directory et points de contrôle associés
• ANSSI / CERT-FR — Panorama de la cybermenace, sur le rôle de l’annuaire dans les attaques par rançongiciel
• Microsoft — Enterprise Access Model (modèle de cloisonnement des accès privilégiés)