Élévation de Privilèges Active Directory : Backup Operators, Print Operators, Server Operators, les Groupes que Personne n'Audite

Élévation de Privilèges Active Directory Expliquée : Backup Operators, Print Operators, Server Operators

L'élévation de privilèges Active Directory via les groupes intégrés Backup Operators, Print Operators, Server Operators est une classe de risque que la plupart des revues centrées sur les Domain Admins ne vérifient jamais, car aucun de ces quatre groupes — Backup Operators, Print Operators, Server Operators ou Account Operators — n'est imbriqué par défaut dans Domain Admins ou Enterprise Admins. Pourtant, la documentation de Microsoft elle-même liste ces quatre groupes comme des groupes de sécurité Active Directory, et Microsoft les classe par ailleurs comme des comptes et groupes protégés — le même niveau de protection que Domain Admins et Schema Admins.

Cette classification est le signal révélateur. L'appartenance à l'un de ces quatre groupes suffit pour obtenir un accès complet en lecture/écriture à tous les fichiers d'un contrôleur de domaine, l'exécution de code en mode noyau, l'exécution de commandes au niveau service, ou la manipulation de comptes à l'échelle du domaine. Aucune de ces situations n'est une mauvaise configuration ou un correctif manquant — il s'agit du comportement voulu, par conception, des droits utilisateur Windows, appliqué par défaut à un groupe où il suffit à un attaquant de faire ajouter un seul compte.

Comment Chaque Groupe Accorde des Droits Proches de Domain Admin

Le mécanisme repose sur la Default Domain Controllers Policy (GPO), qui attribue des droits utilisateur Windows spécifiques à ces groupes sur chaque DC du domaine :

Ces valeurs par défaut sont documentées directement par Microsoft : la page de politique « Sauvegarder des fichiers et des répertoires » liste Administrators, Backup Operators et Server Operators comme détenteurs par défaut sur les contrôleurs de domaine, et la page de politique « Charger et décharger des pilotes de périphériques » liste Administrators et Print Operators. Le périmètre d'Account Operators est décrit dans la même référence des groupes de sécurité : ses membres peuvent créer et modifier la plupart des types de comptes, mais le groupe lui-même n'a aucun membre par défaut, et la recommandation de Microsoft est de le garder ainsi.

La Chaîne d'Attaque : Quatre Voies d'Entrée Distinctes

Étape 1 — De Backup Operators à ntds.dit

SeBackupPrivilege contourne entièrement les ACL NTFS, ce qui permet d'extraire la base AD directement depuis un DC en production sans jamais toucher au groupe Domain Admins. Le schéma documenté dans plusieurs publications publiques — Semperis, Hacking Articles et nhimg.org — utilise diskshadow.exe pour créer une copie shadow du volume afin de copier le fichier verrouillé ntds.dit, puis robocopy (qui respecte SeBackupPrivilege) pour récupérer la copie et un export de la ruche registre SYSTEM :

# script diskshadow (à exécuter depuis un compte détenant SeBackupPrivilege)
set context persistent nowriters
add volume c: alias cvol
create
expose %cvol% z:
exec "cmd.exe" /c robocopy /b z:\windows\ntds . ntds.dit
exec "cmd.exe" /c reg save hklm\system c:\temp\system.hive

Hors ligne, ntds.dit associé à la ruche SYSTEM livre tous les hashes de mots de passe du domaine — une voie directe vers une connexion pass-the-hash en tant que Domain Admin, sans exploit ni CVE nécessaire. Cela mène aux mêmes secrets que couvre notre article Abus ACL et DCSync pour les chemins basés sur les ACL — mais via un contournement du système de fichiers plutôt qu'un droit de réplication.

Étape 2 — De Print Operators à SYSTEM via un pilote chargé

SeLoadDriverPrivilege permet à un membre de Print Operators de charger un pilote en mode noyau sur un contrôleur de domaine. Comme le décrivent les travaux de recherche de Tarlogic sur ce privilège et plusieurs recueils de notes offensive-security (par ex. HackTricks), ce privilège est couramment détourné en chargeant un pilote légitimement signé mais exploitable — la technique Capcom.sys en est l'exemple public le mieux documenté — pour exécuter du code arbitraire en espace noyau en tant que NT AUTHORITY\SYSTEM. À partir de là, ajouter le compte courant à Domain Admins ou extraire directement ntds.dit devient trivial.

Étape 3 — De Server Operators au détournement de service

Server Operators hérite des mêmes droits de sauvegarde/restauration que Backup Operators, mais obtient en plus SERVICE_ALL_ACCESS sur la plupart des services d'un DC. L'article de Hacking Articles sur ce groupe détaille comment repointer le chemin binaire d'un service légitime vers un exécutable contrôlé par l'attaquant, puis redémarrer ce service — celui-ci exécute alors la charge utile en tant que SYSTEM. Des recherches publiées sur l'abus de SeRestorePrivilege (couramment atteint via l'appartenance à Server Operators) montrent en outre qu'il permet d'écraser des binaires système protégés et de détourner des DLL de service, offrant au moins trois chemins indépendants depuis une seule appartenance de groupe jusqu'à SYSTEM sur un DC.

