Huy Kha | Architecte principal de l'identité et de la sécurité

Active Directory (AD) est toujours au centre de la plupart des environnements d'entreprise, et les attaquants le savent. Alors que les menaces ciblent de plus en plus l'identité, AD continue d'être un point d'entrée clé et d'escalade des privilèges. Le problème est que les mêmes erreurs de configuration et les mêmes oublis se retrouvent dans toutes les organisations, quelle que soit leur taille ou leur secteur d'activité.

Après avoir examiné les résultats de plusieurs évaluations de la sécurité de l'Active Directory (ADSA) en 2025, l'équipe Identity Forensics and Incident Response (IFIR) de Semperis a constaté un schéma clair. Certains risques reviennent sans cesse. Certains sont bien connus mais ne sont pas traités, tandis que d'autres sont faciles à manquer sans les bons outils ou la bonne visibilité.

Dans ce billet, je vais passer en revue les 10 risques AD les plus courants rencontrés dans des environnements réels et expliquer ce qu'ils sont, pourquoi ils sont importants et comment les attaquants en tirent parti.

Risque 1 : Voies d'attaque de niveau 0 ouvertes par des autorisations mal configurées

Au cours des missions ADSA, l'une des configurations erronées les plus dangereuses que l'équipe IFIR a observées est lorsque des comptes ou des groupes se retrouvent avec des droits DCSync par le biais d'autorisations indirectes. Cela ne signifie pas que quelqu'un a directement attribué les autorisations. Au lieu de cela, par exemple, un compte non privilégié peut faire partie d'un groupe qui a tous les droits de contrôle sur un compte privilégié qui a déjà des capacités DCSync.

Par conséquent, un attaquant n'a pas besoin de cibler directement le compte privilégié. Il peut s'en prendre au maillon faible de la chaîne et accéder au même niveau de contrôle. La mauvaise configuration se produit généralement parce que les permissions sont déléguées de manière trop large, ce qui entraîne une violation indirecte du niveau 0(figure 1).

Figure 1. Cette analyse montre un indicateur d'exposition (IOE) résultant d'une mauvaise configuration des autorisations déléguées.

Un autre exemple d'attaque menant à une violation de niveau 0 est la compromission d'un compte disposant de droits d'écriture sur les objets du contrôleur de domaine(Figure 2). Cet accès peut être utilisé de manière abusive pour effectuer une attaque de type "Resource-Based Constrained Delegation" (RBCD), permettant à l'attaquant d'usurper l'identité de comptes disposant de privilèges élevés.

Figure 2. Cet indicateur met en évidence les utilisateurs ou les groupes qui n'ont pas été désignés par défaut et qui ont reçu un accès en écriture à un objet DC.

Risque 2 : Utilisation excessive de groupes AD intégrés à haut niveau de privilèges

Les environnements Windows plus anciens comprennent souvent des groupes intégrés destinés à l'administration déléguée de fonctions telles que les opérateurs de compte, les opérateurs de serveur, les opérateurs de sauvegarde et les opérateurs d'impression. Ces groupes sont souvent négligés mais peuvent encore détenir des privilèges élevés dans Active Directory(figure 3). Si ces groupes sont remplis, leurs membres peuvent effectuer des actions qui conduisent à une escalade des privilèges et à un accès direct aux ressources de niveau 0.

Figure 3. Cette analyse examine AD à la recherche de groupes intégrés à privilèges élevés qui présentent un risque pour la sécurité.

L'utilisation continue des anciens groupes intégrés augmente le risque de compromission, en particulier si les comptes qu'ils contiennent ne sont pas étroitement surveillés ou contrôlés. Les meilleures pratiques recommandent généralement d'éviter de s'appuyer sur la plupart des groupes intégrés dans AD (par exemple, DnsAdmins, Administrateurs DHCP, Propriétaires de créateurs de stratégies de groupe, Utilisateurs de bureaux à distance), car ils disposent souvent d'autorisations étendues(figure 4).

