Ce que les pentesteurs corrigent en priorité : 5 actions de durcissement d’Active Directory (récap du webinaire)

L’IA n’a pas offert aux attaquants de nouvelles portes d’entrée dans Active Directory. Elle a rendu les anciennes moins coûteuses, plus rapides et plus faciles à exploiter à grande échelle. Les corrections que les pentesteurs recommandent depuis des années fonctionnent toujours, et les ignorer est plus risqué qu’auparavant.

C’était le message principal du premier webinaire Authentication Insights, le 14 octobre 2026. Spencer Alessi, pentesteur senior chez SecurIT360 et Microsoft MVP, était l’invité du journaliste cybersécurité John E. Dunn. Ils ont abordé les cinq corrections de durcissement d’Active Directory que Spencer applique en premier, la manière de fixer les priorités, et un test d’intrusion où les défenses ont tenu.

Spencer a ouvert avec une phrase qu’il répète souvent : « On ne peut plus se permettre autant de laisser-aller. » Les ransomwares ont mis à nu les équipes IT qui avaient négligé les fondamentaux. L’IA fait encore monter les enjeux.

Il s’est appuyé sur deux rapports récents.

• Le rapport de threat intelligence d’Anthropic montre des attaquants qui utilisent l’IA pour écrire et réécrire leurs outils, et pour enchaîner découverte et exploitation de vulnérabilités dans des chaînes automatisées. Les outils réécrits ne portent aucune signature connue, si bien que les détections statiques perdent de leur valeur. La détection comportementale compte davantage.

• Le rapport de GreyNoise sur une campagne d’exploitation de PaperCut décrit un groupe russe qui a ciblé environ 500 organisations et obtenu les droits d’administrateur de domaine dans certaines d’entre elles. Aucune des techniques n’était nouvelle : Kerberoasting, abus de certificats, extraction d’identifiants, et outils offensifs bien connus comme Mimikatz, Impacket, NetExec, Certify et Rubeus.

« Quand on parle d’Active Directory, toutes les attaques, tous les abus sont connus, a déclaré Spencer. On sait comment s’en défendre. »

À retenir pour les administrateurs : l’obscurité et l’effort exigé de l’attaquant ne vous protègent plus. Mais les défenses sont les mêmes que celles qui ont toujours fonctionné.

Des outils gratuits comme PingCastle, Purple Knight, Locksmith et ADeleg trouveront de nombreux problèmes. Le plus difficile est de décider par quoi commencer.

« Si vous avez un rapport avec 20 vulnérabilités, vous ne pouvez pas toutes les corriger », a souligné Spencer.

Il les classe à l’aide de quatre questions, qu’il appelle le modèle P.R.I.D. :

• Privilèges : que peut faire un attaquant ?

• Portée (Reach) : où peut-il aller ?

• Impact : quelle serait la gravité ?

• Détection : le verriez-vous ?

L’objectif est d’augmenter le coût d’une attaque. Une vulnérabilité avec des privilèges étendus, une large portée, un fort impact et peu de chances d’être détectée passe en tête de liste.

Les privilèges méritent une attention particulière. Dans Active Directory, chaque objet a des permissions, et AD n’émet aucun avertissement quand vous en accordez une dangereuse. La plupart des environnements comportent des permissions dangereuses que personne ne connaît.

Spencer conseille de documenter votre modèle d’accès, par service et par rôle ou par application, et de tracer chaque modification.

Lors d’un test d’intrusion, il a trouvé le groupe Everyone avec un contrôle total sur la racine du domaine. Personne dans l’équipe IT ne savait quand ni comment ce réglage avait été appliqué, ni si c’était l’œuvre d’un attaquant. Sans historique, personne ne pouvait dire si le révoquer casserait quelque chose.

Spencer choisit des corrections à fort impact, à faible risque de casse, et qui offrent le plus de protection par heure de travail. Trois sont des gains rapides qui prennent de quelques heures à quelques jours. Deux sont des projets plus longs.

1. Déployer LAPS (gain rapide)

Windows LAPS rend aléatoire le mot de passe de l’administrateur local sur chaque machine. Un poste de travail compromis ne livre plus à l’attaquant un mot de passe partagé pour se déplacer sur le réseau. LAPS est intégré à Windows, Active Directory et Intune. Son déploiement prend quelques heures dans une petite organisation, et de quelques jours à deux semaines dans une grande.

Spencer constate moins souvent qu’avant des droits d’administrateur local partagés. Ils restent courants dans l’enseignement, où le personnel reçoit des droits d’administrateur local pour installer des logiciels.

2. Auditer et corriger les modèles de certificats (gain rapide)

Les modèles mal configurés d’Active Directory Certificate Services (AD CS) font partie des chemins d’attaque que Spencer rencontre le plus souvent lors de tests d’intrusion internes. Beaucoup d’équipes ne savent même pas qu’elles utilisent AD CS, parce qu’un MSP ou un éditeur l’a installé puis est parti. Certains logiciels d’éditeurs exigent même, par conception, des paramètres de modèles non sécurisés.

Lancez Locksmith, un outil PowerShell gratuit développé par Jake Hildreth. Il recherche les mauvaises configurations AD CS connues, explique chaque risque et, pour de nombreux problèmes, fournit un extrait PowerShell pour le corriger. Relisez ces extraits avant de les exécuter. Commencez par ESC1, ESC2, ESC4 et ESC8, les plus dangereux.

