Jetons d'accès Windows et contexte de sécurité : le cœur du modèle d'autorisation

Modèle d'exécution du noyau Windows

Sous Windows, les utilisateurs n’exécutent pas de code : seuls les processus exécutent du code.

Lorsqu’une identité s’authentifie, le système crée une session d’ouverture de session et lui associe un jeton d’accès (Access Token). Chaque processus démarré par cet utilisateur hérite d’une copie de ce jeton. C’est ce jeton — et uniquement lui — qui définit le contexte de sécurité utilisé par le noyau pour accorder ou refuser chaque opération.

Concept

Un Jeton d’accès (Access Token) est un objet noyau (nt!_TOKEN) créé par le sous-système de sécurité local (LSASS) lors de l’authentification réussie d’un principal. Il encapsule l’intégralité du contexte de sécurité nécessaire à la prise de décision :

• Le SID de l’utilisateur : identifiant principal du compte.
• Les SIDs de tous les groupes : incluant les groupes locaux, groupes de domaine et Well-Known SIDs résolus lors de la connexion.
• La liste des privilèges (Privileges) : droits système accordés au compte (SeDebugPrivilege, SeImpersonatePrivilege, etc.) avec leur état (Enabled, Disabled).
• Le niveau d’intégrité (Integrity Level) : balise Mandatory Integrity Control (MIC) : untrusted, Low, Medium, High, System.
• Le type de jeton : Primary Token (attaché à un processus) ou Impersonation Token (attaché à un thread pour usurper temporairement l’identité d’un client).
• Le session ID et logon ID : identifiant unique de la session Windows interactive ou distante.

---

Pourquoi c’est important en DFIR

Comprendre la mécanique des jetons d’accès est capital pour reconstituer les attaques en mémoire et les élévations de privilèges :

1. Token impersonation & vol de jeton (T1134) : un attaquant disposant des droits SYSTEM sur un serveur peut inspecter la mémoire de tous les processus, voler le jeton d’un administrateur connecté (via token::elevate dans Mimikatz ou incognito dans Metasploit) et exécuter des commandes sous son identité sans jamais connaître son mot de passe.
2. Impact de l’UAC (User Account Control) : un administrateur local connecté de manière interactive reçoit par défaut un jeton filtré (Filtered Token) de niveau d’intégrité Medium dépourvu de ses privilèges administratifs. Sans élévation UAC (High Integrity), de nombreuses actions forensiques ou malveillantes sont bloquées.
3. Abus de SeImpersonatePrivilege (potato exploits) : tout compte de service (ex: IIS_IUSRS, MSSQLSERVER) disposant de ce privilège peut forcer un processus SYSTEM à s’authentifier auprès de lui pour capturer et usurper son jeton, réalisant une escalade locale immédiate.

---

Comment ça fonctionne

1. Génération et anatomie du jeton

                  ┌───────────────────────────────────────────────┐
                  │                 Access Token                  │
                  ├───────────────────────────────────────────────┤
                  │ User SID    : S-1-5-21-...-1105 (jdoe)        │
                  │ Group SIDs  : S-1-5-21-...-513 (Domain Users) │
                  │               S-1-5-32-544 (Administrators)   │
                  │               S-1-1-0 (Everyone)              │
                  │               S-1-5-11 (Authenticated Users)  │
                  │ Privileges  : SeChangeNotifyPrivilege (En)   │
                  │               SeDebugPrivilege (Disabled)     │
                  │ Integrity   : High (S-1-16-12288)             │
                  │ Token Type  : Primary                         │
                  │ Impersonation Level : SecurityImpersonation   │
                  └───────────────────────────────────────────────┘

Lorsqu’un processus enfant est créé (via CreateProcess), il reçoit par défaut une copie exacte du jeton primaire de son processus parent.

2. Primary token vs impersonation token

• Primary token : assigné au processus lui-même. Utilisé par tous les threads qui n’ont pas spécifiquement adopté un jeton d’usurpation.
• Impersonation token : assigné temporairement à un thread individuel au sein d’un processus serveur (ex: un serveur de fichiers ou un serveur RPC) pour lui permettre d’agir au nom d’un client distant. Il comporte un niveau d’usurpation :
  • SecurityAnonymous : le serveur ne connaît pas l’identité du client.
  • SecurityIdentification : le serveur connaît l’identité et les SIDs du client, mais ne peut pas accéder aux ressources en son nom.
  • SecurityImpersonation : le serveur peut accéder aux ressources locales au nom du client.
  • SecurityDelegation : le serveur peut accéder aux ressources distantes sur le réseau au nom du client (requiert la délégation Kerberos).

---

Ce qui est possible

