Au-delà des ACL : Cartographier les chemins d'élévation de privilèges Windows avec BloodHound

Introduction

Les privilèges Windows sont des droits spéciaux qui accordent aux utilisateurs la capacité d’effectuer des opérations sensibles à l’échelle du système. Dans certains cas spécifiques, ils peuvent même complètement outrepasser les vérifications standards des listes de contrôle d’accès (ACL).

Cet article va décrire l’architecture des access tokens Windows et leurs privilèges associés. Nous verrons également comment BloodHound peut être utilisé pour cartographier ces privilèges de haute valeur à travers un domaine, révélant des chemins cachés vers l’élévation de privilèges.

Access Tokens 101

Avant d'expliquer les vulnérabilités d’élévation de privilèges liées aux privilèges Windows, il est important de comprendre comment fonctionnent les access tokens. Si vous êtes déjà familier avec ces concepts, n’hésitez pas à passer directement à la suite.

Les access tokens sont des objets Windows qui décrivent le contexte de sécurité d’un processus ou d’un thread. Ils sont utilisés pour représenter l’identité d’un utilisateur sur une machine. Voici une liste non exhaustive des attributs que possèdent ces tokens :

• SID : L’identifiant unique de l’utilisateur représenté par le jeton.
• Type : Le type d’access token (Primary ou Impersonation).
• Groupes : Les groupes de l’utilisateur décrits par le token.
• Privilèges : Les privilèges de l’utilisateur, c’est le champ d’intérêt principal dans notre cas.

Les access tokens peuvent facilement être inspectés en utilisant Process Hacker :

Chaque fois qu’un processus ou un thread tente d’accéder à une ressource comme un fichier, une clé de registre ou tout objet sécurisable avec une DACL, le noyau Windows vérifie l’access token du thread ou processus performant l’action par rapport à la DACL de l’objet auquel on accède pour déterminer s’il faut accorder ou refuser l’accès.

Une Discretionary Access Control List (DACL) est un type d’ACL. Une ACL est une structure Windows qui contient plusieurs entrées de contrôle d’accès (ACE). Dans le contexte d’une DACL, les ACE sont utilisées pour déterminer si un utilisateur devrait être autorisé ou non à effectuer une action sur un objet et fonctionnent selon le schéma (simplifié) suivant :

L’autre type possible d’ACL est appelé System Access Control List (SACL), elle fonctionne de la même manière qu’une DACL sauf que son but est de journaliser les accès.

C’est ainsi que la vérification d’accès sur Windows fonctionne habituellement. Cependant, comme toujours, il y a des exceptions. De telles exceptions se produisent à cause des privilèges Windows, qui peuvent permettre de complètement contourner les vérifications ACL ! Les implications sont détaillées dans la section suivante.

Privilèges des access tokens

Alors que les DACL déterminent les droits qu’un utilisateur possède afin d’interagir avec un objet, les privilèges opèrent à un niveau différent.

Un privilège est un droit spécial accordé à un compte pour effectuer une opération sensible à l’échelle du système. Certains privilèges permettent de complètement contourner les vérifications ACL.

Par exemple, si l’access token d’un utilisateur inclut le privilège SeBackupPrivilege, qui permet de sauvegarder des fichiers et répertoires, cet utilisateur sera capable de lire n’importe quel fichier sur le système, même si la DACL du fichier lui refuse explicitement l’accès. Windows accorde ce droit pour s’assurer que les logiciels de sauvegarde peuvent fonctionner indépendamment des permissions individuelles des fichiers.

Voyons maintenant comment certains privilèges peuvent être exploités afin d’effectuer de l’élévation de privilège local.

SeDebugPrivilege

SeDebugPrivilege est un bon exemple de privilège qui peut être facilement exploité, comme son nom le suggère, il a été créé pour permettre le débogage d’objets Windows tels que les processus ou les threads. Ce privilège permet à son propriétaire d'entièrement contourner les vérifications liées à l’obtention d’un handle sur un processus ou un thread. Ainsi, grâce à ce privilège, vous pouvez obtenir un handle sur n’importe quel processus ou thread. Ce handle peut ensuite être utilisé pour effectuer des actions sur le processus ou le thread, comme le terminer, lire sa mémoire, changer son access token, etc.

Comme vous l’avez peut-être deviné, ce privilège laisse à un attaquant de multiples possibilités pour élever ses privilèges, voici une liste non exhaustive :

• Écrire un shellcode dans la mémoire d’un processus privilégié puis créer un thread pour exécuter ce shellcode. Le shellcode s’exécutera avec les mêmes privilèges que le processus ciblé.
• Lire la mémoire de LSASS et utiliser mimikatz pour récupérer les identifiants.

