Tim Beasley Consultant senior en gestion des incidents

Bienvenue à nouveau dans notre série consacrée aux groupes Active Directory à risque qui ne « semblent » pas dangereux. Comme je l’ai expliqué dans notre premier épisode, les pirates n’ont pas besoin du rôle d’administrateur de domaine pour causer de réels dégâts, et ils ne recherchent pas toujours des groupes dotés de privilèges aussi élevés et évidents.

« Account Operators » est un groupe AD que beaucoup de gens sous-estiment, car il ne contient pas le mot « admins ». C'est précisément pour cette raison qu'il est si souvent négligé.

On croit souvent à tort que le groupe « Account Operators » ne représente pas un risque sérieux, car ses membres ne sont pas censés modifier les groupes protégés tels que « Domain Admins ».

Cette hypothèse est, au mieux, incomplète — et, au pire, dangereuse.
Elle est également fausse dans certaines circonstances.

Le problème principal n’est pas que le groupe « Account Operators » soit un groupe administratif de « niveau supérieur » à proprement parler (même si nous le traitons comme tel). Le véritable problème réside dans le fait qu’il confère un contrôle étendu sur les identités au sein du domaine — et dans Active Directory, les identités sont synonymes de privilèges.


Que peuvent faire concrètement les gestionnaires de compte ?

Par défaut, les membres du groupe « Account Operators » peuvent créer, modifier et supprimer des objets utilisateur, groupe et ordinateur dans la majeure partie du domaine. Dans de nombreux environnements, cela inclut les capacités suivantes :

  • Réinitialiser les mots de passe
  • Activer ou désactiver des comptes
  • Modifier les noms d'entités de service (SPN)
  • Gérer l'appartenance à des groupes non protégés
  • Créer de nouveaux comptes utilisateur

Les opérateurs de compte ne sont délibérément pas autorisés à modifier directement les groupes et comptes protégés contrôlés par AdminSDHolder, notamment les administrateurs de domaine, les administrateurs d'entreprise, les administrateurs de schéma et le groupe « Administrateurs » intégré sur les contrôleurs de domaine.

Mais ces restrictions n'éliminent pas les vecteurs d'attaque qu'un acteur malveillant expérimenté peut exploiter après avoir compromis un membre du groupe « Account Operators ».

C’est là le point essentiel que les responsables de la sécurité doivent bien comprendre : « Account Operators » n’est pas un simple rôle d’administrateur délégué inoffensif.
Il s’agit d’un amplificateur de privilèges situé directement au-dessus du plan d’identité.


Pourquoi le groupe des « Account Operators » devient-il si rapidement dangereux ?

Si un pirate parvient à compromettre les identifiants d'un opérateur de compte, il n'a pas besoin de s'ajouter au groupe « Domain Admins » pour commencer à agir à sa guise.

Je les ai vus créer des utilisateurs contrôlés par des attaquants, réinitialiser les mots de passe de comptes privilégiés non protégés, manipuler indirectement l'appartenance à des groupes, ajouter des SPN pour mettre en place des attaques de type « Kerberoasting », et abuser de la création d'objets informatiques pour mener des attaques par délégation, telles que la délégation restreinte basée sur les ressources.

Cela est important car bon nombre des voies d’attaque les plus réalistes visant les entreprises ne nécessitent pas de s’attaquer en premier lieu aux groupes « stratégiques » les plus évidents. Il suffit de disposer des identités adéquates, des groupes délégués appropriés et des voies d’authentification adéquates le temps nécessaire pour changer de cible.

En d’autres termes, les « Account Operators » offrent à un attaquant un accès en écriture distribué à l’ensemble de l’infrastructure d’identité. Cela suffit souvent amplement pour passer du statut de « pas tout à fait privilégié » à celui de « je vous tiens à ma merci ».


Scénarios d'abus plausibles après la compromission des opérateurs de compte

Une méthode évidente consiste à créer des comptes « porte dérobée ». Un attaquant peut créer un nouvel utilisateur, puis l'intégrer à des groupes privilégiés ou semi-privilégiés qu'il est en mesure de contrôler, y compris des groupes disposant de voies d'escalade cachées qui font souvent l'objet d'une surveillance bien moins stricte que celle des administrateurs de domaine. De plus, cette approche lui permet de comprendre l'imbrication des groupes au sein des groupes privilégiés, ce qui facilite une escalade supplémentaire et assure la persistance de l'attaque.

