Sécuriser un Active Directory : un modèle connu, une pratique rare

J’ai assisté la semaine dernière à une session du CLUSIR Auvergne-Rhône-Alpes sur la sécurisation de l’Active Directory. Trois intervenants, trois angles : la théorie du cloisonnement par un consultant, l’attaque par un pentester qui passe admin du domaine en une heure, et le retour d’expérience d’un RSSI qui a déployé tout ça dans un groupe industriel. Le format est rare et il vaut le détour, parce qu’on entend trop souvent l’un de ces trois discours sans les deux autres.

Ce qui m’a accroché, c’est que je connaissais déjà une bonne partie de la première et de la deuxième parties. Pendant ma formation, j’ai eu à mener un test d’intrusion sur un AD, du compte utilisateur lambda jusqu’au contrôleur de domaine. Donc en écoutant le pentester dérouler sa kill chain, je n’ai pas découvert les techniques. J’ai surtout réentendu, dans la bouche de quelqu’un qui le fait dix fois par an chez des clients, à quel point c’est mécanique. Le reste du webinaire, la défense et le retour terrain, m’a surtout montré pourquoi si peu d’entreprises s’en protègent vraiment.

Un modèle vieux de plusieurs années, et pourtant l’exception

Le cœur de la partie théorique, c’est le tiering. L’idée tient en une phrase : on découpe l’annuaire en trois niveaux de confiance. Le Tier 0 contient le noyau critique (les contrôleurs de domaine, la PKI, les serveurs de sauvegarde, Azure AD Connect, tout ce qui peut compromettre l’AD). Le Tier 1, les serveurs applicatifs métier. Le Tier 2, les postes utilisateurs et les imprimantes. La règle qui fait tout tenir est simple : on interdit qu’un compte d’un niveau bas se connecte à un niveau plus haut. Pas de remontée, donc pas d’escalade.

Ce qui m’a surpris, c’est que ce modèle n’a rien de nouveau. Microsoft le pousse depuis des années. Et pourtant, en salle, il a été présenté comme l’exception plutôt que la règle. La plupart des entreprises commencent à peine à s’y mettre.

J’ai compris pourquoi en écoutant les questions de la salle et le RETEX. Le tiering n’est pas un produit qu’on installe. C’est un changement d’organisation. Un administrateur qui touchait les trois niveaux avec un seul compte se retrouve avec trois comptes et trois postes dédiés. Des flux qui marchaient depuis dix ans cassent du jour au lendemain parce qu’une tâche planifiée oubliée se connecte là où elle n’a plus le droit. La réticence que j’entendais autour de moi n’est pas de la paresse. Recréer des comptes, redéployer des GPO, ré-éduquer les équipes, ça coûte du temps et ça touche des gens qui n’ont pas demandé à changer leurs habitudes. Le coût est réel et il tombe sur l’exploitation quotidienne.

Pourquoi l’attaque va si vite

La partie offensive m’a confirmé une chose que mon projet de formation m’avait déjà fait sentir : la rapidité de l’attaque tient moins au talent de l’attaquant qu’à l’absence d’architecture.

Le pentester arrive sur le réseau, lance un outil d’écoute, et attend que les postes se trompent de chemin de résolution de noms. Des protocoles de secours comme LLMNR ou NBT-NS, encore actifs par défaut, lui font tomber une empreinte d’authentification dans les mains. À partir de là, soit il la casse si le mot de passe est faible, soit il la relaie vers une machine qui n’a pas activé la signature SMB. Ajoutez un service de certificats mal configuré (le fameux ADCS, où une simple case cochée transforme un compte utilisateur en administrateur du domaine) et la chaîne se boucle en quelques commandes. BloodHound fait le reste : il cartographie les relations cachées de l’annuaire et trace le chemin le plus court vers un compte privilégié.

Aucune de ces attaques n’est un exploit sophistiqué. Chacune exploite soit un protocole legacy qu’on a laissé allumé, soit un compte qui peut se connecter là où il ne devrait pas. C’est exactement ce que le tiering vient empêcher. La défense n’est pas un antivirus ou une sonde de plus, c’est une décision d’architecture : qui a le droit de parler à qui. Pour quelqu’un qui vient de la donnée comme moi, ça résonne. En BI, on raisonne en moindre privilège sur les jeux de données, en cloisonnement par rôle, en sécurité au niveau des lignes. Le tiering, c’est la même logique appliquée à l’identité plutôt qu’à la table de faits.