Une autre approche pourrait être de récupérer l’access token d’un processus en utilisant advapi32!OpenProcessToken puis d’emprunter l’identité de ce token. Cependant, avoir accès à un token ne signifie pas que vous pouvez l’utiliser. En effet, les vérifications d’attribution de token sont strictes et restrictives, empêchant cette approche. Heureusement, cette vérification d’attribution de token peut être contournée en utilisant le privilège SeImpersonatePrivilege ou SeAssignPrimaryTokenPrivilege comme démontré dans la section suivante.

SeImpersonatePrivilege & SeAssignPrimaryTokenPrivilege

Le privilège SeImpersonatePrivilege est un privilège fréquemment exploité par les attaquants afin d’élever leurs privilèges. En effet, ce privilège est souvent utilisé par IIS, MSSQL et d’autres services Windows. Ainsi, lorsqu’un attaquant parvient à exécuter du code à distance sur une machine Windows via ces services, l’attaquant obtient généralement ce privilège. Ce privilège permet à un thread d’emprunter l’identité de l’access token de n’importe quel utilisateur.

Cependant, comment un tel token peut-il être récupéré ? Comme nous l’avons vu, si nous avons le privilège SeDebugPrivilege, nous pouvons facilement en obtenir un en utilisant advapi32!OpenProcessToken mais que faire si nous ne l’avons pas ? Dans de tels cas, les exploits de la famille Potato peuvent être utilisés. Ils consistent généralement à contraindre un processus privilégié à s’authentifier auprès d’un serveur contrôlé par l’attaquant et à emprunter l’identité du token du processus privilégié.

Le privilège SeAssignPrimaryTokenPrivilege fonctionne de manière similaire au privilège SeImpersonatePrivilege, mais avec une différence mineure : le type de token utilisable. En effet, SeImpersonatePrivilege permet à un thread d’adopter temporairement un access token de type Impersonation tandis que SeAssignPrimaryTokenPrivilege permet la création d’un nouveau processus utilisant un access token de type Primary.

Un access token de type Primary est associé à un processus et représente le contexte de sécurité de l’utilisateur exécutant ce processus, alors qu’un access token de type Impersonation est utilisé par un thread au sein d’un processus pour adopter temporairement un contexte de sécurité différent, typiquement pour accéder à des ressources au nom d’un client.

Il existe beaucoup d’autres privilèges intéressants comme SeLoadDriverPrivilege, SeBackupPrivilege, SeCreateTokenPrivilege, etc. qui peuvent être exploités pour l’élévation de privilèges, mais ils ne seront pas couverts dans cet article. Parlons maintenant des droits d’ouverture de session.

Droits d’ouverture de session

Alors que les privilèges déterminent ce qu’un processus peut faire une fois qu’il est en cours d’exécution, les droits d’ouverture de session définissent comment un compte utilisateur est autorisé à obtenir un accès initial à un ordinateur. Ces droits sont appliqués en utilisant des politiques de sécurité via la Local Security Authority (LSA). Si un utilisateur n’a pas le droit d’ouverture de session nécessaire, la LSA rejettera la tentative d’ouverture de session avant même qu’un access token ne soit généré, empêchant efficacement l’utilisateur d’effectuer toute action sur le système.

Voici la liste des droits d’ouverture de session disponibles et leur effet :

• SeInteractiveLogonRight : Ce droit détermine quels comptes peuvent ouvrir une session localement sur un ordinateur.
• SeRemoteInteractiveLogonRight : Ce droit détermine quels comptes peuvent ouvrir une session à distance en utilisant par exemple le protocole de bureau à distance (RDP).
• SeNetworkLogonRight : Ce droit est utilisé pour permettre d’accéder à un ordinateur depuis le réseau (par ex. accéder aux partages, interfaces RPC).
• SeServiceLogonRight : Cela permet à un compte d’ouvrir une session en tant que service, ceci est vital pour les comptes de service car cela leur permet de s’exécuter en tant que services en arrière-plan. Cela ne signifie pas que le compte peut créer ou démarrer des services.
• SeBatchLogonRight : Cela permet à un compte d’être utilisé par une tâche planifiée. Cela ne signifie pas que le compte peut créer de nouvelles tâches planifiées.

D’autre part, tous ces droits ont leur opposé qui refuse l’authentification à la place (par ex. SeDenyInteractiveLogonRight, SeDenyNetworkLogonRight, etc.), les droits de refus ont la priorité sur les droits d’autorisation.

