Une simple délégation oubliée sur un objet ordinateur peut suffire à exposer le mot de passe administrateur local géré par LAPS, et ouvrir la voie à une élévation de privilèges silencieuse. Ces dérives ne déclenchent aucune alerte, n’apparaissent pas au niveau des unités d’organisation (OU) et échappent bien souvent aux outils d’audit classiques. Pourtant, dans un domaine Active Directory, il suffit d’un droit de lecture accordé au mauvais compte pour transformer une protection en porte d’entrée.

Ce constat m’a été remonté à la suite de plusieurs échanges avec Alain Cuisenier, ingénieur en sécurité Active Directory. Ces discussions ont mis en évidence un besoin concret : mieux auditer les délégations liées à Microsoft LAPS afin d’identifier des expositions invisibles. Dans cet article, nous allons voir comment ces failles apparaissent, pourquoi elles restent difficiles à repérer, comment les détecter avec un module PowerShell open source dédié (LegacyLapsAudit), puis comment les corriger.

L’essentiel en bref

L’audit des délégations LAPS consiste à vérifier quels comptes disposent réellement d’un droit de lecture sur l’attribut (le mot de passe administrateur local, stocké en clair par LAPS Legacy). Le risque principal vient des droits appliqués directement sur un objet ordinateur plutôt qu’hérités d’une OU : ils n’apparaissent pas dans la vue des délégations d’OU et échappent aux modules PowerShell LAPS.

Un compte disposant d’un droit , ou sur cet attribut peut lire le mot de passe local et obtenir un accès administrateur sur la machine. Pour les détecter, il faut comparer les ACL réelles de chaque objet ordinateur aux délégations légitimes définies au niveau des OU, puis migrer vers Windows LAPS (LAPS2), qui chiffre les mots de passe et ne repose plus uniquement sur des ACL.

Comprendre le risque

Même avec des mesures de sécurité en place, des audits réguliers ou des campagnes de pentest, une simple erreur de délégation peut suffire à fragiliser une infrastructure Active Directory, voire à la compromettre. Ce type de dérive reste silencieux et difficile à détecter avec les outils d’audit classiques, car il ne modifie ni la configuration des GPO ni les délégations visibles au niveau des OU.

Rappel : qu’est-ce que Microsoft LAPS (Legacy) ?

Microsoft LAPS, également appelé LAPS Legacy ou LAPS1, permet de renouveler automatiquement le mot de passe du compte administrateur local des machines jointes à un domaine Active Directory. Chaque machine dispose ainsi d’un mot de passe unique et régulièrement renouvelé, ce qui limite fortement les mouvements latéraux par réutilisation de mot de passe.

Lors du déploiement de la solution, Active Directory ajoute et réplique deux attributs principaux dans l’annuaire : , qui stocke le mot de passe local en clair, et , qui contient la date d’expiration. Ce fonctionnement peut surprendre, mais l’accès à ces attributs est en principe protégé par les ACL (listes de contrôle d’accès) : seuls les comptes disposant des autorisations nécessaires peuvent les consulter.

Si vous débutez avec la solution, la mise en place complète (installation, préparation du schéma, GPO) est détaillée dans notre cours gratuit sur Microsoft LAPS.

Pourquoi les ACL sont le maillon faible

Le principal risque réside dans une mauvaise gestion des ACL sur les objets ordinateurs. Un utilisateur disposant de droits excessifs peut accéder à des informations sensibles sans que cela soit visible au niveau des OU, car la permission est portée par l’objet lui-même. Ces délégations dangereuses peuvent être rapprochées de plusieurs catégories de failles reconnues :

• CWE-284 : mauvais contrôle d’accès.
• CWE-732 : attribution incorrecte de permissions sur une ressource critique.
• CWE-269 : mauvaise gestion des privilèges.

Une telle exposition peut conduire à une élévation de privilèges, puis à des mouvements latéraux au sein du système d’information.

Démonstration : d’une délégation oubliée à la compromission

Dans notre lab, nous allons illustrer plusieurs cas concrets d’erreurs de délégation pouvant mener à une exposition des mots de passe LAPS. L’objectif n’est pas de fournir un mode d’emploi offensif, mais de montrer à quel point ces expositions sont banales et faciles à exploiter, pour mieux les traquer ensuite.

Scénario 1 : un droit Full Control qui persiste après déplacement

