Sécurité de l’Active Directory : attention aux objets avec un propriétaire inadapté

I. Présentation

Bien que certaines entreprises misent désormais sur Azure Active Directory et se passent d'un Active Directory en local, il reste un système très répandu. Certaines des entreprises qui exploitent un annuaire Active Directory sont exposées à la vulnérabilité "Broken owner" sans le savoir, ce qui rend les comptes à faible privilège sensibles. Ces comptes peuvent devenir la cible d'attaques informatiques.

Dans cet article, nous allons vous montrer comment cela se produit, vous expliquer les risques encourus, et vous expliquer comment détecter ces objets ayant un propriétaire inadapté (broken owner, en anglais) à l'aide d'un script PowerShell afin de protéger l’annuaire des potentielles attaques basées sur ce vecteur de compromission (par exemple, les attaques par délégation Kerberos).

La sécurité informatique est devenue un enjeu majeur pour les entreprises, l’AD suscite une attention particulière dans une infrastructure système Microsoft, ce dernier a pour rôle principal d’autoriser les accès aux différentes ressources, de repérer les services et de gérer les identités et permissions.

Un Active Directory propre, une obligation.

Toute mauvaise configuration ou mauvais usage de l’AD est une porte d’entrée pour une future attaque. C’est pour cette raison qu’il est essentiel de respecter les bonnes pratiques et veiller continuellement sur leurs applications. N’oublions pas qu’un AD maîtrisé et organisé constitue la base de la sécurité.

II. La notion de propriétaire des objets Active Directory

Chaque objet dans l’Active Directory possède un propriétaire qui lui confère tous les droits, notamment les droits de modifier la valeur des attributs et des autorisations. Ces droits sont représentés par des ACL (Access Control List) et sont dupliqués à partir du compte (Self) de l’objet.

Il est donc très dangereux d’accorder ce droit à des utilisateurs ou groupes à non-privilèges, que ce soit d’une façon volontaire ou intentionnelle.

A. Comment cela se produit-il?

Un utilisateur ou groupe autorisé à créer un objet dans l’AD (par délégation, par exemple) deviendra le propriétaire de cet objet à moins que ce dernier fasse partie d’un groupe à privilège, comme par exemple "Admin du domaine";  dans ce cas, le propriétaire de l’objet sera corrigé et remplacé automatiquement par l’Active Directory.

III. La problématique associée aux propriétaires d'objets

Vous devez savoir que si l’utilisateur ou le groupe n’est pas membre du groupe à privilège, il sera le propriétaire de l’objet. Lors de la création de l’objet, ce dernier hérite des droits du compte système par défaut Self présent dans la table ACL.

Si le compte “Self” avait le contrôle total, le propriétaire dans notre cas “User3” aura aussi le contrôle total. Si ce n’est pas le cas, il peut toujours se le procurer et faire des modifications à tout moment sur ces objets (car il a les permissions de modification des attributs), ces utilisateurs ou groupes deviennent ainsi une cible potentielle lors d’attaques donc il faudra les protéger et  les surveiller.

A. Exemple avec la délégation pour créer des comptes

Dans cet exemple, nous allons déléguer la tâche de création de comptes à un simple utilisateur nommé "HelpDesk1".

Sur l’OU "IT-Connect", nous allons déléguer le droit de création d'utilisateurs à "HelpDesk 1" qui n'aura aucun autre droit dans l’AD ni sur les machines locales.

Pour faire simple, nous allons lui accorder le droit de créer des comptes utilisateurs.

Nous allons ensuite créer avec l’utilisateur "HelpDesk1", les comptes "Florian" et "Dakhama", à partir d’une machine dans le domaine. Pour cela, l'utilisateur utilisera les outils "RSAT", la commande "DSADD" ou PowerShell.

Les deux objets sont bien présents dans notre Annuaire et ils ont comme propriétaire notre utilisateur "helpdesk1".

Voici les détails de sécurité du compte "Florian" :

B. Retrait des droits

Nous allons maintenant retirer les droits à l’utilisateur "HelpDesk1". Autrement dit, on supprime la délégation créée précédemment.

Dans l’onglet "Sécurité" de l'OU "IT-Connect", nous allons supprimer l’utilisateur "HelpDesk1" de la table ACL pour lui retirer les droits. L'utilisateur, quant à lui, existe toujours.

Nous constatons ensuite que l’utilisateur "HelpDesk1" ne peut plus créer de compte. C'est normal.

Les droits sont grisés :

C. Risques et menaces

L’utilisateur "HelpDesk1" n’a plus aucun droit sur notre AD, à part sur les objets dont il est le propriétaire.

Nous allons nous procurer le contrôle total sur nos anciens objets créés quand la délégation de contrôle était effective. Pour faire simple, on ouvre la console utilisateur AD (dsa.msc), on effectue un clic droit sur l’utilisateur "Florian" afin d'ajouter "HelpDesk1" (lui-même).

Maintenant que nous avons le contrôle total sur notre objet (pour rappel, l’utilisateur HelpDesk1 n’a plus aucun droit sur l’AD, les délégations ont été supprimées) on pourra tout faire sur ce compte ! Pour être précis, on peut effectuer le changement du MDP, récupérer le Hash, faire des attaques sur des attributs par délégation (ms-ds-allowedhosted), etc…..

Ici nous allons changer la valeur de l’attribut "Description", à titre d'exemple.

Je vous laisse imaginer ce qu’il est possible de faire avec ces objets, vous pouvez trouver plein d'exemples sur le Net... Ci-dessous, un autre exemple d’exploit de cette vulnérabilité. L'attaque Délégation Kerberos peut aussi être utilisée.