Une autre méthode courante consiste à procéder à des réinitialisations de mots de passe ciblées ou en masse. Les opérateurs de comptes peuvent réinitialiser les mots de passe de la plupart des utilisateurs du domaine, y compris les comptes de service, les identités d’application et les utilisateurs administratifs non protégés. Entre les mains d’un acteur malveillant, cela se traduit par un accès opérationnel immédiat et un risque de perturbation des activités.

Une troisième voie consiste à exploiter les SPN et à recourir au « kerberoasting ». Si un attaquant parvient à modifier les attributs d’un compte et à ajouter des SPN, il peut créer de nouvelles cibles vulnérables au « kerberoasting » ou rendre des comptes existants exploitables sans que l’« attaque » ne semble évidente.

Une quatrième méthode consiste à exploiter des comptes non protégés mais qui restent précieux. De nombreuses organisations disposent encore d’administrateurs délégués, de comptes de service hérités et de groupes imbriqués qui ne sont pas protégés par AdminSDHolder. La réinitialisation des mots de passe ou la modification des attributs de ces objets peut suffire à obtenir des privilèges supérieurs.

Et puis il y a utilisation abusive d'un compte informatique. Étant donné que les opérateurs de compte peuvent souvent créer des objets informatiques et contrôler ce qu’ils créent, ils peuvent permettre des attaques impliquant MachineAccountQuota et la délégation soumise à des contraintes liées aux ressources. Cela ouvre la voie à l'usurpation d'identité et à l'escalade de privilèges sans jamais toucher directement au groupe « Domain Admins ».

On s'amuse déjà ?


La nuance concernant AdminSDHolder que les défenseurs ne devraient pas ignorer

C'est là que la conversation devient encore plus gênante.

En théorie, les opérateurs de compte ne devraient pas pouvoir modifier les groupes protégés tels que « Domain Admins » ou « Enterprise Admins ».

Dans la pratique, cette protection n'est pas appliquée en continu. Elle est assurée par le processus « Security Descriptor Propagator », communément appelé SDProp, qui appose la liste de contrôle d'accès (ACL) AdminSDHolder sur les objets protégés selon un cycle périodique. Par défaut, ce cycle s'exécute toutes les 60 minutes environ.

L’intervalle par défaut de 60 minutes de SDProp revêt une grande importance. Entre deux cycles de traitement, les « objets protégés » peuvent temporairement s’écarter du descripteur de sécurité prévu. Si les autorisations ont dérivé, si les droits hérités ou délégués n’ont pas encore été entièrement corrigés, ou si un objet nouvellement créé ou modifié n’a pas été réactualisé, un attaquant peut disposer d’une brève opportunité d’exploiter cette faille avant que SDProp ne réapplique la liste de contrôle d’accès (ACL) protégée.

Cela signifie qu’un attaquant n’a pas nécessairement besoin d’une appartenance permanente à un groupe protégé. Il lui suffit parfois de disposer d’un délai suffisant au sein de cette fenêtre par défaut de 60 minutes pour ajouter un principal contrôlé, démarrer une session privilégiée, extraire des secrets, créer des comptes de porte dérobée ou établir une persistance ailleurs avant que SDProp ne supprime les preuves évidentes au niveau de la liste de contrôle d’accès (ACL) ou de l’appartenance. Il peut même avoir le temps de réinitialiser un compte administrateur nouvellement créé.

60 minutes, c'est beaucoup de temps pour un cybercriminel expérimenté.

Cela pose un grave problème de détection pour les responsables de la sécurité, car cela peut donner lieu à l'octroi de privilèges de très courte durée, suivis d'activités privilégiées menées à partir d'un compte qui pourrait ne plus sembler disposer de privilèges lorsque les enquêteurs examineront la situation ultérieurement.

Le point essentiel à retenir est que la protection AdminSDHolder est cohérente à terme, et non en temps réel, et que la fréquence par défaut de 60 minutes pour la planification SDProp constitue la faille qu'un attaquant tente d'exploiter.


Que doivent surveiller les responsables de la sécurité pour détecter les abus commis par les « Account Operators » ?

