Usurpation de jetons Windows : guide du défenseur pour la détection et le durcissement

Sous Windows, presque toute décision de sécurité se ramène en fin de compte à un petit objet du noyau : le jeton d'accès. Lorsqu'un attaquant qui a déjà pris pied veut passer d'un compte de service à SYSTEM, ou agir en tant qu'administrateur de domaine sans connaître le mot de passe de cette personne, l'usurpation et la manipulation de jetons sont l'une des techniques classiques auxquelles il recourt. Cet article s'adresse aux défenseurs. L'objectif n'est pas d'apprendre à quiconque à compromettre une machine, mais d'expliquer au niveau conceptuel ce que sont les jetons, pourquoi l'usurpation est une fonction légitime et très utilisée et, surtout, comment détecter les abus et durcir le parc afin que la technique devienne bruyante, fragile et facile à arrêter. Tout ce qui suit correspond à la technique MITRE ATT&CK T1134 (Access Token Manipulation).

Ce qu'est réellement un jeton d'accès Windows

Chaque processus et thread sous Windows porte un jeton d'accès. Voyez-le comme un badge signé qui répond à la question que le noyau pose à chaque action sécurisée : qui êtes-vous et qu'avez-vous le droit de faire ? Le jeton contient l'identifiant de sécurité (SID) de l'utilisateur, les SID de tous les groupes auxquels il appartient, une liste de privilèges activés et désactivés (tels que SeDebugPrivilege ou SeImpersonatePrivilege), un niveau d'intégrité et d'autres attributs. Lorsqu'un thread tente d'ouvrir un fichier, de se connecter à un canal nommé ou de démarrer un service, le Moniteur de référence de sécurité compare le jeton au descripteur de sécurité de l'objet. Ce n'est ni un bogue ni une porte dérobée : c'est le fondement de l'autorisation Windows, et cela fonctionne exactement comme prévu.

Deux sortes de jetons importent ici. Un jeton primaire est attaché à un processus et définit son identité de base. Un jeton d'usurpation permet à un seul thread d'agir temporairement au nom d'un autre contexte de sécurité. L'usurpation existe pour de bonnes raisons : un serveur web, de fichiers ou de base de données doit fréquemment effectuer un travail en tant que client connecté, afin que les vérifications d'accès reflètent l'utilisateur réel plutôt que le compte de service hautement privilégié. Windows expose cela via des API et des privilèges documentés. L'abus survient lorsqu'un attaquant réutilise ce même mécanisme pour emprunter une identité plus puissante que celle qu'il détient légitimement.

Comment l'usurpation et la manipulation fonctionnent à haut niveau

Conceptuellement, l'abus de jetons suit quelques schémas. Dans le premier, un attaquant qui contrôle un processus doté de droits d'usurpation amène un client plus privilégié — souvent un service ou le système d'exploitation lui-même — à s'authentifier auprès de quelque chose qu'il contrôle, capture le jeton d'usurpation résultant et l'adopte. Dans le deuxième, un attaquant disposant de droits suffisants duplique un jeton existant appartenant à un autre utilisateur connecté et lance un nouveau processus avec celui-ci. Dans le troisième, des privilèges déjà présents sur un jeton (comme des droits de débogage ou d'usurpation) sont exploités pour atteindre un processus plus privilégié et adopter son contexte.

Le fil conducteur est qu'aucun mot de passe n'est volé et qu'aucune faille de corruption mémoire n'est nécessairement exploitée. L'attaquant utilise des fonctions prévues de Windows avec une identité qu'il ne devrait pas manier. C'est précisément pourquoi la technique est attrayante pour les adversaires et pourquoi la prévention par signatures seule est insuffisante : les appels d'API paraissent ordinaires. La défense doit s'appuyer sur le contexte : quel compte, depuis quelle filiation de processus, à quel moment, faisant quoi ensuite.

Surface d'attaque : les privilèges qui la rendent possible

Une poignée de privilèges Windows permettent l'abus de jetons de manière disproportionnée, et inventorier qui les détient est l'une des activités défensives les plus utiles. SeImpersonatePrivilege et SeAssignPrimaryTokenPrivilege permettent à un processus d'usurper ou d'attribuer des identités de jeton et sont, par défaut, accordés aux comptes de service tels que LOCAL SERVICE, NETWORK SERVICE et les comptes exécutant IIS ou SQL Server. SeDebugPrivilege permet d'ouvrir pratiquement n'importe quel processus, y compris très privilégié, et ne devrait presque jamais être détenu par des utilisateurs ordinaires. SeCreateTokenPrivilege est encore plus sensible et n'est quasiment jamais nécessaire aux applications normales.