Voici un autre exemple de l’exploit de la vulnérabilité "Broken Owner".

Dans ce scénario, si le compte HelpDesk1 est compromis à partir d’un hash présent sur une machine sur laquelle il intervient (support niveau 1), la personne malveillante pourra se procurer ses objets dans l’AD, les rendre indétectables (en refusant la lecture de certains éléments à des groupes à privilèges) et passer en cachette pour extraire des données ou injecter des ransomwares sur des ressources partagées.

D’autres scénarios sont envisageables, A noter que même si HelpDesk1 ne possède plus de droit dans l’AD, son compte reste sensible en raison des objets dont il est le propriétaire.

IV.  Comment détecter les comptes avec un propriétaire inadapté ?

Maintenant que nous sommes conscients de ce risque et de ces menaces, nous allons voir comment lister et détecter les mauvais propriétaires des objets afin de les corriger.

A. Le script PowerShell "SCABOO"

Pour cela, nous avons développé un script simple d’utilisation (et open source) pour nous faciliter la tâche.

Ci-dessous, le lien du script PowerShell. Il existe aussi en interface graphique :

• Script SCABOO (dakhama-mehdi)

Le projet porte le nom de SCABOO (Scan-AD-Broken-Owner-Object). Pour l'utiliser, il vous suffit de le télécharger et de l'ouvrir avec PowerShell ISE ou VSCode.

La bonne nouvelle, c'est que ce script ne nécessite pas de prérequis spécifique pour fonctionner :

• Aucun module ni les droits avancés ne sont nécessaires
• Une machine et un utilisateur du domaine, tout simplement

Le script pourra être lancé à partir de n’importe quelle machine dans le domaine, avec n’importe quel compte. Il ne nécessite aucun module PowerShell complémentaire, ce qui est un avantage, et ne garde rien dans la mémoire "Variable avec les informations". Le traitement est spontané et sécurisé.

Note : utilisez le GUI si vous avez des restrictions pour exécuter le script PowerShell...

Ce que vous devez savoir sur ce script...

Le script effectue des requêtes LDAP grâce au module ADSI, il ne fait que des requêtes de types GET donc aucune modification n’est faite sur l’annuaire. Le script n’utilise pas de variable en dur comme "admins du domaine", etc…. Mais plutôt des SID, ce qui le rend compatible avec toutes les versions d’AD de toutes langues.

Une fois lancée, nous avons le choix entre un scan de l’AD entier ou de choisir une OU spécifique, nous allons commencer par ce second choix.

• Entrez le numéro 2.

• Ensuite, entrez le nom de votre OU, dans mon cas IT-Connect. Vous pouvez entrer seulement l’initiale, le script fera une recherche et proposera le choix entre les OU portant une partie du nom.
• Sélectionnez votre OU, puis entrez OK.

• Le scan est lancé

Une fois que le scan est terminé, une page HTML sera créée au même emplacement que le script. Elle sera lancée automatiquement et affiche un résumé des objets scannés et ceux présentant une anomalie.

Pour scanner tout l’AD, nous allons relancer le script et choisir l’option 1.

Remarque : attention, si votre AD contient plus de 1000 objets, le scan risque d'être un peu long (2 à 3 minutes). Si besoin, vous pouvez stopper le script à tout moment.

Voici le résultat pour un scan sur l'ensemble de notre AD :

Le script nous liste aussi les éléments sans propriétaire Owner qu'il faudra corriger en urgence, car ils peuvent être la cible d’attaques.

B. Personnalisation du script

Selon vos besoins, vous pouvez adapter certaines parties du script.

• Nombre d’éléments affiché

Par défaut, le script liste 50 éléments à corriger dans le tableau, ce choix a été fait pour ne pas ralentir le traitement et l’affichage de la page HTML, si vous avez plus de 50 éléments vous pouvez les afficher en changeant cette ligne numéro 222.

Remplacez le 50, par le nombre d’objets par catégorie souhaité.

• Affichage dans un autre format

Vous pouvez afficher le résultat dans un fichier Excel ou dans une fenêtre GridView. Pour le faire, commentez les lignes 246 et 248, et décommentez la dernière ligne.

Exemple du résultat :

• Exclure un compte

Si vous souhaitez exclure un groupe ou un compte (par exemple, le compte d’intégration MDT ou SCCM, ou un compte quelconque du résultat), ajoutez ce dernier à la variable Skipdefaultgroups. Dans notre exemple, on exclut le groupe "MDT-account".

V. Recommandations

Face à cette potentielle vulnérabilité permanente, Microsoft et ANSSI nous recommandent de changer les propriétaires des objets qui ont un propriétaire à non-privilège ou qui n’ont pas de propriétaire (Broken Owner) par l'un de ces groupes

• « Administrateurs du domaine » ;
• « Administrateurs de l'entreprise » ;
• « Administrateurs » ;
• « Système local »

Vous pouvez consulter les liens ci-dessous en complément :

• AD DS: Owner Rights | Microsoft Docs
• Points de contrôle Active Directory (ssi.gouv.fr)

VI. Conclusion

Le propriétaire des objets Active Directory est un élément très important pour la sécurité de l’annuaire. Il convient d’adapter nos usages en tenant compte de cet aspect. Nous reviendrons en détail dans un prochain article sur les méthodes de préventions et de corrections.

Merci à Mehdi Dakhama pour sa collaboration sur cet article.

Guylaine NGOUDJO Ingénieur Système Microsoft

Ingénieur système Microsoft, spécialiste dans l'architecture et la sécurité d'Active Directory et d'Azure AD. Passionnée depuis mon plus jeune âge par le monde IT, je souhaite partager mon retour d'expérience à travers mes articles.

See Full Bio