Bien que ces droits ne puissent pas être exploités, ils sont importants à comprendre car ils définissent la manière dont vous pouvez accéder aux systèmes. Avoir une bonne compréhension de ces droits peut être encore plus impactant pour les défenseurs, car s’ils sont bien configurés, ils peuvent aider à empêcher le mouvement latéral.

Par exemple, dans mon lab, l’utilisateur nioz est administrateur de domaine et devrait donc par défaut pouvoir accéder à n’importe quelle machine via le réseau. Cependant, le privilège SeDenyNetworkLogonRight a été ajouté à cet utilisateur sur la machine pki. Ceci empêche cet utilisateur de pouvoir accéder à ses partages SMB et RPC et est un moyen vraiment efficace d'empêcher le mouvement latéral pour les défenseurs.

Ceci empêche ce compte d’effectuer des techniques de mouvement latéral telles que PsExec car l’utilisateur ne peut pas créer le service ni déposer un fichier via SMB :

Restreindre les privilèges via le contrôle de compte d’utilisateur (UAC)

Le User Account Control (UAC) est une fonctionnalité Windows bien connue qui est utilisée pour appliquer le principe du moindre privilège aux processus. Son objectif est de s’assurer que les programmes s’exécutent avec les permissions minimales dont ils ont besoin pour fonctionner. Lorsqu’un programme veut effectuer une action qui pourrait affecter l’ensemble du système (comme installer un logiciel ou modifier un paramètre système), l’UAC intervient et demande la permission à l’utilisateur.

Lorsqu’un utilisateur privilégié ouvre une session interactive avec succès, le processus lsass.exe, qui gère l’authentification de l’utilisateur, va créer deux access tokens pour la session.

Le premier est un access token hautement privilégié représentant le contexte de sécurité complet de l’utilisateur.

Le second token est filtré et créé en passant le token privilégié à travers la fonction ntdll!NtFilterToken. Cet appel supprime les privilèges sensibles et définit les groupes SID administratifs en "Refus uniquement" pour créer un access token peu privilégié. Ce token est ensuite utilisé pour créer un processus explorer.exe pour la session de l’utilisateur.

L’access token d’un processus explorer.exe peut être observé en utilisant Process Hacker :

explorer.exe sera le processus parent des processus nouvellement créés. Comme tous les processus Windows héritent de l’access token de leur parent par défaut, ceux-ci seront peu privilégiés également. Ainsi, lorsque vous recherchez des opportunités d’élévation de privilèges locaux, il faut toujours lister les privilèges de votre token dans un contexte élevé. Sinon, vous manquerez des privilèges impactants.

Pour créer un nouveau processus avec un token hautement privilégié, vous devez “Exécuter le processus en tant qu’administrateur”. Ensuite, la demande est traitée par le Application Information Service qui lance le bureau UI de consentement sécurisé et affiche la fameuse invite UAC. L’utilisateur doit alors autoriser l’action en cliquant sur “Oui” ou en fournissant des identifiants (si configuré de cette façon). Si l'action est autorisée, le système récupère l’access token original et non filtré qui a été généré lors de l’ouverture de session et l'utilise pour lancer le processus.

Cependant, malgré le fait que cette architecture puisse paraître sécurisée, l’UAC n’a jamais vraiment été un problème pour les attaquants car il est sujet à de nombreux contournements.

Collecte des privilèges

Maintenant que les impacts des privilèges et des droits d’ouverture de session sur l’environnement Windows ont été expliqués, voyons comment il est possible de collecter à distance ces droits. Il existe deux méthodes principales pour collecter ces droits, ces méthodes ont été implémentées via cette Pull Request SharpHoundCommon :

• Se connecter à chaque système à distance via RPC et demander à la LSA pour chaque privilège utilisateur en utilisant par exemple l’API Windows advapi32!LsaEnumerateAccountRights.
• Analyser les GPO du domaine et obtenir les privilèges depuis le fichier GptTmpl.inf.

Les deux méthodes ont des avantages et des inconvénients. Par exemple se connecter à distance à chaque système est bruyant et nécessite des privilèges d’administrateur local sur la machine. De l'autre côté, l'énumération via GPO est furtive et ne nécessite qu’un utilisateur peu privilégié. Cependant, vous pourriez manquer certains privilèges s’ils n’ont pas été appliqués via des GPO.

Voyons à présent comment fonctionnent ces méthodes en détails.

Collecter les privilèges en parsant les GPO

Collecter les privilèges en parsant les GPO est relativement facile et peut être fait avec quelques requêtes LDAP. Pour cette démonstration, nous effectuerons ces requêtes manuellement avec ldeep.

La première étape consiste à obtenir les GPO du domaine et leur emplacement.