Dans un premier temps, nous accordons par erreur à un droit de type (FC) sur une machine. Cette mauvaise configuration peut provenir d’une simple erreur d’un technicien ou d’une demande ponctuelle dans une OU de test. Le problème, c’est que ce droit persiste, ce qui peut créer une véritable porte dérobée. Ici, la machine PC-1 dispose des droits accordés à .

Une fois la machine déplacée vers une autre OU, nous constatons que les droits ACL ont été conservés. Le déplacement ne réinitialise pas les permissions portées directement par l’objet.

Scénario 2 : un droit de lecture directement sur l’attribut

Dans un second scénario, nous accordons directement à le droit de lecture sur l’attribut du mot de passe LAPS, sur et . Nous allons ensuite vider la valeur du champ de date d’expiration du mot de passe LAPS sur ce dernier, ce qui perturbe le suivi de rotation.

Voici les permissions en question :

Ces droits n’apparaissent pas au niveau des OU, car ils sont directement appliqués à l’objet . Cela les rend beaucoup plus difficiles à détecter : l’exécution des commandes du module PowerShell LAPS ne permet pas d’identifier cette anomalie.

Exploitation : lire le mot de passe et rebondir

Depuis PC-1, l’utilisateur disposant du droit sur l’objet peut exploiter cette configuration et lire le mot de passe LAPS. En quelques commandes, sans outil RSAT ni élément particulier, le mot de passe est récupéré, ce qui lui permet de devenir administrateur local de la machine.

Ainsi, une élévation de privilèges a été réalisée facilement.

De la même façon, nous récupérons le mot de passe de .

Puis nous ouvrons une connexion en Bureau à distance vers le serveur.

L’ouverture de session s’effectue sans difficulté, ce qui facilite un mouvement latéral vers le serveur. Comme nous pouvons le voir, nous n’avons eu besoin d’aucune compétence avancée ni d’outil spécifique (Linux, Kali) pour exploiter cette mauvaise configuration et prendre le contrôle.

Pourquoi les outils d’audit classiques passent à côté

Pour vérifier la portée du problème, nous avons testé les principaux outils d’audit Active Directory sur ce même scénario. Dans notre lab, nous avons utilisé PingCastle et Purple Knight en version gratuite, puis ADACLScan et BloodHound. Aucun d’eux n’a permis de corréler correctement les ACL anormales avec la présence de LAPS sur les machines, en particulier lorsqu’un droit inapproprié est défini directement sur l’objet.

PingCastle et Purple Knight

L’usage de PingCastle a été rapidement écarté : la version gratuite ne propose pas d’audit LAPS spécifique.

Purple Knight, de son côté, analyse et liste les droits ACL sur chaque machine pour les utilisateurs non standards pouvant lire le mot de passe. Cependant, dans le cas d’une délégation légitime effectuée au niveau d’une OU (par exemple pour les groupes ou ), ces droits sont interprétés comme non légitimes. Cela génère des résultats volumineux, avec des tableaux pouvant contenir plusieurs milliers de machines, ce qui rend l’analyse difficile et peu exploitable.

Scan ADACL

Le module ADACLScan ne propose pas d’analyse spécifique liée à LAPS ou aux droits dangereux. Il se contente de lister l’ensemble des ACL par défaut. Il est donc nécessaire d’ajouter ses propres filtres et combinaisons pour identifier les cas à risque. Sur un environnement de grande taille, l’outil peut ainsi passer à côté de certaines expositions, notamment pour des utilisateurs ne disposant pas de connaissances approfondies.

BloodHound

Sous BloodHound, le résultat est semblable à celui de Purple Knight. Nous avons utilisé le filtre Cypher suivant pour lister les comptes disposant de droits étendus sur les machines gérées par LAPS :

Nous pouvons alors visualiser les comptes disposant de droits étendus sur les machines. Cependant, il est impossible de déterminer si ces droits ont réellement été délégués via une OU parente ou directement sur les objets, rendant l’analyse ambiguë, en particulier dans des environnements de grande taille comportant un nombre important de machines.

4

LegacyLapsAudit : un module PowerShell dédié à l’audit des délégations

Face à ce constat, nous avons décidé de créer un outil open source, français, pour lever cette ambiguïté. Il s’agit d’un module PowerShell disponible sur la PowerShell Gallery.

Son objectif est d’analyser les machines, de comparer les droits pour déterminer s’ils sont légitimes ou non, d’identifier les accès suspects à la lecture des mots de passe LAPS, et d’offrir une vue globale et simple des délégations ainsi que de l’usage de LAPS.