Étape 4 — D'Account Operators à la persistance silencieuse

Account Operators ne porte aucun privilège OS, mais ses droits natifs AD sont étendus : créer de nouveaux utilisateurs, réinitialiser la plupart des mots de passe utilisateur, et ajouter ou retirer des membres de la plupart des groupes, à l'échelle du domaine. L'article de Cyber Advisors sur Account Operators le décrit comme souvent « à un pas de Domain Administrator » — le groupe ne peut pas toucher directement Domain Admins, Enterprise Admins ou les autres groupes protégés (ils sont protégés par l'ACL AdminSDHolder), mais il peut librement créer des comptes, s'ajouter à n'importe quel groupe non protégé disposant de droits délégués, et réinitialiser le mot de passe de tout compte qui n'est pas dans un groupe protégé. Cela suffit pour une persistance durable et peu visible, sans jamais toucher à un groupe Tier 0.

🚨 Danger : aucune de ces quatre techniques ne nécessite une divulgation de vulnérabilité, un CVE ou un correctif manquant. Il s'agit du comportement voulu, par conception, des droits utilisateur Windows — le seul « bug » est qu'un compte soit membre du groupe.

Détection

Les changements d'appartenance aux groupes et l'usage des privilèges sont tous deux journalisés nativement — l'écart vient presque toujours du fait que personne ne les surveille.

Croisez tout ce qui précède avec les connexions interactives ou RDP (Event ID 4624, type de connexion 2 ou 10) provenant de ces quatre groupes sur un DC — sous n'importe quel modèle de tiering raisonnable, aucun d'eux ne devrait jamais en avoir besoin. Notre guide de supervision Active Directory sur les Event IDs qui comptent couvre les prérequis de politique d'audit pour tous les événements ci-dessus. Des outils d'énumération continue comme etc-collector, PingCastle et Purple Knight peuvent aussi signaler directement une appartenance non vide à ces groupes, sans attendre qu'un événement de log se déclenche.

Remédiation

1. Gardez les quatre groupes vides. C'est l'état par défaut documenté ; traitez tout ajout comme un changement digne d'un incident, pas comme une délégation de routine.
2. Déléguez de façon ciblée plutôt que d'imbriquer dans des groupes intégrés. Si une équipe a réellement besoin de créer des comptes utilisateur, accordez ce droit via une délégation ACL au niveau OU plutôt que par une appartenance à Account Operators, qui est par conception à l'échelle du domaine.
3. Sortez les tâches de sauvegarde du privilège à l'échelle du domaine. Quand l'outil de sauvegarde le permet, utilisez un compte de service dédié, limité à la cible de sauvegarde spécifique, plutôt qu'un compte humain ou partagé détenant SeBackupPrivilege/SeRestorePrivilege à l'échelle du domaine via Server/Backup Operators.
4. Appliquez un modèle de tiering. Aucun compte admin, helpdesk ou service de Tier 1 ou Tier 2 ne devrait jamais être imbriqué dans un groupe Tier 0 — ces quatre groupes inclus. Notre article Dérive des Accès Privilégiés explique comment l'appartenance imbriquée revient même après un audit propre, et notre guide Durcissement Active Directory couvre où cela s'inscrit dans une séquence de verrouillage plus large.
5. Activez la politique d'audit et alertez dessus. Activez « Auditer l'utilisation des privilèges sensibles » et « Auditer la gestion des groupes de sécurité », transférez les Event IDs 4728/4732/4756/4673 vers votre SIEM, et alertez sur toute occurrence impliquant les SID de ces quatre groupes.
6. Revérifiez régulièrement, pas une seule fois. Ces quatre groupes sont exactement le type de constat qu'une revue plus large des mauvaises configurations de sécurité Active Directory les plus courantes a tendance à révéler en parallèle — intégrez ce contrôle à chaque cycle d'audit récurrent, comme le décrit notre checklist d'audit de sécurité Active Directory, pas à un nettoyage ponctuel.

Comment EtcSec Détecte Cela

Les contrôles ACCOUNT_OPERATORS_MEMBER, BACKUP_OPERATORS_MEMBER, PRINT_OPERATORS_MEMBER et SERVER_OPERATORS_MEMBER d'EtcSec signalent toute appartenance non vide à ces quatre groupes lors de chaque audit AD — la même tolérance quasi nulle documentée par Microsoft. PRIVILEGE_SEBACKUP_ABUSE et PRIVILEGE_SERESTORE_ABUSE détectent séparément les cas où SeBackupPrivilege ou SeRestorePrivilege a été attribué au-delà des valeurs par défaut intégrées via une GPO, l'autre manière dont ces droits finissent entre de mauvaises mains.