$ ldeep ldap -u lowpriv -p [REDACTED] -d lab.local -s ldap://192.168.90.212 search "(objectCategory=groupPolicyContainer)" displayname,gPCFileSysPath
[{
  "displayName": "LocalPrivileges",
  "dn": "CN={61BAD2C5-75EE-425F-A839-7F2C73F9026C},CN=Policies,CN=System,DC=lab,DC=local",
  "gPCFileSysPath": "\\\\lab.local\\SysVol\\lab.local\\Policies\\{61BAD2C5-75EE-425F-A839-7F2C73F9026C}"
},
{
  "displayName": "Default Domain Controllers Policy",
  "dn": "CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=lab,DC=local",
  "gPCFileSysPath": "\\\\lab.local\\sysvol\\lab.local\\Policies\\{6AC1786C-016F-11D2-945F-00C04fB984F9}"
},
{
  "displayName": "Default Domain Policy",
  "dn": "CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=lab,DC=local",
  "gPCFileSysPath": "\\\\lab.local\\sysvol\\lab.local\\Policies\\{31B2F340-016D-11D2-945F-00C04FB984F9}"
}]

Une fois l’emplacement des GPO connu, il est possible d’obtenir le fichier GptTmpl.inf de chaque GPO et de vérifier si des privilèges y sont définis. Ce fichier est situé dans le répertoire \\dc01.lab.local\SYSVOL\lab.local\Policies\{61BAD2C5-75EE-425F-A839-7F2C73F9026C}\MACHINE\Microsoft\Windows NT\SecEdit.

$ smbclient.py lab.local/lowpriv:[REDACTED]@192.168.90.212
# cd lab.local\Policies\{61BAD2C5-75EE-425F-A839-7F2C73F9026C}\MACHINE\Microsoft\Windows NT\SecEdit\
# cat GptTmpl.inf
[Unicode]
Unicode=yes
[Registry Values]
MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity=4,1
MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal=4,1
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature=4,1
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature=4,1
[Privilege Rights]
SeAssignPrimaryTokenPrivilege = *S-1-5-20,*S-1-5-19
SeAuditPrivilege = *S-1-5-20,*S-1-5-19
SeBackupPrivilege = *S-1-5-32-549,*S-1-5-32-551,*S-1-5-32-544
SeBatchLogonRight = *S-1-5-32-559,*S-1-5-32-551,*S-1-5-32-544
SeChangeNotifyPrivilege = *S-1-5-32-554,*S-1-5-11,*S-1-5-32-544,*S-1-5-20,*S-1-5-19,*S-1-1-0
SeCreatePagefilePrivilege = *S-1-5-32-544
SeDebugPrivilege = *S-1-5-32-544
SeIncreaseBasePriorityPrivilege = *S-1-5-90-0,*S-1-5-32-544
SeIncreaseQuotaPrivilege = *S-1-5-32-544,*S-1-5-20,*S-1-5-19
SeInteractiveLogonRight = *S-1-5-9,*S-1-5-32-550,*S-1-5-32-549,*S-1-5-32-548,*S-1-5-32-551,*S-1-5-32-544
SeLoadDriverPrivilege = *S-1-5-32-550,*S-1-5-32-544
SeMachineAccountPrivilege = *S-1-5-11
SeNetworkLogonRight = *S-1-5-32-554,*S-1-5-9,*S-1-5-11,*S-1-5-32-544,*S-1-1-0
SeProfileSingleProcessPrivilege = *S-1-5-32-544
SeRemoteShutdownPrivilege = *S-1-5-32-549,*S-1-5-32-544
SeRestorePrivilege = *S-1-5-32-549,*S-1-5-32-551,*S-1-5-32-544
SeSecurityPrivilege = *S-1-5-32-544
SeShutdownPrivilege = *S-1-5-32-550,*S-1-5-32-549,*S-1-5-32-551,*S-1-5-32-544
SeSystemEnvironmentPrivilege = *S-1-5-32-544
SeSystemProfilePrivilege = *S-1-5-80-3139157870-2983391045-3678747466-658725712-1809340420,*S-1-5-32-544
SeSystemTimePrivilege = *S-1-5-32-549,*S-1-5-32-544,*S-1-5-19
SeTakeOwnershipPrivilege = *S-1-5-32-544
SeUndockPrivilege = *S-1-5-32-544
SeEnableDelegationPrivilege = *S-1-5-32-544
[Version]
signature="$CHICAGO$"
Revision=1

