Blog

Découvrez le write up de la deuxième partie du WonkaChall 2 !

Part 2 – WINDOWS

Reconnaissance

Dans la partie précédente, nous avions récupéré une configuration VPN sur un bucket AWS. Nous pouvons donc nous connecter au VPN wonka_internal.ovpn.

Une fois connecté, nous cherchons à déterminer les sous-réseaux auxquels nous avons nouvellement accès. Pour cela, nous pouvons regarder les routes qui nous sont poussées.

Le sous-réseau 172.16.42.0/24 semble intéressant, voyons un peu ce qui est vivant là-dessus avec un nmap ping.

Trois machines semblent UP : 172.16.42.5, 172.16.42.11 et 172.16.42.101. Enumérons à présent les services de ces machines.

A en juger par les services en écoute, ces trois machines semblent être des Windows, dont l’une d’elle un possible contrôleur de domaine. Notons le port 8080 ouvert sur 172.16.42.11. Pourrait-il s’agir d’un Tomcat, proie facile ?

Nous confirmons qu’il s’agit de machines Windows dans un domaine FACTORY.

Nous tentons d’accéder au service tournant sur le port 8080 de SRV01-INTRANET et tombons sur une page web qui semble être un Wiki.

Tomcat

Un diagramme intéressant est disponible et donne une bonne vision de l’infra générale de l’entreprise.

Nous apprenons notamment l’existence de plusieurs machines sur un sous-réseau 172.16.69.0/24 et que PC01-DEV est l’ordinateur d’un dev/admin.
Lorsque nous cherchons à accéder à une page qui n’existe pas, nous tombons sur la page d’erreur qui trahit que le service web est bien un Tomcat.

Nous tentons alors d’accéder au manager du Tomcat afin d’essayer de compromettre la machine. Mais le manager n’est pas là.

On énumère alors le service web avec GoBuster et nous trouvons que l’host-manager est actif.

Nous nous rendons sur l’host-manager et tombons sur une basic authentification. Nous donnons les identifiants « tomcat / tomcat ».

Les identifiants sont corrects et nous permettent d’accéder à l’host-manager.

Nous tombons sur internet sur des ressources expliquant qu’il est possible de prendre le contrôle du serveur sous-jacent au Tomcat à l’aide de cette page host-manager, variante du manager classique.

L’idée est simple : faire en sorte que le Tomcat vienne chercher et déployer un war sur un serveur SMB nous appartenant. Le war contient un webshell nous permettant d’exécuter des commandes en tant que NT AUTHORITY\SYSTEM.

De là, nous pourrons venir extraire de la mémoire des identifiants intéressants.

Autre point à prendre en compte : les antivirus. Un war Meterpreter se fera probablement détecter, de même qu’un Mimikatz. Nous utiliserons donc un war fait maison et un procdump afin de réaliser un dump du processus lsass que l’on parsera en local avec Mimikatz.

Mettons donc tout cela dans un répertoire.

Lançons ensuite un serveur SMB pointant dans un répertoire contenant notre war.

Nous venons renseigner le chemin réseau vers notre war à l’host-manager, à savoir \\10.8.0.42\aka.

akerva.factory.lan doit pointer vers l’IP du Tomcat. Nous éditons donc notre /etc/hosts.

Nous cliquons sur Add et voyons le Tomcat venir chercher le war et le déployer sur notre serveur SMB.

Le dossier est créé sur notre serveur SMB.

L’host-manager référence notre application.

On accède à notre webshell via : http://akerva.factory.lan:8080/akerva/cmd.jsp. Nous pouvons ici entrer des commandes comme whoami pour vérifier que nous sommes bien NT AUTHORITY SYSTEM.

Sur le Desktop de l’utilisateur adminServer, nous retrouvons le flag 5.

Tentons maintenant notre procdump.

Nous rappatrions notre dump.

Parsons le dump à l’aide de Mimikatz en local.

Le SHA256 du mot de passe de adminServer est le flag 6.

Bloodhound

Maintenant que nous disposons d’un compte dans le domaine, nous pouvons faire un Bloodhound. Nous prenons bien soin d’utiliser les dernières versions de BloodHound et de SharpHound en date 😉. Nul besoin d’ajouter notre machine Windows au domaine pour exécuter l’ingestor.

Le Bloodhound ne révèle aucun chemin de compromission mais une primitive « AddAllowedToAct » entre un compte « SvcJoinComputerToDom » et le contrôleur de domaine attire notre attention.

