Droits Utilisateur Dangereux GPO Active Directory SeDebug SeTcb : Escalade de Privilège SeLoadDriver vers SYSTEM

Qu'est-ce qu'une attribution de droits utilisateur dangereuse dans Active Directory

La Group Policy ne se limite pas à déployer des logiciels ou à mapper des lecteurs réseau — son conteneur Security Settings peut aussi accorder des droits utilisateur locaux (des « privilèges » dans le modèle de jeton d'accès Windows, distincts des permissions sur les objets) à n'importe quel principal de sécurité, y compris Authenticated Users, Domain Users, ou un groupe personnalisé. Lorsque la section [Privilege Rights] d'une GPO attribue un privilège à fort impact tel que SeDebugPrivilege, SeLoadDriverPrivilege ou SeTcbPrivilege à des comptes qui ne sont pas administrateurs locaux, chaque ordinateur auquel la GPO s'applique hérite d'un chemin direct, sans exploit requis, entre « n'importe quel compte du domaine » et SYSTEM. Les équipes sécurité et les auditeurs signalent de plus en plus ce schéma — des droits utilisateur dangereux accordés via GPO — comme un constat Active Directory distinct, différent de la classique mauvaise configuration « la GPO ajoute un utilisateur au groupe Administrateurs locaux ».

Il ne s'agit pas d'une vulnérabilité de Windows, mais d'une erreur d'écriture de Group Policy, généralement introduite pour débloquer un agent de supervision, un outil de sauvegarde ou un outil de helpdesk qui a légitimement besoin de droits élevés, puis laissée en place (ou copiée dans des GPO sans rapport) longtemps après que la justification initiale a disparu. Les mauvaises configurations de GPO comptent parmi les vecteurs d'attaque les plus courants de Group Policy, précisément parce qu'elles sont silencieuses : rien ne casse, aucune alerte ne se déclenche, et la GPO continue de s'appliquer à chaque cycle de rafraîchissement de la politique.

Le rayon d'impact dépend du lien de la GPO, pas de la justification initiale de l'attribution. Une GPO créée pour corriger l'agent de supervision d'un seul serveur, puis liée par commodité à une OU ou à la racine du domaine, accorde silencieusement le même droit à tous les ordinateurs sous ce lien — transformant une exception étroite et justifiable en un chemin d'escalade à l'échelle du domaine que personne n'a validé, une variante de plus des chemins cachés vers Domain Admin liés à l'imbrication dangereuse de groupes.

Pourquoi Active Directory considère ces droits utilisateur accordés par GPO comme dangereux

Windows applique environ une trentaine de droits utilisateur via le jeton d'accès. La plupart sont anodins entre de mauvaises mains — « Changer le fuseau horaire » n'est pas un chemin vers SYSTEM. Trois d'entre eux font exception.

SeDebugPrivilege (« Déboguer des programmes »)

SeDebugPrivilege permet à son détenteur d'ouvrir un handle vers n'importe quel processus ou thread de la machine, en contournant le contrôle d'accès qui empêcherait normalement un non-propriétaire de toucher au processus d'un autre utilisateur — y compris les processus appartenant à NT AUTHORITY\SYSTEM. Comme LSASS s'exécute en tant que SYSTEM et conserve en mémoire des identifiants mis en cache, un compte disposant de SeDebugPrivilege peut ouvrir un handle vers LSASS et en extraire des identifiants exploitables — le même mécanisme que celui utilisé par le module sekurlsa de Mimikatz, et le même mécanisme derrière les techniques de living-off-the-land comme le dump de LSASS via l'export MiniDump de comsvcs.dll. Par défaut, seuls les administrateurs détiennent ce droit.

SeLoadDriverPrivilege (« Charger et décharger des pilotes de périphérique »)

SeLoadDriverPrivilege permet à son détenteur de charger un pilote en mode noyau via l'API NtLoadDriver(). Les pilotes noyau s'exécutent sans barrière de sécurité vis-à-vis du reste de l'OS : un compte disposant de ce droit peut donc enregistrer et charger un pilote signé connu pour être vulnérable (le pilote Capcom.sys en est un exemple bien documenté) et l'utiliser comme primitive pour lire/écrire en mémoire noyau ou exécuter du code arbitraire en tant que SYSTEM — une technique communément appelée BYOVD (Bring Your Own Vulnerable Driver). Ce chemin reste pertinent même face à un EDR moderne, car un pilote vulnérable signé est approuvé par les contrôles d'intégrité du code qui bloquent le code non signé.

SeTcbPrivilege (« Agir en tant que partie du système d'exploitation »)

SeTcbPrivilege est le plus direct des trois : il permet à son détenteur d'appeler les API d'authentification normalement réservées à la Trusted Computing Base de Windows, ce qui inclut l'usurpation de n'importe quel compte du système, y compris SYSTEM. Un attaquant détenant ce droit n'a besoin ni de dumper des identifiants ni de charger un pilote — il peut créer un service qui appelle directement les API de logon de confiance et usurper SYSTEM sans détour. Sur un système correctement configuré, aucun compte non-administrateur ne devrait jamais détenir SeTcbPrivilege.

🚨 Danger : les trois droits sont considérés comme critiques car aucun ne nécessite un exploit d'exécution de code. Si la GPO accorde le droit, l'escalade est un usage documenté et pris en charge d'une API Windows — pas un bug.

La chaîne d'attaque : de la mauvaise configuration GPO à SYSTEM

Étape 1 — Découvrir l'attribution

Un attaquant qui dispose déjà d'un point d'appui dans le domaine (un utilisateur phishé, un compte de service peu privilégié) énumère les GPO appliquées aux OU intéressantes — contrôleurs de domaine, serveurs tier-0, rebonds — et lit la section [Privilege Rights] du fichier GptTmpl.inf de chaque GPO dans SYSVOL, lisible par défaut par tout utilisateur authentifié :

# Enumerer la section User Rights Assignment de chaque GPO pour les trois droits critiques
Get-GPO -All | ForEach-Object {
    $report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
    $report.GPO.Computer.ExtensionData.Extension.UserRightsAssignment |
        Where-Object { $_.Name -match 'SeDebugPrivilege|SeLoadDriverPrivilege|SeTcbPrivilege' } |
        Select-Object @{n='GPO';e={$report.GPO.Name}}, Name, Member
}

Étape 2 — Confirmer que le compte est concerné

L'attaquant vérifie si son compte actuel — ou un groupe qu'il contrôle, y compris un groupe large comme Authenticated Users si la GPO est configurée aussi largement — figure parmi les membres de l'attribution, et à quels ordinateurs la GPO est liée. Une GPO liée à la racine du domaine ou à une OU contenant des contrôleurs de domaine transforme ce constat d'« intéressant » en « qui met fin au domaine ».

Étape 3 — Exploiter le droit

• Avec SeDebugPrivilege : ouvrir un handle sur lsass.exe et extraire des identifiants pour un cassage hors ligne ou du replay.
• Avec SeLoadDriverPrivilege : enregistrer et charger un pilote signé vulnérable, puis l'exploiter pour obtenir un shell SYSTEM.
• Avec SeTcbPrivilege : appeler directement les API de logon de confiance pour usurper SYSTEM, sans pilote ni dump d'identifiants.

Chacun de ces trois droits transforme « utilisateur du domaine dans cette OU » en « SYSTEM local sur chaque machine touchée par la GPO » — ce qui, si l'OU contient des ressources tier-0, équivaut fonctionnellement à un chemin d'attaque direct vers Domain Admin. Depuis un SYSTEM local sur un contrôleur de domaine, l'attaquant n'est plus qu'à un pas des droits DCSync et de l'ensemble des identifiants du domaine.

Détection

La supervision Active Directory couvre l'ensemble plus large des ID d'événements à surveiller si vous voulez étendre la détection au-delà de ces trois privilèges. Le dépôt public de règles de détection d'Elastic embarque aussi une règle « Group Policy Abuse for Privilege Addition » qui surveille l'événement de changement du service d'annuaire (Event ID 5136) déclenché lorsque le GUID de l'extension côté client Sécurité d'une GPO est modifié — le signal indiquant que le contenu de son GptTmpl.inf, y compris [Privilege Rights], a changé — signalant précisément cette classe de droits à fort impact (SeDebugPrivilege, SeTakeOwnershipPrivilege, SeEnableDelegationPrivilege, SeImpersonatePrivilege) — une référence utile même en dehors d'Elastic Security. Quelle que soit la source à partir de laquelle vous alertez, traitez toute occurrence comme critique : il n'existe aucune raison légitime pour que ces trois droits atteignent un compte non-administrateur par simple dérive de politique.

Remédiation

1. Inventoriez chaque GPO qui touche [Privilege Rights]. Exportez toutes les GPO avec Get-GPOReport -All -ReportType Xml et recherchez les nœuds UserRightsAssignment ; ne présumez pas que seules les GPO de « baseline de sécurité » touchent cette section.
2. Limitez les trois droits critiques aux administrateurs. Les CIS Benchmarks pour Windows Server et Windows 11 fixent tous deux « Déboguer des programmes » (SeDebugPrivilege) aux seuls administrateurs comme recommandation de référence ; appliquez la même norme à SeLoadDriverPrivilege et SeTcbPrivilege, sauf exception spécifique, documentée et limitée dans le temps.
3. Retracez l'origine de chaque exception. Si un agent de supervision ou un outil de sauvegarde a réellement besoin de l'un de ces droits, limitez la GPO au plus petit groupe de sécurité possible plutôt qu'à une OU large ou à Authenticated Users, et documentez l'exception avec un responsable et une date de revue.
4. Testez dans une OU isolée avant le déploiement. Déployez d'abord une politique de droits utilisateur durcie sur une OU pilote — certains agents legacy échouent bruyamment (et de façon visible) si un droit dont ils dépendent est retiré, ce qui est une découverte bien moins coûteuse qu'en production.
5. Versionnez les modifications de GPO. Traitez les modifications de GptTmpl.inf comme des modifications de code — un processus de diff/revue des GPO transforme une attribution silencieuse de privilège en un changement révisable plutôt qu'en une surprise.
6. Rejouez le balayage régulièrement, pas seulement une fois. Les GPO sont copiées, héritées et re-liées au fil du temps, et une base saine aujourd'hui ne garantit pas une base saine le trimestre prochain. La dérive des accès privilégiés suit exactement ce schéma : les droits reviennent après la clôture de l'audit initial.

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec vérifie la section [Privilege Rights] de chaque GPO liée par rapport aux trois attributions critiques couvertes ici — PRIVILEGE_SEDEBUG_ABUSE, PRIVILEGE_SELOADDRIVER_ABUSE et PRIVILEGE_SETCB_ABUSE — et signale tout SID non par défaut disposant de l'un d'eux en dehors du groupe intégré Administrateurs, avec le nom de la GPO et l'OU liée, pour un constat directement exploitable sans balayage manuel via Get-GPOReport.