Comptes intégrés et comptes privilégiés : taxonomie et portée

Règle d'or de clarification DFIR

Il est impératif de ne jamais confondre cinq concepts fondamentalement distincts :

• Compte : une identité de sécurité unique détentrice d’un secret (ex. Administrator, RID 500).
• Groupe : un conteneur d’identités simplifiant l’attribution d’accès (ex. Domain Admins, RID 512).
• Privilège (User Right) : le droit accordé par l’OS d’exécuter une opération système (ex. SeDebugPrivilege).
• Permission : un droit d’accès accordé sur un objet spécifique via une ACL (ex. GenericAll sur une OU).
• Rôle administratif : une fonction organisationnelle résultant de la combinaison des quatre éléments ci-dessus.

Concept

Le système d’exploitation Windows et Active Directory définissent des comptes intégrés (Built-in Accounts) et des groupes hautement privilégiés configurés par défaut pour assurer l’amorçage, la maintenance et l’exécution des composants du système d’exploitation et de l’annuaire.

Ces comptes disposent de prérogatives opérationnelles délimitées par leur contexte d’exécution (local à l’hôte ou global à la forêt).

---

Pourquoi c’est important en DFIR

Les comptes et groupes privilégiés constituent la cible prioritaire des attaquants lors des phases d’élévation de privilèges et de domination :

1. Abus de comptes de service intégrés : un processus s’exécutant sous NETWORK SERVICE ou LOCAL SERVICE peut être détourné pour escalader vers SYSTEM via des vulnérabilités de type Potato (ex. GodPotato, SweetPotato) abusant des privilèges SeImpersonatePrivilege.
2. Élévation furtive via des groupes secondaires : les attaquants ne s’ajoutent pas systématiquement dans Domain Admins. Ils ciblent souvent des groupes moins surveillés mais tout aussi dévastateurs comme Account Operators, Backup Operators (permettant la lecture de ntds.dit via SeBackupPrivilege), ou DnsAdmins (exécution de DLL arbitraire sur les DC).
3. Persistance sur les comptes d’infrastructure : le compte krbtgt (RID 502) est le compte de service central de Kerberos. La compromission de son hash NTLM/clé AES permet de forger des tickets Golden Ticket persistants.

---

Comment ça fonctionne

1. Comptes de service intégrés du système d’exploitation

Sur chaque machine Windows, le système d’exploitation fournit trois identités non interactives pour exécuter les services :

Compte	SID	Mot de passe	Accès Réseau	Privilèges Clés
SYSTEM (LocalSystem)	S-1-5-18	Géré dynamiquement par l’OS	Se présente sur le réseau sous l’identité du compte machine (COMPUTER$)	Tous privilèges OS (SeDebug, SeTcb, SeImpersonate)
LOCAL SERVICE	S-1-5-19	Aucun (contexte interne)	Connexion anonyme / Null Session uniquement	Privilèges restreints, pas de droits administratifs
NETWORK SERVICE	S-1-5-20	Aucun (contexte interne)	Se présente sur le réseau sous l’identité du compte machine (COMPUTER$)	Privilèges restreints, accès réseau authentifié

2. Comptes et groupes d’administration Active Directory

Dans Active Directory, les groupes privilégiés se répartissent selon leur rayon d’action :

               ┌───────────────────────────────┐
               │       Enterprise Admins       │  (Forêt entière)
               └───────────────┬───────────────┘
                               │
               ┌───────────────▼───────────────┐
               │         Domain Admins         │  (Domaine spécifique)
               └───────────────┬───────────────┘
                               │
               ┌───────────────▼───────────────┐
               │    BUILTIN\Administrators     │  (Machine locale ou DC)
               └───────────────────────────────┘

• Enterprise Admins (RID 519) : réside uniquement dans le domaine racine de la forêt. Possède le contrôle total sur le schéma, la configuration de la forêt et tous les domaines enfants.
• Domain Admins (RID 512) : administrateurs du domaine spécifique. Par défaut, membre du groupe local Administrateurs de chaque poste et serveur joint au domaine.
• Administrators (RID 544, S-1-5-32-544) : groupe local présent sur chaque machine. Sur un contrôleur de domaine, ce groupe administre le DC lui-même.
• Schema Admins (RID 518) : autorise la modification de la structure même des classes et attributs d’Active Directory.
• Backup Operators (RID 551) : détient les privilèges SeBackupPrivilege et SeRestorePrivilege. Un attaquant membre de ce groupe peut copier la base ntds.dit même sans droits de lecture dans l’annuaire.
• Account Operators (RID 548) : peut créer et modifier des comptes utilisateurs dans le domaine (hors groupes protégés).

---

Ce qui est possible

