En octobre 2023, Microsoft a renforcé les protections liées à certains privilèges sensibles, comme SeDebugPrivilege, notamment en restreignant leur usage dans certains contextes. Ces changements concernent principalement Windows 11 et Windows Server 2022. Ce privilège représente une cible privilégiée, souvent exploitée par les attaquants afin d’augmenter leurs privilèges sur le système.
Lorsqu’une machine est compromise, l’un des premiers objectifs des attaquants est d’obtenir des accès élevés. Dans ce contexte, la gestion des Windows Access Tokens joue un rôle central : ces jetons définissent les droits et permissions des utilisateurs et sont au cœur du mécanisme d’authentification et de contrôle des accès. Une manipulation de ces derniers permet aux attaquants de contourner les protections mises en place, tandis qu’une gestion rigoureuse va limiter les actions malveillantes.
Cet article se propose d’explorer les concepts fondamentaux de ces jetons d’accès (Windows Access Tokens). Qu’est-ce qu’un jeton d’accès, comment fonctionne-t-il, et pourquoi constitue-t-il une cible de choix pour les attaquants ? Nous examinerons les mécanismes qui permettent d’interagir avec ces jetons d’accès, que ce soit pour les énumérer, les dupliquer ou bien les usurper, dans le but de manipuler les permissions d’un système à des fins offensives ou défensives.
Dans la 2nde partie de l’article, nous aborderons un cas d’usage concret d’escalade de privilèges au sein d’un système d’information, illustrant comment un attaquant peut obtenir un accès privilégié en abusant de jetons d’accès. Nous mettrons ainsi en lumière l’un des risques majeurs associés à ces mécanismes.
Que vous soyez un défenseur cherchant à approfondir votre compréhension de ces mécanismes pour sécuriser votre environnement, ou un pentester désireux d’affiner vos techniques offensives, cet article vous propose une introduction essentielle aux Access Tokens, un élément central de la sécurité sous Windows.
Comprendre les Access Tokens sous Windows
Qu’est-ce qu’un Access Token ?
Un Access Token sous Windows (ou jeton d’accès) est un objet système fondamental utilisé pour gérer l’authentification et l’autorisation des utilisateurs et des processus. Il stocke des informations de sécurité essentielles, telles que l’identité de l’utilisateur, les groupes auxquels il appartient et les privilèges qui lui sont associés.
Comment accéder à ces jetons ? Quel est leur rôle dans l’authentification Windows ? Comment sont-ils utilisés dans la gestion de sessions et permissions d’utilisateurs ?
Pour comprendre l’authentification dans les environnements Windows, il est d’abord important de saisir la relation entre ces jetons d’accès et les sessions de connexion.
- Logon Sessions
Une session de connexion (logon session) est une instance d’authentification d’un utilisateur connecté sur un système Windows. Elle commence dès la validation de ses identifiants, après que l’utilisateur ait tapé son mot de passe pour accéder à sa machine, et se termine ensuite, lors de sa déconnexion.
Lorsqu’un utilisateur se connecte à une machine Windows (connexion interactive), il saisit son nom d’utilisateur et son mot de passe. Ces informations sont transmises à la Local Security Authority (LSA), qui se charge alors d’effectuer l’authentification.
1/ Authentification locale
- Si l’utilisateur se connecte avec un compte local, LSA compare les identifiants avec ceux stockés dans la base SAM (Security Account Manager), i.e la base de données locale de Windows contenant les informations des comptes locaux.
2/ Authentification Active Directory
- Si l’utilisateur est membre d’un domaine sur l’Active Directory, la requête est alors transmise au contrôleur de domaine (Domain Controller) le plus proche.
- Ce dernier valide l’authentification et lui génère alors un TGT (Ticket Granting Ticket) via Kerberos ou bien une réponse NTLM selon le contexte.
Une fois authentifié, Windows génère un Access Token représentant le contexte de sécurité de l’utilisateur, qui va permettre de définir les permissions et les privilèges durant cette session.
LogonSessions (Sysinternals) permet de visualiser les sessions de connexion en cours :
LogonSession (Sysinternals)
Pour résumer, lorsqu’un utilisateur s’authentifie avec succès, la Local Security Authority (LSA) crée une session de connexion (logon session) et génère un Access Token représentant le contexte de sécurité de l’utilisateur.
Schéma du mécanisme d’authentification sous Windows
Programming Windows Security, Keith Brown (2000)
- Access Tokens
Un Access Token est un objet qui décrit le contexte de sécurité d’un processus ou d’un thread. Ce jeton est utilisé pour déterminer les droits et privilèges de l’entité associée lorsqu’elle tente d’accéder à un objet sécurisé (“Securable Object”).
Lorsqu’un processus ou un thread interagit avec un tel objet, le système compare les informations contenues dans le jeton d’accès avec la liste de contrôle d’accès (ACL) de l’objet afin de décider si l’accès doit être autorisé ou refusé.
Un jeton d’accès contient plusieurs éléments clés, notamment :
- Un identifiant unique de la session (LUID – Locally Unique Identifier)
- Un ID unique du token, qui est propre à chaque instance
- Le niveau d’intégrité et l’état d’élévation (privilèges élevés)
- Un identifiant de sécurité de l’utilisateur (SID)
- Les SIDs des groupes auxquels l’utilisateur appartient
- La liste des privilèges liés à l’utilisateur et à ses groupes
https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools/tree/main/TokenViewer
Visualisation d’un Access Token
(Process Explorer > Properties > Security)
Un Access Token contient aussi un ensemble de privilèges qui sont définis lors de sa création. Une fois généré, il est impossible d’y ajouter de nouveaux privilèges : seuls ceux déjà inclus pourront être activés ou désactivés.
Qu’est-ce qu’un privilège ?
Un privilège est un droit spécifique qui est accordé à un utilisateur ou à un groupe, permettant d’effectuer certaines actions spéciales sur le système. Par exemple, des opérations telles que : éteindre la machine, charger des pilotes ou modifier l’heure.
Privilèges prédéfinis et gestion
Certains groupes ont des privilèges spécifiques par défaut :
- Les “Administrateurs locaux” ont des droits privilégiés sur le système.
- Les “Backup Operators” ont la capacité de contourner les ACLs afin de réaliser la sauvegarde ou la restauration de fichiers.
- Les “Printer Operators” possèdent des droits liés à la gestion des imprimantes.
Affichage des privilèges d’un utilisateur
Il est possible de visualiser les privilèges d’un utilisateur via la commande suivante :
Affichage des privilèges associés à l’utilisateur courant
PS : La configuration des privilèges se fait dans Stratégies locales (gpedit.msc) dans la rubrique “Attribution des droits utilisateurs”.
Session de connexion et jetons d’accès
La session de connexion (logon session) peut être associée à différents jetons d’accès, chacun correspondant à un contexte spécifique d’exécution. Un Access Token est généralement issu d’une session de connexion (logon session), mais peut être manipulé ou généré indépendamment, en fonction des besoins.
Relation entre l’AuthID et la Logon Session
Un processus doit obligatoirement être associé à un Access Token, car c’est lui qui permet au système d’appliquer les règles de sécurité et de contrôler l’accès aux objets protégés (fichiers, processus, clés de registre). Le jeton va servir à déterminer si une opération est autorisée en fonction des privilèges détenus par le processus.
Interaction avec les jetons d’accès
Les jetons d’accès agissent comme des proxies ou des extensions de la session de connexion. Ils permettent aux processus et threads d’hériter du contexte de sécurité d’un utilisateur sans interagir directement avec la logon session elle-même.
Un développeur va donc manipuler les Access Tokens pour gérer les permissions et privilèges, plutôt que d’avoir un accès direct à la session de connexion sous-jacente.
Héritage des jetons d’accès
Après l’authentification d’un utilisateur sur sa machine, la Local Security Authority (LSA) génère un Access Token qui définit ses droits et privilèges. Ce jeton est d’abord associé au processus explorer.exe, qui sert de point de départ à la session. Tous les processus lancés ensuite hériteront du jeton primaire du processus parent.
Authentification et héritage des jetons d’accès
Chaque processus détient un handle vers un Access Token. Il est possible de le dupliquer ou le modifier selon les droits obtenus. Cela lui permet de modifier des paramètres de sécurité sans affecter les autres processus en cours d’exécution.
- Restricted Tokens
Certains logiciels, comme par exemple les navigateurs web utilisent des jetons restreints (Restricted Tokens). Cette technique agit comme une sandbox, limitant les risques en cas d’exploitation (ex : vulnérabilités de corruption mémoire). Ces jetons modifiés (CreateRestrictedToken) limitent les permissions du processus ou du thread concerné, restreignant son accès aux objets sensibles et sa capacité à exécuter des opérations privilégiées. Un attaquant n’obtiendra ainsi pas un accès total au système.
Comprendre les Access Tokens : Typologie
Sous Windows, les Access Tokens jouent donc un rôle clé dans la gestion des droits et des privilèges d’un utilisateur. Il en existe principalement deux types :
- Primary Token : Généré par le noyau Windows (kernel), ce jeton représente le contexte de sécurité par défaut d’une session de connexion. Il est associé uniquement à des processus et ne peut être lié à des threads ou autres objets.
- Impersonation Token : Ce jeton permet à un thread d’agir sous l’identité d’un autre utilisateur sans modifier le contexte de sécurité global du processus. Il est utilisé principalement par des services nécessitant un accès temporaire à une ressource avec les droits d’un autre utilisateur.
PS : C’est le mécanisme utilisé par un serveur SMB qui attribue un thread distinct à chaque client et usurpe l’identité du client distant pour appliquer ses permissions (sous réserve que la délégation soit autorisée dans le contexte Kerberos configuré).
Il y a plusieurs niveaux d’usurpation (Impersonation Levels) :
- Anonymous : Accès restreint, aucune information d’identité n’est transmise.
- Identification : Permet d’obtenir les informations d’identité, mais sans avoir la capacité d’exécuter des actions en son nom.
- Impersonation : Permet d’agir sous l’identité d’un autre utilisateur au niveau de la machine locale.
- Delegation : Permet d’agir sous l’identité d’un autre utilisateur, y compris sur des machines distantes.
Ce qui distingue ces types de jetons est le fait que le Primary Token est lié aux processus, tandis que l’Impersonation Token est attribué aux threads et permet une exécution sous un autre contexte de sécurité.
Comprendre les Access Tokens : Privilèges
Sous Windows, un Access Token contient non seulement l’identité de l’utilisateur et ses groupes, mais également une liste de privilèges. Ces privilèges déterminent les actions administratives que le processus ou le thread sera autorisé à effectuer.
L’activation d’un privilège permet d’exécuter des actions autrement restreintes par le système. Voici une liste (non exhaustive) de privilèges parmi les plus courants :
| Nom du privilège | Description |
| SeAssignPrimaryTokenPrivilege | Attribuer un jeton primaire à un processus. |
| SeBackupPrivilege | Effectuer des opérations de sauvegarde. |
| SeShutDownPrivilege | Initier un redémarrage du système. |
| SeDebugPrivilege | Autoriser l’analyse et la modification de la mémoire de n’importe quel processus. |
| SeLoadDriverPrivilege | Charger/décharger un pilote de périphérique. |
L’activation de certains privilèges peut permettre de contourner des vérifications d’accès. Par exemple, le SeBackupPrivilege accorde un accès en lecture à tous les fichiers du système, en ignorant les contrôles ACL lors d’une demande de lecture.
Ce privilège est important pour des applications comme les logiciels de sauvegarde, qui ne devraient pas nécessiter une autorisation explicite sur chaque fichier. Grâce à ce privilège, le compte exécutant l’application peut accéder librement aux fichiers et garantir une sauvegarde complète du système, sans être bloqué par les restrictions.
Comprendre les Access Tokens : Token Integrity Level
Windows définit cinq niveaux d’intégrité principaux : Untrusted, Low, Medium, High et System. Ces niveaux sont appliqués aux objets sécurisables afin de restreindre ou d’accorder certains privilèges en fonction du contexte d’exécution.
Par exemple, l’image suivante illustre un cas où un utilisateur, bien qu’appartenant au groupe des administrateurs locaux, ne peut pas ajouter un nouvel utilisateur au système. Cela est dû au fait que son processus s’exécute avec un jeton d’intégrité Medium, qui est insuffisant pour effectuer cette action.
Tentative d’ajout d’un nouvel utilisateur (jeton d’intégrité Medium)
La manière standard d’exécuter un processus à l’aide d’un jeton de haute intégrité est d’utiliser « Exécuter en tant qu’administrateur » et de répondre à l’invite de l’UAC.
User Account Control (UAC) : C’est un mécanisme de sécurité intégré à Windows qui limite l’exécution des processus nécessitant des privilèges administratifs. Lorsqu’un programme requiert des droits élevés, l’UAC affiche une invite exigeant une validation avant de l’exécuter. Cela limite ainsi les risques d’élévations de privilèges non autorisées, en particulier dans les scénarios de malware ou d’exécution silencieuse.
Comprendre les Access Tokens : Network Authentication
Local Security Authority Subsystem Service (LSASS) conserve les identifiants des utilisateurs connectés afin de permettre un accès transparent aux ressources réseau, évitant ainsi la saisie répétée des informations de connexion. Ces identifiants peuvent être stockés sous différents formats, notamment en texte clair, sous forme de tickets Kerberos ou de hashs NTLM. Windows met en cache ces informations pour chaque session, facilitant ainsi l’authentification aux services réseau.
Authentification réseau : exemple d’accès à un partage SMB
Programming Windows Security, Keith Brown (2000)
Lorsqu’un processus tente d’accéder à une ressource distante, Windows utilise les informations contenues dans l’Access Token pour identifier la session de l’utilisateur et récupérer les identifiants mis en cache. Ces derniers sont ensuite exploités pour authentifier automatiquement l’utilisateur auprès du service distant, lui permettant de se connecter sans ressaisir ses informations d’identification, Single Sign-On (SSO).
Côté serveur cible, l’authentification réseau repose sur un Network Logon Session (qui représente le client distant) ainsi qu’un Impersonation Token.
Cas pratique : Access Token Manipulation (ATT&CK T1134)
Pour la démonstration, le lab utilisé est composé d’une workstation sous Windows, d’un serveur Windows ayant son service SMB activé et d’un contrôleur de domaine.
L’attaque va consister à abuser des tokens afin d’escalader nos privilèges et récupérer un compte administrateur de domaine en capacité d’exécuter des commandes sur le contrôleur de domaine.
Prérequis
Nous disposons initialement d’un accès valide en tant qu’administrateur local sur le serveur SMB. Des sessions d’autres utilisateurs y sont potentiellement actives, ce qui en fait une cible intéressante pour énumérer les jetons d’accès.
Dans un premier temps, on utilise PsExec, outil de Microsoft Sysinternals, pour lancer un invite de commandes en tant que NT AUTHORITY\SYSTEM :
Élévation de privilèges à l’aide de l’outil PsExec
L’idée est donc de lister les Access Tokens des utilisateurs connectés à la machine, en particulier ceux ayant des privilèges élevés.
Plutôt que d’utiliser des outils existants comme Mimikatz ou Incognito, le parti pris pour ce PoC a été de développer un outil personnalisé :
https://github.com/ScrowHacking/Imperson8/tree/master
Cette démarche offre l’avantage de mieux appréhender les interactions avec l’API Windows tout en évitant les potentielles détections, remontées pour des outils publics connus.
Affichage de la commande « help » de l’outil Imperson8
Cet outil présente différentes fonctionnalités : il permet entre autres d’afficher le jeton d’accès utilisé par le processus courant, d’afficher ses privilèges, d’énumérer les processus qui tournent sur le système et d’usurper les tokens d’impersonation présents sur le système, y compris ceux ayant un niveau de délégation élevé.
Affichage du token du processus courant et des privilèges
Lors de cette énumération, un access token appartenant à un utilisateur ayant des droits privilégiés sur le domaine (Domain Admin) a ainsi pu être identifié :
Détection d’un delegation token d’un utilisateur privilégié
Usurpation du token d’un Administrateur de domaine
L’objectif va être d’implémenter une fonction permettant d’usurper l’identité d’un utilisateur privilégié après avoir récupéré son Windows Access Token.
Pour ce faire, la fonction impersonate_token explore les processus actifs afin d’identifier un Delegation Token qui serait exploitable. Une fois identifié, ce token sera dupliqué, puis converti en Primary Token et enfin assigné à la session active.
Enfin, une fois le token attribué à la session, CreateProcessWithTokenW sera utilisé pour exécuter une commande sous l’identité de l’utilisateur usurpé, permettant ainsi une élévation de privilèges (sans connaissance des identifiants de l’utilisateur ciblé).
Fonction permettant l’usurpation via son access token
L’appel à CreateProcessWithTokenW nécessite que le token ait été converti en jeton primaire (Primary Token) et que le processus appelant dispose des privilèges SeAssignPrimaryToken et SeIncreaseQuotaPrivilege.
L’outil exécuté à l’aide de l’option –impersonate permet d’utiliser l’impersonation token de l’utilisateur privilégié détecté précédemment. En usurpant ce token, il est alors possible d’exécuter des actions sous l’identité d’un Administrateur de domaine.
Obtention des droits administrateur de domaine via le token usurpé
Manipulation des tokens : détection et mitigation
La détection des abus de tokens repose principalement sur l’analyse des journaux d’événements. Lorsqu’un attaquant tente d’usurper un token ou d’exécuter une action nécessitant des privilèges élevés, plusieurs événements peuvent être générés. (Ex : assignation de privilèges spéciaux : event 4672, tentative d’opération sensible sur un objet système : event 4673, usurpation de token via runas/psexec : event 4648)
La corrélation de ces événements dans un SIEM ou un EDR permet d’identifier des schémas suspects. Une élévation soudaine vers NT AUTHORITY\SYSTEM, suivie d’une connexion à une machine distante peut, par exemple, révéler une tentative d’usurpation de token. Une attention particulière doit également être portée aux exécutions de processus tels que Mimikatz ou PsExec, souvent employés dans ce type d’attaque.
Certains droits, tels que SeAssignPrimaryToken, SeImpersonate ou SeTcbPrivilege, doivent être limités aux services et comptes qui en ont vraiment besoin. (Principe du moindre privilège).
Depuis Windows 10/Server 2016, il est également recommandé d’activer la protection de LSASS en tant que processus protégé (RunAsPPL), pour empêcher la lecture ou duplication de tokens sensibles.
Enfin, la segmentation des machines constitue une autre mesure clé. Les contrôleurs de domaine et les serveurs critiques doivent être isolés. (Tier Modeling)
Une approche combinant analyse des événements, segmentation des privilèges et restrictions des outils d’exploitation offre une protection efficace contre ces attaques, tout en limitant l’impact potentiel d’une compromission.
Conclusion
Les Access Tokens sont un élément central de l’authentification et de la gestion des privilèges sous Windows. Une mauvaise gestion peut exposer le système à des attaques telles que Pass-the-Token, la duplication de tokens ou l’impersonation, facilitant une élévation de privilèges et des mouvements latéraux au sein du système d’information.
Dans cet article, nous avons expliqué leur fonctionnement et leur rôle dans l’authentification, puis illustré ces éléments par une attaque concrète à travers l’énumération des tokens sur un serveur SMB, l’usurpation de l’access token d’un administrateur de domaine, en finissant par l’exécution de commandes sur le Contrôleur de Domaine.
Pour s’en protéger, il est essentiel de surveiller les événements liés aux tokens, d’appliquer le principe du moindre privilège et de restreindre les droits sensibles (SeAssignPrimaryToken, SeImpersonate, etc). En combinant une approche offensive et défensive, il devient alors possible de mieux identifier et de prévenir ce type d’abus.
Ressources :
https://www.elastic.co/blog/introduction-to-windows-tokens-for-security-practitioners
https://nyameeeain.medium.com/windows-access-token-manipulation-80d4549c5b14
https://github.com/S1ckB0y1337/TokenPlayer
https://www.cyfox.com/blog-posts/investigating-token-impersonation-and-mitigating-token-theft-risks
https://www.youtube.com/watch?v=RMVyYvt0bLY&list=WL&index=73 (Access Token, BlackHat)
https://www.elastic.co/blog/how-attackers-abuse-access-token-manipulation
https://github.com/FSecureLABS/incognito/blob/394545ffb844afcc18e798737cbd070ff3a4eb29/incognito.exe
Pass-the-Token, Mimikatz, Rubeus, Incognito, Seatbelt