SID, RID et identité Windows : le modèle mental fondamental

Modèle mental central en DFIR

Dans le noyau Windows et les protocoles d’autorisation, les chaînes de caractères de noms d’utilisateurs n’existent pas.

Le sous-système de sécurité (SRM - Security Reference Monitor) ne manipule et ne compare strictement que des SIDs. Deux comptes avec le même libellé textuel ont des SIDs différents. Un compte renommé conserve son SID. Si un compte est supprimé puis recréé avec exactement le même nom, il reçoit un nouveau SID et perd tous ses accès antérieurs.

Concept

Un SID (Security Identifier) est une structure de données binaire de longueur variable utilisée par Windows pour identifier de manière universelle et univoque un principal de sécurité :

• Un utilisateur (humain ou compte de service).
• Un groupe de sécurité (local, global, universel).
• Une machine (compte ordinateur COMPUTER$).
• Une autorité spéciale ou un contexte de session (Well-Known SIDs).

Le RID (Relative Identifier) constitue le dernier segment numérique du SID. Il est attribué séquentiellement par l’autorité de sécurité (la machine locale ou le contrôleur de domaine détenant le rôle FSMO RID Master).

---

Pourquoi c’est important en DFIR

Pour un enquêteur en réponse à incident, la maîtrise des SIDs est le seul rempart contre les interprétations erronées :

1. Suppression et recréation de compte (attaque par leurre) : un attaquant qui crée un compte backup_admin, l’utilise, le supprime, puis un administrateur légitime recrée un compte du même nom. Les logs historiques pointent vers l’ancien SID (ex: RID 1142), prouvant que les actions malveillantes n’ont pas été commises par le compte actuel (RID 1185).
2. Investigation sur système hors ligne : lorsqu’on analyse un disque dur ou une ruche de registre sans contrôleur de domaine accessible, Windows ne peut pas traduire les SIDs en noms d’utilisateurs. L’analyste doit savoir lire et décomposer les SIDs bruts.
3. Persistance furtive via sIDHistory : un attaquant exploitant Mimikatz peut injecter le SID du groupe Domain Admins (RID 512) dans l’attribut sIDHistory d’un utilisateur standard. L’utilisateur semble inoffensif dans l’annuaire, mais son jeton d’accès contient le SID administrateur, lui conférant un contrôle total (voir Fiche 18 : Cross-Domain Group Membership and Foreign Security Principals).

---

Comment ça fonctionne

1. Décomposition anatomique d’un SID

Considérons le SID suivant : S-1-5-21-3623811015-3361044348-30300820-1013

S - 1 - 5 - 21 - 3623811015 - 3361044348 - 30300820 - 1013
│   │   │   │   └──────────────────────────────────┘   └── RID (Identifiant Relatif)
│   │   │   │            Domain Identifier (Sub-Authority)
│   │   │   └── Identifiant de sous-autorité non unique (NT Authority)
│   │   └────── Autorité de sécurité (5 = SECURITY_NT_AUTHORITY)
│   └────────── Niveau de révision (toujours 1 dans les versions actuelles)
└────────────── Préfixe littéral du SID

• S : préfixe standard désignant un SID.
• 1 : version de la spécification (Révision 1).
• 5 : identificateur d’autorité (SECURITY_NT_AUTHORITY). D’autres autorités existent : 0 (Null), 1 (World), 2 (Local), 3 (Creator), 4 (Non-unique).
• 21 : indique que la sous-autorité suivante identifie un domaine Active Directory ou une machine locale SAM.
• 3623811015-3361044348-30300820 : le Domain SID. Ce triplet d’entiers 32 bits est généré aléatoirement lors de l’installation de Windows (pour une machine locale) ou lors de la création du domaine Active Directory (sur le premier DC). Tous les comptes d’un même domaine partagent exactement le même Domain SID.
• 1013 : le RID. Identifiant attribué de façon unique au sein de cette autorité.

2. Les RIDs réservés et well-known SIDs

Certains RIDs sont standardisés par Microsoft sur toutes les machines et tous les domaines :

SID / RID	Signification	Portée & Particularité
RID 500	Compte Administrateur intégré	...-500 existe dans chaque SAM et chaque domaine AD.
RID 501	Compte Invité (Guest)	Désactivé par défaut.
RID 502	Compte krbtgt	Présent uniquement sur les domaines Active Directory.
RID 512	Domain Admins	Groupe administrateur global du domaine.
RID 513	Domain Users	Tous les utilisateurs du domaine.
RID 516	Domain Controllers	Tous les contrôleurs de domaine.
RID 519	Enterprise Admins	Présent uniquement dans le domaine racine de la forêt.
S-1-5-18	NT AUTHORITY\SYSTEM	Le système d’exploitation lui-même (LocalSystem).
S-1-5-19	NT AUTHORITY\LOCAL SERVICE	Service local restreint sans accès réseau anonyme.
S-1-5-20	NT AUTHORITY\NETWORK SERVICE	Service local avec identité machine (COMPUTER$) sur le réseau.
S-1-5-32-544	BUILTIN\Administrators	Groupe d’administration locale présent sur chaque machine.

---

Ce qui est possible

