La semaine dernière au forum InCyber 2024 de Lille (le FIC pour les anciens), nous avons présenté plusieurs retours d’expériences lors de sessions hacking lab. Au programme, partage autour de quelques-unes de nos missions Red Team, IoT, mais également d’un chemin de compromission alternatif que nous avons pu exploiter en condition réelle. Nous vous proposons ce petit article en guise de rattrapage si vous n’étiez pas présent, en attendant que la rediffusion soit disponible sur YouTube.
L’un des chemins de compromission le plus connu des attaquants consiste à obtenir un compte utilisateur sur l’environnement Active Directory, puis d’élever ses privilèges de sorte à compromettre une machine sur laquelle s’est connectée un administrateur de domaine. Il peut ensuite récupérer la mémoire du processus LSASS.exe, pour tenter de récupérer le mot de passe de ce compte et ainsi obtenir les pleins privilèges sur le domaine. Toutefois, ce chemin commence à être bien connu des défenseurs et le processus LSASS.exe est de plus en plus surveillé. Nous avons ainsi décidé de vous présenter un scénario de compromission ne touchant pas à ce processus, de manière à renforcer notre discrétion lors de nos attaques.
Etape 1: Elévation de privilèges locaux
Après l’obtention d’un compte de service (par exemple un compte de service utilisé par le composant MSSQL) sur la machine ciblée, nous cherchons à élever nos privilèges localement sur celle-ci. Nous constatons alors que le compte dispose de privilèges importants et notamment un nous permettant d’usurper l’identité d’un utilisateur après son authentification (SeImpersonatePrivilege).
Pour exploiter ce privilège, nous avons utilisé le code d’exploitation que nous avions développé et présenté lors de la Hackvens 2023 : CoercedPotato ! L’article explicatif est disponible sur le site Hackvens.
Nous disposons à présent des privilèges « NT\SYSTEM » sur le serveur, nous pouvons alors nous authentifier sur le domaine en tant que compte machine du serveur compromis. Cela est un bon début pour notre élévation de privilèges sur le domaine, cependant ce type d’objet a des droits plus limités qu’un compte utilisateur du domaine et notamment sur un composant que nous utiliserons dans la partie 3 de cet article (l’AD-CS).
Etape 2 : Obtention d’un compte de domaine
Nous cherchons à présent un moyen d’élever nos privilèges sur le domaine. Grâce à notre accès privilégié au système, nous listons les AccessTokens présents sur la machine. Afin de vulgariser, ceux-ci peuvent être comparés à des cookies dans l’environnement de Windows. Nous utilisons alors un des AccessTokens découvert, afin d’usurper l’identité d’un compte du domaine et ainsi de réaliser des requêtes sur le réseau interne. Pour cela, nous utilisons l’outil impersonate développé par Aurélien Chalot (@Defte_).
Etape 3 : Elévation de privilèges sur le domaine
Nous disposons d’un compte utilisateur sur le domaine, sans droit spécifique. Nous pouvons alors interagir avec l’AD-CS (PKI Windows), et notamment lister les différents modèles de certificats configurés, via l’outil certify.exe. Nous constatons alors qu’un modèle de certificat enrôlable seulement par un compte utilisateur du domaine, est vulnérable à l’attaque connue ESC1. Cette vulnérabilité permet à n’importe quel utilisateur du domaine d’effectuer une demande de certificat en spécifiant un sujet alternatif (SAN) arbitraire au sein de la demande de signature de certificat (CSR).
Cela nous permet alors d’obtenir un certificat valide pour le compte « Administrator », nous permettant de nous authentifier sur ce compte via une demande de ticket d’authentification Kerberos. Nous disposons à présent des pleins privilèges sur le domaine Active Directory sans toucher à la mémoire du processus LSASS.exe !