Comme vous pouvez le voir, la GPO LocalPrivileges possède un fichier GptTmpl.inf, ce qui n’est pas forcément le cas de toutes les GPO. Ce fichier est un Security Configuration File et est donc composé de sections et de paires clé-valeur. Les sections définies dans ce fichier peuvent varier mais dans le contexte de cet article, seule la section Privilege Rights est intéressante : les noms de privilèges sont associés à une liste séparée par des virgules de Security Identifiers (SID).

L’étape suivante consiste à interroger la propriété gPLink des OU pour savoir à quelles OU les GPO sont associées.

$ ldeep ldap -u lowpriv -p [REDACTED] -d lab.local -s ldap://192.168.90.212 search "(&(objectCategory=organizationalUnit)(gPLink=*))" gPLink
[{
  "dn": "OU=AmazingComputers,DC=lab,DC=local",
  "gPLink": "[LDAP://cn={61BAD2C5-75EE-425F-A839-7F2C73F9026C},cn=policies,cn=system,DC=lab,DC=local;0]"
},
{
  "dn": "OU=Domain Controllers,DC=lab,DC=local",
  "gPLink": "[LDAP://CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=lab,DC=local;0]"
}]

Dans notre cas, nous pouvons voir que la GPO LocalPrivileges est liée à l’OU AmazingComputers. Enfin, nous pouvons lister les ordinateurs de cette OU :

$ ldeep ldap -u lowpriv -p [REDACTED] -d lab.local -s ldap://192.168.90.212 -b "OU=AmazingComputers,DC=lab,DC=local" search "(objectCategory=computer)" sAMAccountName
[{
  "dn": "CN=SCCM,OU=AmazingComputers,DC=lab,DC=local",
  "sAMAccountName": "SCCM$"
},
{
  "dn": "CN=PKI,OU=AmazingComputers,DC=lab,DC=local",
  "sAMAccountName": "PKI$"
}]

En itérant ce processus sur toutes les GPO, nous aurons connaissance des privilèges appliqués aux utilisateurs sur toutes les machines du domaine.

Se connecter à chaque système à distance pour cartographier les privilèges locaux

L’autre moyen fiable de cartographier les privilèges locaux est de se connecter directement aux machines et d’interroger la LSA. Cela peut être fait via la fonction suivante :

NTSTATUS LsaEnumerateAccountsWithUserRight(
  LSA_HANDLE          PolicyHandle,
  PLSA_UNICODE_STRING UserRight,
  PVOID               *Buffer,
  PULONG              CountReturned
);

Cette fonction requiert un handle vers un objet Local Security Policy et renvoie les utilisateurs qui possèdent le privilège interrogé. Ainsi, pour énumérer tous les utilisateurs avec des privilèges locaux sur une machine, vous devez parcourir une liste de privilèges et appeler cette fonction plusieurs fois.

Manipuler les privilèges en utilisant BloodHound

Voyons maintenant un exemple sur la façon dont BloodHound peut être utilisé pour énumérer les privilèges puis les exploiter.

Comme on peut le voir ci-dessous, l’utilisateur synacktiv a le privilège SeBackupPrivilege et le droit CanRDP sur les machines PKI.LAB.LOCAL et SCCM.LAB.LOCAL. Comme le SeBackupPrivilege permet à son propriétaire de lire n’importe quel fichier ou ruche du registre, il peut être exploité pour obtenir des privilèges administratifs sur une machine en lisant des ruches sensibles telles que SAM et SYSTEM. Dans notre scénario, nous allons d’abord accéder à la machine en utilisant RDP puis effectuer une sauvegarde des ruches SAM et SYSTEM pour obtenir le hash NT de l’administrateur local.

La première étape consiste à se connecter à la machine en utilisant RDP :

Une fois cela fait, lancez une instance PowerShell élevée (sinon votre jeton d’accès n’aura pas SeBackupPrivilege).

Ensuite, transférez les ruches vers votre système attaquant et utilisez secretsdumps.py pour les parser :

Conclusion

Dans cet article, nous avons expliqué le fonctionnement interne des jetons d’accès Windows et exploré comment des privilèges spécifiques modifient fondamentalement le contexte de sécurité d’un utilisateur, leur permettant de contourner les restrictions ACL traditionnelles.

D’autre part, les droits d’ouverture de session peuvent être tout aussi utiles pour les défenseurs. En effet, en contrôlant soigneusement ceux-ci, les organisations peuvent considérablement diminuer les chances qu’un attaquant pivote à travers leur infrastructure Active Directory. Notre Pull Request BloodHound permet aux attaquants comme aux défenseurs d’identifier les opportunités d’élévation de privilèges locaux via les privilèges Windows et de voir les chemins d’attaque associés.