Ci-dessous le mécanisme de fonctionnement :

Prérequis

Le module ne nécessite pas de droits élevés et peut être exécuté depuis n’importe quelle machine du domaine. Néanmoins, disposer d’un compte ayant accès en lecture aux attributs LAPS est un plus pour affiner l’analyse et obtenir un rapport complet.

Installation

L’installation se fait directement depuis la PowerShell Gallery, au niveau de l’utilisateur courant :

Lancer une analyse

Une fois le module installé, une analyse complète du domaine se lance avec la commande suivante :

Dans un environnement étendu, je vous recommande de cibler d’abord une OU précise à l’aide du paramètre , en spécifiant le chemin LDAP de l’OU concernée. Cela permet de limiter le périmètre et d’accélérer la première passe d’analyse. À la fin de l’exécution, un rapport s’ouvre automatiquement dans le navigateur.

Vous pouvez consulter un exemple de rapport en ligne pour vous faire une idée du rendu.

Lire le rapport

Plusieurs sections et informations sont disponibles, à commencer par le nombre de machines analysées et celles disposant de LAPS.

La première section intéressante est Suspicious ACL. Elle met en évidence les comptes ayant un droit de lecture sur les mots de passe sans que ce droit soit défini via une OU parente. C’est exactement le cas de figure de nos deux scénarios : cette section peut révéler un oubli, un déplacement d’objet ou une mauvaise configuration.

La section All Laps Delegated permet de lister l’ensemble des comptes ou groupes pouvant lire les mots de passe LAPS sur le parc, avec des informations complémentaires telles que la date de création du compte, son état ou encore son niveau de privilège.

Enfin, une troisième section présente les délégations par OU.

À l’aide de ces informations, l’outil permet de suivre et de maintenir un niveau de sécurité cohérent, en gardant à l’esprit que ce type d’analyse doit être réalisé de manière régulière.

Remédiation : migrer vers Windows LAPS

Face aux menaces actuelles, l’adoption de Windows LAPS (la nouvelle version, dite LAPS2) est fortement recommandée. Contrairement à l’ancien LAPS (Legacy LAPS), qui repose uniquement sur des ACL pour protéger l’attribut , la nouvelle version introduit des mécanismes de sécurité beaucoup plus robustes :

• Le mot de passe est stocké dans un attribut sécurisé (par exemple ).
• Il est chiffré avec des mécanismes cryptographiques modernes.
• L’accès ne repose plus uniquement sur des ACL classiques, mais aussi sur une autorisation de déchiffrement distincte.
• Un utilisateur non autorisé ne verra qu’une valeur chiffrée inutilisable, même s’il parvient à lire l’attribut.

Il faut toutefois garder en tête que le chiffrement de Windows LAPS nécessite un niveau fonctionnel de domaine (DFL) 2016 ou supérieur. Sur un domaine plus ancien ou pour des machines non compatibles, Windows LAPS peut fonctionner en mode texte clair, protégé uniquement par les ACL : dans ce cas, la vigilance sur les délégations reste tout aussi nécessaire.

Pour préparer cette migration, deux tutoriels IT-Connect détaillent la mise en œuvre de Windows LAPS selon votre environnement :

• Pour un déploiement on-premise, suivez notre tutoriel Configurer Windows LAPS avec l’Active Directory.
• Pour un parc géré via le cloud, consultez notre tutoriel Configurer Windows LAPS avec Intune (stockage des mots de passe dans Microsoft Entra ID).

La documentation officielle de Microsoft, Bien démarrer avec Windows LAPS et Active Directory, complète ces ressources.

Conclusion

Nous avons vu qu’une simple mauvaise délégation peut exposer les mots de passe LAPS et permettre une élévation de privilèges ainsi qu’un mouvement latéral, sans outil avancé. La sécurité d’un annuaire Active Directory ne repose ni sur un outil, ni sur un script, mais sur un ensemble de bonnes pratiques alliant technique et stratégie.

Une délégation mal maîtrisée suffit à compromettre un environnement, d’où l’importance d’un audit régulier et d’un contrôle précis des accès. Un module comme LegacyLapsAudit ne remplace pas cette rigueur, mais il comble un angle mort réel des outils du marché : la corrélation entre les ACL portées par les objets ordinateurs et l’usage de LAPS.

FAQ