Un détail défensif qui mérite d’être noté au passage : lancer BloodHound sur son propre annuaire n’est pas un risque, c’est même recommandé par l’ANSSI pour auditer ses chemins de contrôle. La nuance donnée en salle est qu’on le fait depuis un poste et un compte dédiés, pour ne pas déclencher le SOC ni récupérer une dépendance corrompue trouvée sur GitHub. L’outil offensif devient un instrument d’audit.

Là où ça coince vraiment : le legacy industriel

Le retour d’expérience était la partie la plus instructive, et la plus alignée avec ce qui m’intéresse. Le RSSI parlait d’un groupe industriel d’environ mille utilisateurs. Son chantier de durcissement a pris un an, à deux personnes côté sécurité. Et il a beaucoup insisté sur un point : ce n’était pas tant de la charge que du délai. Pour tenir un projet aussi long avec peu de visibilité, il s’appuyait sur un score de sécurité présenté chaque mois au management. Un chiffre que la direction comprend, qui justifie le budget et qui matérialise le risque qu’on réduit, là où une liste de protocoles désactivés ne parle à personne en COMEX.

Le vrai obstacle, c’est le legacy industriel. Des postes sous Windows XP qui pilotent encore des automates, parce que les outils de développement de ces automates ne tournent pas sur du Windows récent et que remplacer un automate, c’est un budget colossal et quinze à vingt ans de durée de vie. Ces vieux postes traînent du SMBv1 et du NTLMv1 derrière eux, des protocoles dont on sait casser les empreintes très facilement. Et il suffit qu’un seul serveur accepte ces vieux protocoles pour rouvrir la porte à toute la boîte. La segmentation réseau du monde industriel (le modèle Purdue, qui empile les automates en bas et la supervision plus haut) ajoute encore une couche de contraintes.

Sa phrase qui m’est restée : un tiering à moitié fait ne sert à rien. Un prestataire lui avait livré de belles unités d’organisation par niveau, mais avait laissé trente pour cent des serveurs dans un dossier non classé. Résultat, le cloisonnement était décoratif. Il suffit d’une machine mal rangée pour casser tout l’édifice. C’est exactement le genre de détail qu’on ne voit pas dans un schéma PowerPoint propre, et qu’on paie en production.

Cette difficulté n’est pas un cas d’école savoyard. C’est précisément ce que NIS2 va demander aux sous-traitants industriels de la région, et la mention en passant de l’ouverture possible de l’outil ORADAD de l’ANSSI aux entités assujetties va dans ce sens. Le legacy tient à l’argent et à la continuité de production, pas à un manque de discipline.

Ce que j’en retiens

Ce qui me reste de ce webinaire, c’est surtout une conviction. Le tiering n’est pas une option de confort réservée aux grandes structures, c’est la réponse architecturale directe à ce que le pentester déroulait sous nos yeux. Dès qu’on peut le mettre en place, on devrait le faire. Le reste, c’est de l’arbitrage entre un coût d’exploitation bien réel et un risque qu’on a tendance à sous-estimer tant qu’on ne l’a pas vu se matérialiser.

Je comprends mieux la réticence, maintenant. Elle a ses raisons : recréer des comptes, redéployer des GPO, composer avec vingt ans de legacy industriel, ça pèse lourd sur des équipes déjà chargées. Mais l’écouter sans jamais la trancher, c’est laisser ouverte la porte que le pentester franchit en une heure.

Et puis il y a ce constat qui me suit depuis ma formation : le mois où j’ai attaqué un AD m’a appris plus sur la manière de le défendre que beaucoup de lectures théoriques. Voir un système tomber, c’est comprendre où il faut le tenir.

Une précision pour finir. Je n’invente rien : je retrace les propos tenus pendant cette session du CLUSIR ARA, tels que je les ai perçus et notés. Ce que vous pouvez lire est ma lecture de l’intervention, agrémentée de ma propre vision et de mon parcours. Les éléments techniques (outils, configurations ADCS, modèle Purdue) viennent des présentations des intervenants.