Comme ces privilèges sont utilisés légitimement, la question défensive n'est pas « pouvons-nous retirer l'usurpation de Windows » — c'est impossible — mais plutôt « quels comptes non-service, interactifs ou peu fiables ont accumulé ces droits, et pouvons-nous les leur retirer ? » La prolifération de privilèges sur les comptes de service, les groupes d'administrateurs locaux trop permissifs et les identifiants partagés transforment un seul processus compromis à faibles droits en un problème à l'échelle du domaine.

Détection : les journaux et événements qui comptent

Le signal le plus utile à lui seul est le journal de sécurité Windows. Les ouvertures de session réussies sont enregistrées sous l'événement 4624, et le champ type d'ouverture de session est crucial : le type 9 (NewCredentials) et les ouvertures de session d'usurpation inhabituelles méritent un examen, surtout lorsqu'elles proviennent de comptes de service ou machine qui agissent ensuite comme des administrateurs humains. L'événement 4672 (« Privilèges spéciaux attribués à la nouvelle ouverture de session ») se déclenche chaque fois qu'une session se voit accorder des privilèges sensibles comme SeDebugPrivilege ou SeImpersonatePrivilege ; une référence des comptes qui le déclenchent normalement transforme les anomalies en alertes. L'événement 4688 (création de processus) avec audit de ligne de commande permet de reconstituer la filiation des processus : un compte de service qui lance cmd.exe ou powershell.exe en tant que SYSTEM peu après un événement d'usurpation est une piste solide.

Là où Sysmon est déployé, l'ID d'événement 1 (création de processus) enrichit la filiation avec des hachages et des détails du parent, l'ID d'événement 8 (CreateRemoteThread) et l'ID d'événement 10 (ProcessAccess) font apparaître les accès inter-processus vers des cibles sensibles comme lsass.exe, et l'ID d'événement 25 (falsification de processus) signale la manipulation. Les plateformes EDR modernes ajoutent directement une télémétrie au niveau du jeton : elles peuvent signaler quand l'identité effective d'un thread diverge de son propriétaire de processus, quand un jeton est dupliqué et quand un jeton privilégié sert à créer un processus enfant. L'art défensif consiste à corréler tout cela en une histoire plutôt qu'à alerter sur un unique appel d'apparence bénigne.

Ingénierie de détection : transformer la télémétrie en alertes