Figure 4. Cet indicateur identifie les membres de groupes intégrés communs qui peuvent disposer d'autorisations étendues.

Risque 3 : configuration non sécurisée du gestionnaire de réseau local

NT LAN Manager version 1 (NTLMv1) est un protocole d'authentification ancien qui est encore étonnamment courant dans certains environnements, mais il ne devrait pas l'être. Il utilise une cryptographie faible qui permet aux attaquants de capturer et de craquer facilement le trafic d'authentification(Figure 5). Si un attaquant parvient à authentifier une machine à l'aide de NTLMv1 (généralement à l'aide d'un outil d'attaque tel que Responder), il peut s'emparer du hachage du mot de passe et le craquer hors ligne pour obtenir le texte du mot de passe.

Figure 5. Cet avertissement de Microsoft attire l'attention sur la vulnérabilité des protocoles d'authentification obsolètes.

Actuellement, tous les systèmes d'exploitation Microsoft supportent la version 2 de NT LAN Manager. Avant d'appliquer NTLMv2 à l'ensemble du domaine, commencez par activer l'audit NTLM afin d'identifier les systèmes ou les applications qui utilisent encore NTLMv1. Une fois que vous avez examiné les journaux et corrigé toute dépendance héritée, vous pouvez commencer à configurer un objet de stratégie de groupe (GPO) à l'échelle du domaine pour définir le niveau d'authentification du gestionnaire de réseau local à Send NTLMv2 response only. Refuse LM & NTLM (Figure 6). Ce paramètre renforce l'authentification moderne et bloque les protocoles plus faibles.

Figure 6. Veillez à définir des politiques de sécurité pour appliquer des protocoles d'authentification modernes.

Risque 4 : Configuration non sécurisée de l'ADCS

Notre équipe IFIR constate que les services de certificats Active Directory (ADCS) mal configurés restent un risque négligé mais à fort impact dans de nombreux environnements. Lorsque les modèles de certificats, les autorisations d'inscription ou les fonctions d'inscription sur le web ne sont pas correctement sécurisés, les attaquants peuvent abuser des ADCS pour se faire passer pour des utilisateurs, élever leurs privilèges et prendre le contrôle non autorisé de systèmes sensibles.

Un problème courant est celui des modèles de certificats trop permissifs qui permettent à n'importe quel utilisateur authentifié de s'inscrire pour obtenir des certificats avec l'option Client Authentication EKU. Si l'on ajoute à cela la ENROLLEE_SUPPLIES_SUBJECT cette configuration permet aux utilisateurs de spécifier eux-mêmes le sujet du certificat (Figure 7), ce qui peut permettre à des utilisateurs peu privilégiés de demander des certificats au nom d'autres comptes, y compris les administrateurs de domaine. Ces certificats peuvent ensuite être utilisés pour se faire passer pour ces comptes et obtenir un accès élevé. Ce type de mauvaise configuration est classé comme ESC1.

Figure 7 : Des modèles de certificats ADCS mal configurés peuvent permettre à des attaquants de demander des certificats pour des comptes à haut privilège et d'obtenir un accès élevé.

Un risque connexe survient lorsque des utilisateurs peu privilégiés ont la possibilité de modifier les modèles de certificats. Les attaquants peuvent abuser de cette vulnérabilité pour introduire des paramètres non sécurisés, tels que l'activation de l'option ENROLLEE_SUPPLIES_SUBJECTqui peut transformer un modèle précédemment sûr en un modèle vulnérable à des attaques telles que ESC1 (Figure 8). Ce type de mauvaise configuration relève de l'ESC4.

Figure 8. Cet indicateur de sécurité signale que la mauvaise configuration d'un modèle de certificat peut présenter des risques.

Risque 5 : Délégation sans contrainte

La délégation sans contrainte(figure 9) est dangereuse car lorsqu'un utilisateur demande un ticket de service sur un serveur doté de ce paramètre, son ticket d'attribution de ticket (TGT) est inclus et reste en mémoire. Si un pirate prend le contrôle de ce serveur, il peut s'emparer du TGT et l'utiliser pour usurper l'identité de l'utilisateur. Le risque augmente si le service Windows Print Spooler fonctionne sur les DC. Un attaquant peut utiliser le bogue de l'imprimante pour faire en sorte qu'un DC s'authentifie auprès du serveur compromis, ce qui fait fuir le TGT du DC et donne à l'attaquant le contrôle total.

Pour réduire le risque, veillez à ce que vos comptes de niveau 0 ou équivalents disposent de l'autorisation d'accès à l'Internet. Account is sensitive and cannot be delegated et ajoutez-les au groupe des utilisateurs protégés.

Figure 9. La mise en place d'une délégation sans contrainte sur un serveur expose le TGT Kerberos à la compromission et aux abus.

Risque 6 : Des utilisateurs non privilégiés peuvent ajouter des comptes d'ordinateur au domaine

Dans la plupart des environnements AD, tout utilisateur authentifié peut ajouter jusqu'à 10 ordinateurs au domaine. Il s'agit d'un paramètre par défaut qui est souvent oublié. Mais les attaquants n'oublient pas. S'ils ont accès à un compte à faible privilège, ils peuvent créer un objet ordinateur(Figure 10) et l'utiliser dans des attaques qui s'appuient sur le RBCD.

La situation s'aggrave lorsque certains modèles de certificats permettent aux ordinateurs du domaine de s'inscrire et d'inclure le certificat Client Authentication EKU avec le ENROLLEE_SUPPLIES_SUBJECT drapeau. Cette combinaison ouvre la porte à une attaque ESC1 classique, dans laquelle l'attaquant peut demander un certificat qui lui permet d'usurper l'identité d'un autre utilisateur. Si vous n'avez pas de raison d'autoriser les utilisateurs à ajouter des machines au domaine, il est préférable de définir l'attribut ms-DS-MachineAccountQuota à 0 et le verrouiller.

Figure 10. Cet indicateur de sécurité vous signale que vous devez vous assurer que les utilisateurs ne peuvent pas ajouter de machines à votre domaine.

Risque 7 : Comptes privilégiés avec SPN configuré

L'attribution de Service Principal Names (SPN) à des comptes d'utilisateurs privilégiés tels que Domain Admins ou d'autres comptes de niveau 0 présente un risque de sécurité important. Lorsqu'un compte privilégié possède un SPN (Figure 11), n'importe quel utilisateur authentifié du domaine peut envoyer une requête Kerberos Ticket-Granting Service (TGS) pour l'obtenir. Le ticket obtenu est chiffré avec le hachage du mot de passe du compte, ce qui signifie qu'un attaquant peut l'extraire et effectuer un La kermesse attaque. L'une des erreurs de configuration les plus courantes est l'attribution d'un MSSQL SPN au compte Administrateur intégré (RID 500), ce qui permet aux attaquants d'accéder directement par Kerberoasting à l'un des comptes les plus puissants du domaine.

Le point essentiel est que le piratage se fait entièrement hors ligne. Une fois que l'attaquant a le ticket, il peut effectuer une attaque par force brute ou par dictionnaire à l'aide d'outils tels que hashcat sans générer d'autre trafic ou d'autres alertes sur le DC. Les comptes privilégiés ne devraient jamais se voir attribuer de SPN. Si un service a besoin d'un SPN, il doit être exécuté sous un compte de service séparé, à faible privilège, avec un mot de passe fort et géré.

Figure 11 : Cette analyse identifie les comptes privilégiés avec les SPN définis.

Risque 8 : Les comptes de service périmés restent activés

Les comptes de service ont tendance à s'accumuler au fil du temps. Ils sont souvent créés pour des systèmes qui ont été remplacés, des scripts ponctuels ou d'anciens projets que plus personne ne gère. Le problème est que beaucoup de ces comptes restent activés longtemps après qu'ils ne sont plus nécessaires. Certains d'entre eux disposent encore d'autorisations élevées ou sont exclus des politiques de mot de passe habituelles, ce qui en fait une cible parfaite pour les attaquants. Si l'un de ces comptes oubliés est compromis, il peut être difficile à détecter. Comme personne ne l'utilise activement, toute activité suspecte peut passer inaperçue.

Comme le montre la figure 12 , il est utile de passer régulièrement en revue les comptes de service. Si un compte n'a pas été utilisé depuis longtemps et que personne ne peut justifier son utilité, désactivez-le et surveillez les éventuelles retombées.

Figure 12. L'examen régulier des comptes de service et de leur activité permet de s'assurer que les comptes inutilisés sont purgés avant qu'ils ne soient compromis.

Risque 9 : Absence d'application de niveau 0

La mise en œuvre d'un modèle de hiérarchisation complet pour l'entreprise est un défi et est souvent irréaliste. Mais il n'est pas négociable de disposer d'un modèle minimal pour les systèmes de niveau 0.

Les systèmes de niveau 0 sont ceux qui contrôlent l'identité, et s'ils sont compromis, le reste de l'environnement tombe avec eux. Dans la plupart des ADSA, nous avons constaté que de nombreuses organisations n'ont mis en place aucun modèle de hiérarchisation.

Si vous n'avez pas encore établi de modèle de niveau 0, il est temps de commencer. Pour vous aider, la figure 13 présente une liste de systèmes qui sont généralement traités comme des systèmes de niveau 0 dans des environnements bien sécurisés, ainsi qu'un modèle permettant de déterminer leur statut de niveau 0.

Figure 13. Il est essentiel pour la cybersécurité de l'entreprise de comprendre, d'identifier et de protéger les actifs de niveau 0 tels que ceux figurant dans cette liste.

Risque 10 : Sauvegardes d'Active Directory non fiables et non restaurables

AD est au cœur de l'authentification et de l'accès dans l'ensemble de l'environnement. Pourtant, l'une des lacunes les plus critiques que nous constatons encore dans de nombreuses organisations est l'absence d'une stratégie de sauvegarde appropriée pour Active Directory.

Certaines organisations pensent qu'il suffit d'avoir des contrôleurs de domaine répartis sur plusieurs sites, ou elles s'appuient sur des instantanés de VM à usage général sans vérifier si ces sauvegardes peuvent restaurer AD d'une manière cohérente et prise en charge.

En réalité, si Active Directory tombe en panne et qu'il n'y a pas de sauvegarde propre et restaurable, la récupération devient extrêmement difficile, surtout après une cyberattaque.

Une sauvegarde AD fiable n'est pas une simple copie au niveau du fichier ou un instantané. Créez une sauvegarde fiable et validée. Isolez-la du domaine de production. Protégez-la de toute altération. Et testez-la régulièrement. Sans cette sauvegarde, vous exposez votre infrastructure la plus critique à des dommages irréversibles.

Aperçu de Semperis

À une époque où les cyberattaques ne sont pas une question de " si " mais de " quand", les organisations doivent prendre des mesures pour assurer leur résilience avant, pendant et après un cyberincident.

Commencez par éliminer les vulnérabilités courantes comme celles-ci. Ensuite, collaborez avec des experts en matière d'identité et sélectionnez des outils de gestion de l'identité pour vous aider :

  • Renforcez vos défenses
  • Établir de manière proactive des stratégies efficaces de réponse aux incidents
  • Se rétablir rapidement en cas d'incident
  • Réduire le risque à long terme

Vous avez besoin d'un examen plus approfondi de votre infrastructure d'identité ? Profitez des dizaines d'années d'expérience de notre équipe IFIR.

En savoir plus sur l'élimination des vulnérabilités d'Active Directory