• Renommer un compte sans changer son identité : renommer Administrator en Helpdesk_Guest préserve le RID 500. Pour le système d’autorisation, ce compte possède toujours les droits suprêmes.
• Identifier l’autorité émettrice d’un coup d’œil : en comparant les 3 blocs de chiffres précédant le RID, l’analyste détermine immédiatement si deux événements de logs proviennent du même domaine, de deux domaines distincts, ou d’une SAM locale.
• Corréler des artefacts orphelins : lorsqu’une ACL de fichier affiche S-1-5-21-...-1045 au lieu d’un nom d’utilisateur, cela prouve que le compte qui avait reçu ces droits a été supprimé de l’annuaire (ou provient d’un domaine étranger déconnecté).

---

Ce qui n’est pas possible

• Récupérer les permissions en recréant un compte homonyme : si CORP\alice (RID 1105) est supprimée, la recréation de CORP\alice se voit allouer le RID 1106. Elle n’hérite d’aucun des droits ou accès spécifiques attribués au RID 1105.
• Avoir deux fois le même RID dans la même autorité : le gestionnaire de RID garantit l’unicité stricte au sein d’une même machine ou d’un même domaine.
• Falsifier un SID dans un jeton sans privilège élevé : sous Windows, seul le pilote noyau (ou LSASS avec les privilèges SeTcbPrivilege / SYSTEM) peut construire un jeton d’accès contenant des SIDs arbitraires.

---

Confusions fréquentes

Erreurs courantes d'interprétation

1. Confondre S-1-5-32-544 et S-1-5-21-...-512 : S-1-5-32-544 est le groupe local BUILTIN\Administrators (valable sur chaque machine hôte). S-1-5-21-...-512 est le groupe de domaine Domain Admins. Par défaut, Domain Admins est imbriqué dans BUILTIN\Administrators lors de la jonction au domaine, mais ce sont deux SIDs totalement distincts.
2. Croire que la résolution de nom est garantie : les outils DFIR qui traduisent automatiquement les SIDs en noms peuvent échouer si la machine est analysée hors ligne, affichant un SID brut. Ne concluez pas à un artefact corrompu : le SID est la seule valeur canonique.

---

Exemple concret : l’attaque par SIDHistory

Dans un environnement avec deux domaines en relation d’approbation (CHILD.CORP et ROOT.CORP), un attaquant compromet CHILD.CORP. Il souhaite obtenir un accès persistant et invisible sur ROOT.CORP :

1. L’attaquant cible le compte utilisateur ordinaire CHILD\jdoe (SID : S-1-5-21-222-333-444-1102).
2. À l’aide de l’outil Mimikatz (misc::addsid), il injecte dans l’attribut LDAP sIDHistory de jdoe le SID du groupe Domain Admins du domaine racine : S-1-5-21-999-888-777-512.
3. Lorsque jdoe s’authentifie, le KDC génère un jeton Kerberos contenant à la fois son SID principal et tous les SIDs présents dans son sIDHistory.
4. Lors de l’accès à un serveur de fichiers dans ROOT.CORP, le serveur inspecte le jeton, y trouve le SID S-1-5-21-999-888-777-512, et lui accorde un accès administrateur total, bien que l’interface graphique Active Directory n’affiche jdoe que comme simple membre de Domain Users.

Ce vecteur est analysé en profondeur dans la Fiche 18 : cross-domain group membership and foreign security principals et la Fiche 24 : lateral movement across Active Directory domains.

---

Artefacts / traces

Dans les journaux Security.evtx, les événements de modification de compte et de détection de privilèges enregistrent les SIDs :

EventID: 4720 # Compte utilisateur créé
TargetUserName: attacker_backup
TargetSid: S-1-5-21-3623811015-3361044348-30300820-1185   <-- Noter le RID 1185
SubjectUserSid: S-1-5-21-3623811015-3361044348-30300820-500

EventID: 4765 # SID History ajouté (Alerte rouge)
TargetUserName: jdoe
TargetSid: S-1-5-21-222-333-444-1102
SidHistoryValue: S-1-5-21-999-888-777-512                   <-- Injection Domain Admins

---

Méthodes d’investigation

1. Identifier les comptes avec sIDHistory suspect via PowerShell :

   Get-ADUser -Filter 'sidhistory -like "*"' -Properties sidhistory |
     Select-Object Name, SID, @{Name="sIDHistory";Expression={$_.sidhistory}}

2. Convertir un SID en nom en ligne de commande :

   $objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-21-3623811015-3361044348-30300820-500")
   $objUser = $objSID.Translate([System.Security.Principal.NTAccount])
   $objUser.Value

3. Identifier le domain SID d’un domaine :

   (Get-ADDomain).DomainSID.Value

---

Points clés à retenir

1. Le SID est la seule identité reconnue par le sous-système de sécurité de Windows.
2. Le RID (dernier élément du SID) identifie un compte unique au sein de son autorité locale OU de domaine.
3. Le RID 500 est toujours l’administrateur intégré, quel que soit son nom d’affichage OU sa langue.
4. La suppression d’un compte est irréversible en termes de SID : le recréer génère un nouveau RID. :
5. L’attribut sIDHistory permet à un jeton d’emporter des droits issus d’autres domaines OU d’anciens comptes.

---

Références

• Microsoft TechNet: Well-Known SIDs in Windows
• Fiche 01 : local accounts vs domain accounts
• Fiche 06 : Windows access tokens and security context
• Fiche 18 : cross-domain group membership and foreign security principals