• Compromettre un contrôleur de domaine via Backup Operators : l’analyste doit savoir qu’un compte membre de Backup Operators n’a pas besoin d’être Domain Admin pour extraire les secrets du domaine.
• Abuser d’un service s’exécutant en SYSTEM pour agir sur le réseau : si un service tiers sur un serveur applicatif tourne sous LocalSystem, ses requêtes réseau vers d’autres serveurs SMB se font sous l’identité APP01$. Si ce compte machine a des droits spécifiques dans AD, l’attaquant en hérite.
• Restreindre les comptes privilégiés : l’utilisation du groupe de sécurité intégré Protected Users (introduit avec Server 2012 R2) empêche le cache des hashs NTLM en mémoire LSASS et bloque la délégation Kerberos non contrainte.

---

Ce qui n’est pas possible

• Un Domain Admin d’un domaine enfant ne peut pas modifier directement le schéma de la forêt : cette opération requiert l’appartenance au groupe Schema Admins dans le domaine racine.
• LOCAL SERVICE ne peut pas s’authentifier comme la machine sur le réseau : contrairement à NETWORK SERVICE et SYSTEM, il ne dispose pas des credentials de COMPUTER$.
• Déléguer des droits sur un compte protégé sans passer par AdminSDHolder : les membres des groupes privilégiés sont protégés par le processus système SDProp qui écrase périodiquement leurs ACLs par le modèle sécurisé AdminSDHolder.

---

Confusions fréquentes

Pièges d'investigation

1. Croire que SYSTEM est un utilisateur Active Directory : SYSTEM (S-1-5-18) est une identité purement locale au noyau Windows. Il n’existe aucun compte SYSTEM dans ntds.dit. Sur le réseau, un processus SYSTEM s’authentifie toujours avec le compte machine Kerberos (COMPUTER$).
2. Considérer Enterprise Admins et Domain Admins comme équivalents : dans une forêt multidomaines, compromettre un Domain Admin d’un domaine enfant donne accès à ce domaine, mais nécessite une traversée de trust ou un abus de configuration pour remonter au domaine racine (sauf si le SID Filtering est désactivé, voir Fiche 14 : Types of Active Directory Trusts).

---

Exemple concret : l’élévation via SeBackupPrivilege

Lors d’une intrusion, un attaquant obtient un accès sous l’utilisateur CORP\operator1. L’analyste examine les groupes et constate qu’il n’est pas Domain Admin. L’alerte semble mineure.

Pourtant, operator1 est membre de Backup Operators :

1. L’attaquant exécute une session PowerShell avec le privilège SeBackupPrivilege.
2. Il utilise l’API de sauvegarde Windows (via wbadmin ou diskshadow) pour créer un cliché instantané (Volume Shadow Copy) du volume C: sur le contrôleur de domaine.
3. Il copie le fichier verrouillé C:\Windows\NTDS\ntds.dit et la ruche HKLM\SYSTEM.
4. Hors ligne, il extrait les hashs de tous les utilisateurs du domaine, obtenant les hashs du compte Administrator (RID 500) et de krbtgt (RID 502).

L’absence d’appartenance directe à Domain Admins a masqué la criticité absolue de l’accès.

---

Artefacts / traces

Dans les journaux Security.evtx, surveillez l’assignation de privilèges lors de l’ouverture de session et les modifications de groupes :

EventID: 4672 # Privilèges spéciaux attribués à la nouvelle ouverture de session
SubjectUserName: operator1
SubjectUserSid: S-1-5-21-111111111-222222222-333333333-1108
PrivilegeList:
  SeBackupPrivilege
  SeRestorePrivilege
  SeSecurityPrivilege

EventID: 4728 # Membre ajouté à un groupe de sécurité global
TargetUserName: Domain Admins
TargetSid: S-1-5-21-111111111-222222222-333333333-512
MemberName: CN=backdoor_user,OU=Users,DC=corp,DC=local
MemberSid: S-1-5-21-111111111-222222222-333333333-1190

---

Méthodes d’investigation

1. Lister tous les membres des groupes sensibles dans Active Directory :

   $PrivGroups = @("Domain Admins", "Enterprise Admins", "Administrators", "Schema Admins", "Backup Operators", "Account Operators", "DnsAdmins")
   foreach ($Group in $PrivGroups) {
       Get-ADGroupMember -Identity $Group -Recursive | Select-Object @{Name="Group";Expression={$Group}}, Name, SamAccountName, SID
   }

2. Vérifier les comptes protégés par AdminSDHolder :

   Get-ADUser -Filter 'adminCount -eq 1' | Select-Object Name, SamAccountName, SID

---

Points clés à retenir

1. SYSTEM n’est pas un compte Active Directory : sur le réseau, il s’exprime sous l’identité de sa machine, COMPUTERSYSTEM` n’est pas un compte Active Directory : sur le réseau, il s’exprime sous l’identité de sa machine, :
2. Backup Operators équivaut à un accès Domain Admin complet via l’extraction de ntds.dit.
3. Enterprise Admins est la seule véritable autorité suprême de la forêt.
4. La surveillance de l’event ID 4672 permet d’identifier l’usage effectif de privilèges critiques.

---

Références

• Microsoft Learn: Active Directory Built-in Security Groups
• Fiche 01 : local accounts vs domain accounts
• Fiche 04 : local administrator vs domain administrator
• Fiche 09 : privileges vs permissions