Les détections efficaces sont comportementales et corrélées. Les règles à forte valeur incluent : un compte de service (LOCAL/NETWORK SERVICE ou une identité de pool d'applications) devenant le parent d'un shell interactif ; un événement 4672 de privilèges spéciaux pour un compte qui n'a jamais eu légitimement besoin de ces privilèges ; un processus dont le SID du jeton de thread ne correspond pas au SID du jeton de processus effectuant des actions sensibles ; et tout handle ouvert vers lsass.exe avec des droits d'accès permettant de lire ou dupliquer des jetons depuis un processus qui n'est pas un produit de sécurité connu. Enrichissez chaque alerte du niveau de l'actif, du type de compte et de l'historique d'authentification récent pour que les analystes trient rapidement.

Construisez ces règles par rapport à une référence. La plupart des environnements ont un ensemble restreint et stable de processus qui usurpent légitimement : agents de sauvegarde, serveurs web, moteurs de base de données, outils de gestion. Énumérez-les, mettez explicitement le comportement attendu en liste d'autorisation et alertez sur la longue traîne. Associez les alertes à une réponse automatisée là où vous lui faites confiance : isoler un hôte, désactiver une session ou forcer la réauthentification d'un administrateur par niveaux peut contenir le mouvement latéral avant qu'il ne se propage.

Atténuation et durcissement

La prévention commence par le moindre privilège. Auditez quels comptes détiennent SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeDebugPrivilege et SeCreateTokenPrivilege, et retirez-les à tout ce qui ne les requiert pas strictement. Utilisez les stratégies d'attribution des droits utilisateur dans la stratégie de groupe pour maintenir les privilèges sensibles épinglés à un ensemble minimal. Adoptez un modèle d'administration par niveaux : les identifiants de domaine et de grande valeur ne doivent jamais ouvrir de session interactive sur des postes de niveau inférieur, car un jeton volé ou usurpé n'est aussi dangereux que les identités présentes sur cette machine.

Protégez les identifiants privilégiés à la source. Ajoutez les comptes sensibles au groupe Utilisateurs protégés et marquez-les comme « sensible et ne peut pas être délégué » afin que leurs jetons ne soient ni mis en cache ni délégués là où ils pourraient être abusés. Activez Credential Guard et la protection de LSASS (RunAsPPL / LSASS en processus protégé) pour rendre bien plus difficile la lecture ou la duplication du matériel d'identifiants et de jetons en mémoire. Restreignez les droits d'administrateur local avec une solution comme LAPS afin qu'un unique point de terminaison compromis n'octroie pas un accès administrateur réutilisable sur tout le parc. Enfin, maintenez les systèmes à jour : plusieurs chemins d'élévation de privilèges qui finissent en abus de jetons commencent par un service non corrigé s'exécutant avec des droits d'usurpation.

Pièges courants et angles morts

La plus grande erreur des défenseurs est de supposer que, l'usurpation étant une fonction normale de Windows, elle ne peut pas être surveillée. Elle le peut — mais seulement si l'audit de la ligne de commande et de la création de processus est réellement activé, si Sysmon ou l'EDR sont déployés de façon cohérente, et si les journaux sont expédiés hors de l'hôte vers un SIEM où la corrélation est possible. Un deuxième piège est la fatigue d'alerte : déclencher sur chaque 4672 sans référence noie les analystes et les entraîne à ignorer le signal. Un troisième est le mélange de niveaux : autoriser un administrateur de domaine à exécuter des outils sur un poste ordinaire « juste cette fois » annule une grande partie de votre durcissement, car le jeton qui y atterrit peut être emprunté. Enfin, n'oubliez pas les comptes de service : ils sont souvent surprivilégiés, rarement renouvelés et presque jamais surveillés d'aussi près que les comptes humains, ce qui en fait la rampe de lancement privilégiée de l'abus de jetons.

Liste de contrôle défensive

Utilisez ceci comme base de départ et adaptez-le à votre environnement : (1) Inventoriez chaque compte et processus détenant SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeDebugPrivilege et SeCreateTokenPrivilege, et élaguez sans pitié. (2) Activez l'audit de création de processus (4688) avec les lignes de commande, et auditez l'usage des privilèges spéciaux (4672). (3) Déployez Sysmon ou un EDR avec des règles pour l'accès inter-processus à lsass.exe et la duplication de jetons. (4) Expédiez tous les journaux de sécurité vers un SIEM et construisez des règles de corrélation fondées sur une référence. (5) Mettez en place une administration par niveaux et interdisez les ouvertures de session de grande valeur sur les hôtes de niveau inférieur. (6) Ajoutez les comptes privilégiés aux Utilisateurs protégés et marquez-les comme non délégables. (7) Activez Credential Guard et la protection de LSASS. (8) Déployez LAPS pour éliminer les mots de passe d'administrateur local partagés. (9) Corrigez rapidement, en priorisant les services s'exécutant avec des privilèges d'usurpation. (10) Répétez la réponse : isolement, révocation de session et réauthentification forcée.

Questions fréquentes

Désactiver l'usurpation est-il une option ? Non. L'usurpation est fondamentale à la façon dont les services Windows servent les clients en toute sécurité ; la supprimer casserait IIS, SQL Server, le partage de fichiers et d'innombrables applications. La bonne approche est le moindre privilège plus la détection, pas la suppression. Si la détection est comportementale, aurai-je des faux positifs ? Quelques-uns, au début. C'est pourquoi la référence compte : énumérez les usurpateurs légitimes de votre environnement, mettez-les explicitement en liste d'autorisation et alertez sur les écarts. En quelques semaines, le bruit chute fortement et les alertes restantes sont à fort signal.

Conclusion

L'usurpation et la manipulation de jetons sont puissantes précisément parce qu'elles se cachent dans une fonctionnalité légitime de Windows : pas de mot de passe cassé, pas d'exploit évident, juste une identité empruntée. C'est exactement pourquoi les défenseurs devraient la traiter comme un problème de détection et de durcissement plutôt que comme quelque chose à bloquer par un contrôle unique. Inventoriez et élaguez les privilèges qui la rendent possible, activez l'audit qui la rend visible, corrélez la télémétrie en alertes comportementales et imposez un modèle par niveaux pour qu'un jeton emprunté ne puisse atteindre vos joyaux de la couronne. Faites cela de façon cohérente et une technique sur laquelle les adversaires comptent pour une élévation de privilèges furtive deviendra l'un des mouvements les plus bruyants et les plus faciles à contenir qu'ils puissent faire.