Spencer recommande de lancer Locksmith après chaque modification d’AD CS et une fois par trimestre.

3. Corriger les permissions dangereuses (gain rapide)

La méthode de Spencer fonctionne quel que soit le niveau de compétence : chercher les groupes dangereux disposant de permissions dangereuses sur des ressources privilégiées.

• Groupes dangereux : Domain Users, Authenticated Users, Domain Computers, Everyone, et des groupes non administrateurs comme Comptabilité ou Ventes.

• Permissions dangereuses : contrôle total, changement de propriétaire, création et suppression d’objets, et autres droits similaires, normaux pour des administrateurs mais pas pour les autres.

• Ressources privilégiées : le Tier 0, c’est-à-dire les contrôleurs de domaine, l’OU Domain Controllers, Domain Admins et Enterprise Admins.

Commencez par le Tier 0 et élargissez progressivement. ADeleg liste toutes les délégations non par défaut du domaine, et ADeleginator automatise la recherche des délégations à risque. Le visualiseur de permissions de NetTools affiche les permissions dangereuses en rouge.

HardenAD, une boîte à outils PowerShell open source, permet aussi d’automatiser la détection des mauvaises configurations d’AD et aide à mettre en œuvre des modèles de délégation par tiers (ESAE) pour bloquer l’élévation de privilèges.

4. Verrouiller les comptes de service (projet plus long)

Les comptes de service aident les attaquants à se déplacer latéralement et à se maintenir dans un environnement. Les priorités de Spencer :

• Des mots de passe longs et uniques, qui ne sont pas stockés dans des fichiers web.config ou des scripts.

• Le moindre privilège. Un compte de service SQL ne devrait jamais être membre de Domain Admins, et le compte Administrateur intégré ne devrait jamais exécuter un service.

• Moins de SPN. Auditez les noms de principal de service et supprimez ceux dont vous n’avez pas besoin pour réduire le risque de Kerberoasting.

• Une appartenance aux groupes restreinte. Les comptes de service administrés de groupe (gMSA) suppriment une grande partie de la gestion des mots de passe. Cartographiez les dépendances avant toute modification, car les changements sur les comptes de service peuvent casser des applications.

5. Supprimer progressivement NTLM (projet plus long)

NTLM survit en partie parce que des produits tiers, des plateformes de virtualisation aux baies de stockage en passant par les pare-feu, en dépendent encore. Selon Spencer, les éditeurs partagent avec Microsoft la responsabilité de mettre à jour leurs logiciels.

Traitez-le comme un projet de long terme. Partez du niveau d’authentification LAN Manager 3, la valeur par défaut. Passez ensuite aux niveaux 4 et 5 sur les postes de travail, puis sur les serveurs, puis sur les contrôleurs de domaine. Auditez l’utilisation de NTLM avant chaque étape.

Pour chaque correction de la liste, la règle de Spencer est la même : ne jamais activer un changement partout d’un coup. Commencez par un groupe de machines de test et quelques utilisateurs avancés. Avancez service par service, puis passez aux serveurs. Procéder par petites étapes garde le travail gérable et protège la crédibilité de l’équipe IT.

Il l’a appris tôt. Jeune administrateur sécurité, il a désinstallé un composant obsolète, Microsoft XML 4.0, d’un serveur d’applications. Dix minutes plus tard, l’administrateur de l’application l’informait que toute l’entreprise était à l’arrêt.

La leçon n’est pas d’éviter le changement. « Parfois, il faut que les choses cassent pour savoir quoi réparer », a dit Spencer. Cassez-les volontairement, avec de la documentation et un plan de retour arrière.

La partie la plus difficile n’est souvent pas technique. Spencer voit de nombreuses équipes qui veulent durcir leur environnement mais butent sur la direction, sur les dynamiques d’équipe, ou sur un administrateur qui refuse un compte d’administration séparé et la MFA.

« La technique, c’est facile, a-t-il déclaré. Travailler avec le métier, tester, déployer les changements, communiquer, c’est ça le plus dur. »

Spencer a conclu avec un test d’intrusion qui montre que le durcissement fonctionne. Un cabinet d’avocats lui a demandé de tester des attaques basées sur l’identité : pass-the-hash, pass-the-ticket, silver tickets et golden tickets. Le cabinet lui a fourni un identifiant d’administrateur de domaine sur une machine jointe au domaine. Dans la plupart des environnements, c’est le pire scénario.

Toutes les attaques ont échoué. L’outil tiers de protection des identités du cabinet a tenu.

Le cabinet a alors tenté autre chose. Il a retiré l’outil tiers pour ne s’appuyer que sur les fonctionnalités natives de Windows et d’Active Directory : Protected Users, restrictions de connexion, stratégies d’authentification et pare-feu Windows. Les défenses ont encore tenu. Même avec des identifiants d’administrateur de domaine, Spencer n’a pas pu quitter le premier poste.

« [Dans] Active Directory, même s’il a 26 ans, les fonctionnalités sont là pour bien le défendre, a-t-il expliqué. Il faut juste travailler un peu plus. »

Il l’a comparé à la rénovation d’une salle de bains. Vous pouvez la faire vous-même, ce qui prend plus de temps mais vous apprend le métier, ou faire appel à un artisan. Les équipes qui peinent à garder la maîtrise de leur environnement iront peut-être plus loin, plus vite, avec un outil tiers. Celles qui ont le temps et les compétences peuvent le faire elles-mêmes. Beaucoup combinent les deux.