Si vous souhaitez détecter les abus commis par les opérateurs de comptes, commencez par examiner l'activité liée au cycle de vie des identités. La création de nouveaux comptes, l'activation de comptes, la réinitialisation de mots de passe et les modifications apportées aux comptes constituent autant d'indicateurs clés lorsqu'elles sont effectuées par un membre de ce groupe. Les événements pertinents sont notamment les codes 4720, 4722, 4723, 4724 et 4738.

Ensuite, surveillez de près les modifications apportées à l'appartenance aux groupes, en particulier les ajouts à des groupes délégués inhabituels, à des groupes imbriqués ou à des groupes conférant des privilèges rarement utilisés. Les événements tels que 4728, 4732 et 4756 sont importants à cet égard, et dans le scénario à fenêtre courte, vous devez également mettre en corrélation les schémas d'ajouts et de suppressions rapides avec les événements 4729, 4733 et 4757.

Vous devez également surveiller les modifications apportées aux SPN et aux autres attributs des répertoires. Événement 5136 est important en cas d'imprévu servicePrincipalName modifications, changements d'attributs liés à la délégation, tels que msDS-AllowedToActOnBehalfOfOtherIdentity, ainsi que d'autres modifications suspectes sur des objets nouvellement créés ou modifiés.

Enfin, établissez une référence comportementale.

  • Combien d'utilisateurs un membre du groupe « Account Operators » crée-t-il généralement par jour ?
  • Combien de réinitialisations de mot de passe effectuent-ils habituellement ?
  • Qui sont les cibles habituelles ?

C'est lorsque l'on s'écarte de cette valeur de référence que commencent les détections à haut niveau de confiance.


Que faire à ce sujet ?

La réponse à privilégier est simple : vider le groupe.

S'il n'existe aucune raison opérationnelle valable d'utiliser des opérateurs de compte (ce qui est presque TOUJOURS le cas), supprimez les membres de ce groupe et laissez-le vide. Si vous avez tout de même besoin d'une administration déléguée, utilisez une délégation sur mesure pour les unités d'organisation (OU) et les objets spécifiques qui nécessitent réellement une gestion.

Si l'appartenance à ce groupe ne peut être supprimée immédiatement, considérez-la comme bien plus sensible que ne le font actuellement la plupart des organisations.

  • Mettre en œuvre une hiérarchie administrative
  • Empêcher la connexion interactive aux contrôleurs de domaine et aux serveurs critiques
  • Refuser la connexion locale dans la mesure du possible

Vous devriez également limiter les risques d'utilisation abusive des objets informatiques en renforçant la sécurité MachineAccountQuota (de préférence à zéro) le cas échéant, et en limitant les personnes autorisées à créer de nouveaux comptes informatiques.

De plus, surveillez attentivement les éléments susceptibles de permettre une escalade de privilèges à court terme ou indirecte : modifications des groupes privilégiés, des délégations, des SPN et des listes de contrôle d'accès (ACL) sur AdminSDHolder et les groupes protégés.


Réévaluer les risques liés aux opérateurs de comptes

Le groupe « Account Operators » est dangereux car il confère un contrôle étendu sur les objets qui définissent les droits d'accès, la confiance et l'authentification au sein d'Active Directory.

Une identité d'opérateur de compte compromise permet de créer de nouveaux entités, de réinitialiser des mots de passe, de manipuler des groupes, de mettre en place une attaque de type « Kerberoasting », d'abuser de la délégation, d'établir une persistance et, dans des conditions favorables, d'exploiter le délai intégré à la protection d'AdminSDHolder.

C'est pourquoi les responsables de la sécurité chevronnés devraient cesser de considérer les « Account Operators » comme un rôle de support traditionnel et commencer à les traiter pour ce qu'ils sont réellement : un accès pré-privilégié offrant de multiples voies d'escalade… autrement dit, le niveau 0.

L'identité, c'est le périmètre… protégez-la.

À la prochaine…Suivez les discussions sur les « Account Operators » sur LinkedIn.

Et si vous souhaitez bénéficier de l'aide d'experts pour identifier et combler les failles de sécurité de votre AD, n'hésitez pas à nous contacter pour un évaluation de la sécurité Active Directory. Nous sommes là pour vous aider.


Pour en savoir plus