Comptes, SID et droits sous Windows
Qui est qui pour Windows : les comptes locaux et de domaine, les SID, les jetons d'accès, l'UAC et les types d'ouverture de session.
Elouan
Série Systèmes Windows et Linux · article 2 sur 6
Quand on enquête sur une machine Windows, deux questions reviennent sans arrêt : qui a fait l’action, et avec quels droits ? Pour y répondre, il faut comprendre comment Windows identifie un utilisateur, ce qu’il lui donne en ouvrant sa session, et comment il trace cette ouverture.
Comptes locaux et comptes de domaine
Un compte Windows peut exister à deux endroits :
- Localement, sur une seule machine. Les comptes locaux et l’empreinte de leur mot de passe (le hash NT) sont stockés dans la base SAM (
C:\Windows\System32\config\SAM). - Dans un domaine Active Directory, géré par les contrôleurs de domaine. Le même compte peut alors ouvrir une session sur toutes les machines du domaine (la série Active Directory y revient en détail).
Quelques comptes spéciaux existent sur toutes les machines :
| Compte | Rôle |
|---|---|
| SYSTEM (LocalSystem) | Le compte le plus puissant sur la machine, utilisé par le système et beaucoup de services |
| LOCAL SERVICE | Compte de service aux droits limités, s’authentifie anonymement sur le réseau |
| NETWORK SERVICE | Compte de service aux droits limités, s’authentifie sur le réseau avec le compte de la machine |
| Administrateur intégré | Compte local d’administration, souvent désactivé |
| Invité | Désactivé par défaut |
Le SID : la vraie identité
Windows ne se fie jamais au nom d’un compte. Il utilise le SID (Security Identifier), un identifiant unique attribué à la création du compte et qui ne change jamais, même si on renomme le compte.
S-1-5-21-3623811015-3361044348-30300820-1013
│ │ │ └──────────── identifiant du domaine ou de la machine ─┘ └─ RID
│ │ └─ autorité NT
│ └─ révision
└─ « c'est un SID »La dernière partie, le RID (Relative Identifier), identifie le compte dans son domaine. Certains RID sont fixes :
| RID | Compte ou groupe |
|---|---|
| 500 | Administrateur intégré |
| 501 | Invité |
| 512 | Admins du domaine |
| 513 | Utilisateurs du domaine |
| 519 | Administrateurs de l’entreprise |
Et certains SID sont identiques sur toutes les machines :
| SID | Signification |
|---|---|
S-1-5-18 | SYSTEM |
S-1-5-19 | LOCAL SERVICE |
S-1-5-20 | NETWORK SERVICE |
S-1-5-32-544 | Groupe local Administrateurs |
S-1-5-32-545 | Groupe local Utilisateurs |
Renommer « Administrateur » ne cache rien
Le compte renommé garde son SID terminé par 500. Un attaquant le retrouve en une commande. La vraie protection est ailleurs : un mot de passe unique par machine avec LAPS, et l’interdiction pour les comptes locaux de se connecter par le réseau.
Le jeton d’accès
Quand un utilisateur ouvre sa session, lsass.exe vérifie ses identifiants puis construit un jeton d’accès (access token). Chaque processus qu’il lance hérite de ce jeton. Il contient :
- le SID de l’utilisateur et ceux de tous ses groupes ;
- ses privilèges (des droits spéciaux sur le système) ;
- son niveau d’intégrité.
Quand un processus veut ouvrir un fichier, une clé de registre ou un autre processus, Windows compare le jeton avec la liste de contrôle d’accès (ACL) de l’objet.
Les privilèges sensibles
Certains privilèges suffisent presque à prendre le contrôle d’une machine :
| Privilège | Ce qu’il permet | Pourquoi c’est sensible |
|---|---|---|
| SeDebugPrivilege | Ouvrir n’importe quel processus | Lire la mémoire de lsass.exe |
| SeImpersonatePrivilege | Agir avec l’identité d’un autre client | Base des élévations de type « Potato » depuis un compte de service |
| SeBackupPrivilege | Lire n’importe quel fichier pour le sauvegarder | Copier la base SAM ou NTDS.dit |
| SeTakeOwnershipPrivilege | Devenir propriétaire de n’importe quel objet | Contourner les ACL |
| SeLoadDriverPrivilege | Charger un pilote | Charger un pilote vulnérable pour agir dans le noyau |
L’UAC et les niveaux d’intégrité
Depuis Windows Vista, un membre du groupe Administrateurs ne travaille pas en permanence avec tous ses droits. Grâce à l’UAC (User Account Control), il reçoit deux jetons :
- un jeton filtré, au niveau d’intégrité moyen, utilisé par défaut ;
- un jeton complet, au niveau élevé, utilisé seulement après une élévation (l’invite « Voulez-vous autoriser… »).
| Niveau d’intégrité | Exemple |
|---|---|
| Faible | Onglet de navigateur en bac à sable |
| Moyen | Programmes d’un utilisateur, ou d’un administrateur non élevé |
| Élevé | Programme « exécuté en tant qu’administrateur » |
| Système | Services tournant en SYSTEM |
Un processus ne peut pas modifier un objet de niveau plus élevé que le sien.
L’UAC n’est pas une frontière de sécurité
C’est Microsoft qui le dit : l’UAC réduit les risques et améliore les habitudes, mais ce n’est pas une frontière de sécurité. Il existe de nombreux contournements connus (technique T1548.002 de MITRE ATT&CK).
Les types d’ouverture de session
Chaque ouverture de session réussie est journalisée (événement 4624, voir l’article sur les journaux Windows), avec un type de logon. C’est l’une des informations les plus utiles d’une enquête.
| Type | Nom | Exemple | Identifiants en mémoire ? |
|---|---|---|---|
| 2 | Interactive | Ouverture de session au clavier | Oui |
| 3 | Network | Accès à un partage, à un serveur web avec authentification Windows | Non |
| 4 | Batch | Tâche planifiée | Oui |
| 5 | Service | Démarrage d’un service avec un compte | Oui |
| 7 | Unlock | Déverrouillage de session | Oui |
| 8 | NetworkCleartext | Authentification réseau avec mot de passe en clair (IIS en Basic) | Oui |
| 9 | NewCredentials | runas /netonly | Oui (pour le réseau) |
| 10 | RemoteInteractive | Bureau à distance (RDP) | Oui |
| 11 | CachedInteractive | Ouverture hors réseau avec des identifiants mis en cache | Oui |
La dernière colonne compte : quand un administrateur ouvre une session interactive ou RDP sur une machine compromise, ses identifiants restent dans la mémoire de lsass.exe et peuvent être volés. Une connexion de type 3 n’en laisse en général pas. C’est l’une des raisons pour lesquelles on demande aux administrateurs de ne pas se connecter en RDP avec un compte d’administration du domaine sur des postes de travail.
Lire une ouverture de session suspecte
Un 4624 de type 10 sur un serveur, à 3 h du matin, depuis l’adresse IP d’un poste utilisateur, avec un compte d’administration : quelqu’un s’est connecté en RDP depuis ce poste. Un 4624 de type 9 lancé par un processus inhabituel peut trahir un pass-the-hash.
Le prochain article montre où Windows enregistre tout ça : les journaux d’événements.
L'essentiel
- Windows n'identifie pas un compte par son nom mais par son SID (Security Identifier), de la forme S-1-5-21-…-RID.
- RID à connaître : 500 = Administrateur intégré, 501 = Invité, 512 = Admins du domaine, 513 = Utilisateurs du domaine, 519 = Administrateurs de l'entreprise.
- SID bien connus : S-1-5-18 = SYSTEM, S-1-5-19 = LOCAL SERVICE, S-1-5-20 = NETWORK SERVICE, S-1-5-32-544 = groupe local Administrateurs.
- Les comptes locaux et leurs empreintes de mot de passe (hash NT) sont dans la base SAM. Les comptes de domaine sont dans Active Directory.
- À l'ouverture de session, chaque processus reçoit un jeton d'accès (access token) : SID de l'utilisateur, groupes, privilèges, niveau d'intégrité.
- Types de logon : 2 interactif, 3 réseau, 4 batch, 5 service, 7 déverrouillage, 8 réseau en clair, 9 nouvelles informations d'identification, 10 RDP, 11 interactif mis en cache.
Idées reçues
On a renommé le compte Administrateur en « support ». Est-il protégé contre les attaques ciblées ?
L'erreur courante. Dire oui, puisque les attaquants ne connaissent plus son nom.
En réalité. Très peu. Le compte garde son SID qui se termine par 500, et ce SID se retrouve facilement. C'est une mesure de complément, pas une protection. Les vraies mesures : un mot de passe unique par machine (LAPS), la désactivation du compte quand c'est possible, et l'interdiction des connexions réseau pour les comptes locaux.
Un utilisateur membre du groupe Administrateurs ouvre une invite de commandes. A-t-elle les droits administrateur ?
L'erreur courante. Répondre oui.
En réalité. Non, pas par défaut. Avec l'UAC, un administrateur reçoit deux jetons : un jeton filtré (niveau d'intégrité moyen) utilisé par défaut, et un jeton complet (niveau élevé) utilisé seulement après une élévation (« Exécuter en tant qu'administrateur »).
L'UAC est-elle une frontière de sécurité ?
L'erreur courante. Dire oui, puisqu'elle bloque l'élévation.
En réalité. Microsoft indique explicitement que non : c'est une fonctionnalité de confort et de réduction des risques, pas une frontière de sécurité. De nombreux contournements existent (UAC bypass, technique T1548.002), et un attaquant qui a déjà le compte d'un administrateur peut souvent s'élever sans invite.
Un événement 4624 avec un type de logon 9 apparaît sur un poste. Qu'est-ce que ça peut indiquer ?
L'erreur courante. Ignorer ce type, peu connu.
En réalité. Le type 9 (NewCredentials) correspond à `runas /netonly` : le processus garde l'identité locale mais utilise d'autres identifiants pour le réseau. C'est légitime pour certains administrateurs, mais c'est aussi la trace laissée par des attaques pass-the-hash avec Mimikatz (sekurlsa::pth). À croiser avec le processus à l'origine et l'utilisateur.
Pourquoi le privilège SeDebugPrivilege est-il si sensible ?
L'erreur courante. Penser que c'est un privilège réservé au débogage sans conséquence.
En réalité. Il permet d'ouvrir n'importe quel processus, y compris ceux de SYSTEM comme lsass.exe, pour lire ou modifier sa mémoire. C'est exactement ce dont un outil de vol d'identifiants a besoin. Il est accordé par défaut aux administrateurs, ce qui explique pourquoi un compte administrateur compromis est si grave.
Tester ses connaissances
Références
- Windows Internals, Part 1 (7e éd.)Pavel Yosifovich, Alex Ionescu, Mark E. Russinovich, David A. Solomon · Microsoft Press
- Windows Security Monitoring : Scenarios and PatternsAndrei Miroshnichenko · Wiley