Après quelques recherches, nous tombons sur plusieurs ressources sur les Resources-Based Constrained Delegation :

https://posts.specterops.io/a-case-study-in-wagging-the-dog-computer-takeover-2bcb7f94c783

https://binged.it/2kaWdnx

https://beta.hackndo.com/resource-based-constrained-delegation-attack/

Très succinctement, l’idée est de pouvoir réécrire la propriété « AllowedToActOnBehalfOfOtherIdentity » d’une machine pour y placer une structure basée sur le SID d’un compte avec service SPN. Ce dernier pourra alors se faire passer pour n’importe qui auprès de la machine cible et donc la compromettre.

Très succinctement, deux conditions sont nécessaires pour une exploitation RBCD réussie :

• Contrôler un compte avec service SPN
• Pouvoir réécrire la propriété « AllowedToActOnBehalfOfOtherIdentity » du contrôleur de domaine

Pour ce premier point, une technique assez simple est de joindre une machine au domaine (qui aura un SPN par défaut). De base sur Active Directory, tout utilisateur du domaine peut joindre jusqu’à 10 machines dans le domaine. Mais ce n’est pas le cas ici car l’administrateur du domaine a durcit cette configuration. Toutefois, le compte de service SvcJoinComputerToDom semble avoir ce privilège.

Pour le second point, notre Bloodhound indique clairement que SvcJoinComputerToDom a ce droit.

Il nous faut donc ce fameux compte SvcJoinComputerToDom. Nous pouvons imaginer que ce compte de service est créé par l’administrateur du domaine pour déléguer le droit de joindre des machines au domaines à l’adminServer et l’adminWorkstation, sans leur donner accès au compte Administrateur du domaine.

SvcJoinComputerToDom

Nous vérifions donc qu’avec nos identifiants adminServer, nous n’avons pas accès à certaines ressources.

Un dossier « provisioning » est accessible en lecture pour adminServer. Nous récupérons le contenu de ce dossier partagé, à savoir le compte de provisioning SvcJoinComputerToDom.

Et également le flag 7.

RBCD

Tout est en place pour notre RBCD. Nous aurons besoin de 4 outils (PowerView, Powermad, Rubeus et Mimikatz).

• https://github.com/PowerShellMafia/PowerSploit/blob/dev/Recon/PowerView.ps1
• https://github.com/Kevin-Robertson/Powermad/blob/master/Powermad.ps1
• https://github.com/GhostPack/Rubeus
• https://github.com/gentilkiwi/mimikatz

Nous commençons d’abord par importer PowerView et Powermad, puis nous spécifions le contrôleur de domaine comme cible. Nous récupérons le SID de l’utilisateur SvcJoinComputerToDomain.

Nous pouvons dès lors ajouter une machine au domaine à l’aide des identifiants de SvcJoinComputerToDom. Puis nous récupérons son SID, formons la structure basée sur ce SID et nous réécrivons la propriété « AllowedToActOnBehalfOfOtherIdentity » du DC.

A présent nous pouvons nous faire passer pour Administrator auprès du DC à l’aide de notre machine ajoutée au domaine.

Ci-dessous le retour de Rubeus.

Notre ticket est importé, allons DCSync avec Mimikatz le hash NTLM de Administrator et de Krbtgt (pour le flag 8).

Looting

Nous récupérons ainsi le hash NTLM de l’Administrateur du domaine. Le domaine est ainsi compromis.

Essayons maintenant de looter. Nous avons déjà compromis le Tomcat, compromis le DC, voyons ce que la machine du dev/admin recèle comme secret.

Pour cela, nous nous faisons un PSExec avec le hash Administrateur mais celui-ci échoue, car Administrator est dans les « Protected Users » du domaine.

On décide alors de DCSync le compte utilisateur « adminWorkstation » et de tenter notre chance avec PsExec. Cela passe. Nous énumérons alors la workstation et finissons par trouver sur le bureau d’adminWorkstation un raccourci WinSCP.

Nous savons que WinSCP enregistre les identifiants dans le registre d’une manière réversible. Nous pouvons simplement retrouver ces identifiants via le module Invoke_sessiongopher de CrackMapExec.

Muni de ces identifiants et d’une machine dans un sous-réseau encore non visité, de nouvelles aventures fortes en émotions s’annoncent dans la troisième et dernière partie…

#Staytuned – Le write up de la dernière partie sera publié dans quelques jours 😉 !