• Voler le jeton d’un processus existant : avec SeDebugPrivilege ou sous SYSTEM, un attaquant ou un analyste peut dupliquer le jeton d’un autre processus via l’API Win32 DuplicateTokenEx pour lancer un nouveau processus avec ce contexte.
• Activer un privilège désactivé : si un jeton contient un privilège à l’état Disabled, le processus peut l’activer à la demande via AdjustTokenPrivileges sans demander d’autorisation supplémentaire à l’OS.
• Restreindre un jeton : un processus hautement sécurisé (ex: bac à sable de navigateur web Chrome/Edge) peut volontairement retirer des SIDs et des privilèges de son jeton pour créer un Restricted Token de niveau d’intégrité Low.

---

Ce qui n’est pas possible

• Ajouter arbitrairement un nouveau SID dans un jeton existant : une fois le jeton créé par LSASS, il est immuable dans le noyau concernant sa liste de SIDs. Pour obtenir un nouveau SID, il faut se réauthentifier ou dupliquer un autre jeton le possédant déjà.
• Utiliser un impersonation token de niveau Identification pour modifier un fichier : le SRM Windows bloque toute tentative d’accès en écriture si le niveau d’usurpation est inférieur à SecurityImpersonation.
• Franchir le réseau avec un jeton local : un jeton volé localement n’emporte pas les secrets Kerberos du client vers une autre machine sauf si une délégation explicite a été négociée.

---

Confusions fréquentes

Pièges d'investigation

1. Confondre l’identité du processus parent et l’identité du thread : lors de l’analyse d’un incident, constater qu’un processus svchost.exe (exécuté en SYSTEM) a écrit un fichier malveillant peut masquer une attaque par Token Impersonation : le thread responsable agissait sous le jeton d’un utilisateur compromis.
2. Oublier le filtre UAC : lorsqu’un administrateur exécute PowerShell sans cliquer sur « Exécuter en tant qu’administrateur », son jeton est de niveau Medium Integrity et son SID BUILTIN\Administrators est marqué avec l’attribut SE_GROUP_USE_FOR_DENY_ONLY. Il ne peut pas administrer la machine.

---

Exemple concret : l’attaque potato (abus de SeImpersonatePrivilege)

1. L’attaquant compromet une application web vulnérable hébergée sur IIS. Il obtient un shell en tant que NT AUTHORITY\IUSR ou compte de pool applicatif (IIS APPPOOL\DefaultAppPool).
2. L’attaquant exécute whoami /priv et constate la présence de : SeImpersonatePrivilege : activé
3. L’attaquant déploie un outil d’élévation locale (ex: SweetPotato ou PrintSpoofer).
4. L’outil initialise un serveur de canal nommé (Named Pipe) local et contraint un service système fonctionnant en NT AUTHORITY\SYSTEM (ex: le service Spooler ou RPC BITS) à s’y connecter.
5. Dès que le service se connecte, l’outil invoque l’API ImpersonateNamedPipeClient().
6. Le thread de l’attaquant adopte le jeton d’accès de SYSTEM et lance un processus cmd.exe avec un Primary Token SYSTEM complet. L’élévation locale de privilèges est totale.

---

Artefacts / traces

Dans Security.evtx et Sysmon :

• Event ID 4672 (security) : consigne l’attribution de privilèges sensibles lors de la génération initiale du jeton.
• Event ID 4673 / 4674 (security) : consigne l’exercice effectif ou la tentative d’exercice d’un privilège sur un objet.
• Event ID 10 (Sysmon) : capture les accès inter-processus suspectés de vol de jeton (ProcessAccess ciblant lsass.exe avec DesiredAccess: 0x1410 ou 0x1000).

---

Méthodes d’investigation

1. Inspecter les privilèges d’une session en cours :

   whoami /priv
   whoami /groups

2. Analyser les jetons des processus avec process hacker / process explorer :
   • Ouvrir les propriétés d’un processus -> Onglet Security.
   • Vérifier l’User, les Groupes, les Privilèges et le niveau d’intégrité (Integrity Level).
3. Détecter les jetons d’usurpation suspects : Vérifier si un thread possède un token différent de son processus hôte via la colonne Token User dans Process Explorer.

---

Points clés à retenir

1. Le noyau Windows n’évalue jamais un utilisateur mais le jeton d’accès attaché au processus/thread.
2. Le jeton fige la liste des SIDs et privilèges au moment précis de l’authentification.
3. Le privilège SeImpersonatePrivilege permet de convertir un compte de service local en SYSTEM.
4. L’UAC génère deux jetons distincts : un filtré (medium) et un élevé (high). :

---

Références

• Microsoft Learn: Access Tokens Technical Reference
• Fiche 05 : authentication vs authorization
• Fiche 09 : privileges vs permissions