✍🏼 Writeup – Relevant room TryHackMe

Ceci est mon premier « writeup » concernant une résolution de room TryHackMe.

J’ai choisi « Relevant » un peu par hasard, son arrivée dans mon cursus tombant au moment où l’idée m’est apparu de réaliser un article de ce genre.


Tout d’abord, je vous donne le briefing lié au challenge :

You have been assigned to a client that wants a penetration test conducted on an environment due to be released to production in seven days.

Scope of Work

The client requests that an engineer conducts an assessment of the provided virtual environment. The client has asked that minimal information be provided about the assessment, wanting the engagement conducted from the eyes of a malicious actor (black box penetration test). The client has asked that you secure two flags (no location provided) as proof of exploitation:

User.txt

Root.txt

Additionally, the client has provided the following scope allowances:

Any tools or techniques are permitted in this engagement, however we ask that you attempt manual exploitation first

Locate and note all vulnerabilities found

Submit the flags discovered to the dashboard

Only the IP address assigned to your machine is in scope

Find and report ALL vulnerabilities (yes, there is more than one path to root)

(Roleplay off)

I encourage you to approach this challenge as an actual penetration test. Consider writing a report, to include an executive summary, vulnerability and exploitation assessment, and remediation suggestions, as this will benefit you in preparation for the eLearnSecurity Certified Professional Penetration Tester or career as a penetration tester in the field.

Note – Nothing in this room requires Metasploit


1ère étape : la reconnaissance …

… et pour cela rien de mieux qu’un coup de nmap :

Explications de la commande :

  • -sS : On souhaite faire un TCP SYN (Stealth) scan (ou half open scan car on ne réalise pas l’intégralité du 3-way handshake TCP).
  • -A : Aggressive scan options = active la détection d’OS (-O) , le scan de version (-sV), utilisation des scripts par défaut (-sC) et réalise un traceroute de la cible (–traceroute).
  • -Pn : Considérer tous les hôtes comme étant connectés (saute l’étape de découverte des hôtes).
  • -p- : Scan l’intégralité des ports possibles.
  • -T4* : Choisit la « politique de temporisation » 4 (la plus rapide étant la 5, par défaut nmap utilise la valeur 3).

* Concernant la « politique de temporisation », je choisis volontairement une valeur élevée pour scanner plus rapidement, mais attention à 2 choses :

  • Si votre connexion est mauvaise, il risque d’y avoir des retransmissions voire des échecs de communication, donc au final temps rallongé et résultat de scan bancal.
  • En condition réelle de pentest plus le scan est « rapide » plus il va avoir de chance d’être vu avec des solutions IDS/IPS (Intrusion Detection/Prevention System) et des pics vont être immédiatement visibles sur un éventuel SIEM (Security Information and Event Management) donc privilégier un scan plus « lent ».

On identifie 2 accès web IIS : un sur le port 80 et l’autre sur le port 49663 qui mènent tous deux à une page web IIS par défaut.

Page web exposée sur les ports 80 et 49663

On remarque également que les ports 139 et 445 sont ouverts, typique d’une implémentation du protocole SMB.
Ci-dessous une explication détaillée concernant ces 2 ports :

Détail des ports 139 et 445

Le port 3389, permettant l’accès à distance à la machine via le protocole RDP (Remote Desktop Protocol), est également ouvert.

Les ports 49666, 49667 et 49668 me semblent non pertinents pour le moment.


2ème étape : établir une cartographie du système (mapping)

Je décide de commencer avec les services web en écoute respectivement sur les ports 80 et 49663.

Pour cela je réalise un bruteforce sur chacun des 2 points d’accès à l’aide de l’outil gobuster :

Résultat bruteforce sur le port 80
Résultat bruteforce sur le port 49663

On ne trouve rien de croustillant sur le serveur web en écoute sur le port 80, mais on obtient un résultat intéressant sur le port 49663.
On découvre en effet un sous-répertoire nt4wrksv.

En naviguant sur ce répertoire, on ne trouve pas grand-chose à exploiter.

Second candidat à explorer : SMB, et pour cela on va se baser sur des outils spécifiques tels que netexec ou smbclient.

Premièrement, on recherche des informations sur la cible avec netexec.

Retour commande nxc

On remarque que la version 1 du protocole SMB est activée, et que la signature des messages est désactivée.

On vérifie ensuite si il y a possibilité de se connecter de manière anonyme.

Retour commande nxc – connexion anonyme

L’accès nous est refusé en connexion anonyme.

On test la connexion « invité » (Guest).

Retour commande nxc – connexion invité

On observe cette fois-ci un retour positif, on peut donc se connecter sans compte, en tant qu’invité.

On va maintenant utiliser l’outil smbclient afin d’énumérer les éventuels partages disponibles et accessibles.

Liste des partages SMB accessibles

On retrouve des partages « classiques », ainsi qu’un partage plus spécifique, avec un nom déjà rencontré lors de l’énumération du serveur web en écoute sur le port 49663 : nt4wrksv.

On tente de se connecter en invité à ce partage énigmatique.

Connexion invité partage nt4wrksv

On récupère le fichier passwords.txt qui semble prometteur, et on affiche son contenu.

Contenu fichier passwords.txt

Le contenu du fichier semble être encodé en base64, tentons de décoder les 2 lignes.

Contenu du fichier passwords.txt décodé

On a alors à notre disposition 2 couples d’utilisateur/mot de passe :

  • Bob – !P@$$W0rD!123
  • Bill – Juw4nnaM4n420696969!$$$

On vérifie également s’il y a un lien entre ce partage et le répertoire du même nom trouvé lors du bruteforce du serveur web en écoute sur le port 49663 :

On confirme que le partage SMB ainsi que le répertoire du serveur web nt4wrksv pointent bien vers le même endroit.

A ce stade, on a obtenu des informations complémentaires sur la cible, ainsi que 2 jeux de nom d’utilisateur et mot de passe, on peut passer à la phase suivante.


3ème étape : l’exploitation de l’hôte cible

On va tenter d’uploader un reverse shell via le partage SMB nt4wrksv que l’on appellera ensuite via le navigateur web.

Pour cela, on utilise l’outil msfvenom permettant de générer divers payloads, dont des reverse shells :

Génération d’un reverse shell TCP en aspx

On upload ensuite le reverse shell via le partage SMB.

Envoi reverse shell sur partage SMB

A partir de ce moment là, il ne nous reste plus qu’à démarrer netcat en écoute sur le port configuré dans la payload (4444 dans notre exemple).

Démarrage de l’écoute du reverse shell

Désormais, netcat est en attente d’une connexion entrante, on peut appeler le script directement via le navigateur web pour déclencher son exécution, et ainsi obtenir le reverse shell tant attendu !

On retourne dans notre console attendant désespérément une connexion entrante afin de vérifier le bon fonctionnement de la payload :

Reverse shell obtenu

Maintenant que l’on est connecté, on peut « fouiller » à la recherche d’informations utiles (un flag peut être ?).

Parcours des utilisateurs

On retrouve un nom déjà vu : Bob !

Voyons s’il a des choses à nous offrir.

Flag utilisateur
Bingo !!! On trouve le premier flag :

THM{fdk4ka34vk346ksxfr21tg789ktf45}


Premier flag en poche, le prochain est le flag root, on peut passer à la prochaine étape : l’escalade de privilèges.

4ème étape : Elévation de privilèges

Première étape, on vérifie les droits à l’aide de la commande whoami.

Liste des privilèges de l’utilisateur courant

On observe 3 privilèges actifs :

  • SeChangeNotifyPrivilege
  • SeImpersonatePrivilege
  • SeCreateGlobalPrivilege

Le second semble prometteur, et après avoir essuyé une fin de non recevoir avec l’outil GodPotato (https://github.com/BeichenDream/GodPotato), j’ai décidé de persister avec l’utilisation de ce privilège avec un autre outil : PrintSpoofer (https://github.com/itm4n/PrintSpoofer).

On commence par télécharger le binaire de l’outil, et on lance un serveur web avec python afin de le récupérer à partir de la cible.

Démarrage d’un serveur web python en écoute sur le port 8000

Pour cela, on peut utiliser un « LOL bin » (Living Off The Land Binary : exemples et cas d’utilisation ici : https://lolbas-project.github.io/) tel que certutil.exe :

Download de l’outil PrintSpoofer via la commande certutil.exe

On lance maintenant l’outil afin d’abuser du privilège SeImpersonatePrivilege afin d’obtenir un shell avec les droits « system ».

Obtention shell system avec PrintSpoofer

Bingo ! Le plus « dur » est fait, on a obtenu un shell « system », il ne reste plus qu’à fouiller pour récupérer le flag root.

Récupération du flag « root »
On trouve le second flag :

THM{1fk5kf469devly1gl320zafgl345pv}


Chaîne d’attaque

ÉtapeTechnique MITRE ATT&CK (ID)Nom technique (anglais)Commentaire / application au challenge
Scan initial avec nmap (ports & versions)T1595 / T1595.002Active Scanning / Scanning IPs, Portsnmap -sS -A -Pn -p- -T4 -oA — découverte des services exposés (IIS, SMB, RDP).
Découverte des services (IIS, SMB, RDP)T1046Network Service DiscoveryIdentification des services sur 80, 49663, 139/445, 3389, etc.
Bruteforce / enumeration web (gobuster)T1595 (recon)Active Scanning / Web content discoveryRecherche de répertoires (ex : nt4wrksv) sur le site écoutant sur 49663.
Découverte des partages SMB / accès invité (Guest)T1135Network Share DiscoveryÉnumération des partages SMB, détection du partage nt4wrksv.
Récupération d’un fichier contenant des credentials encodésT1552.001Credentials in Filespasswords.txt trouvé dans le partage puis décodé (base64) → identifiants récupérés.
Utilisation des identifiants (upload via SMB)T1078Valid AccountsUtilisation des comptes trouvés (Bob/Bill) pour interagir avec le service/partage.
Transfert du webshell/reverse shell via SMB (ingress)T1105Ingress Tool TransferUpload du payload ASPX sur le répertoire web partagé / accessible.
Déclenchement du shell via HTTP (reverse shell)T1190Exploit Public‑Facing Application / Web shell executionAppel du fichier uploadé via navigateur → exécution → reverse shell.
Exécution de commandes (reverse shell → interaction)T1059Command and Scripting InterpreterUtilisation de la session shell pour énumérer le système, trouver utilisateurs, fichiers.
Abus du privilège SeImpersonatePrivilege → PrintSpooferT1134, T1068Access Token Manipulation (Token Impersonation/Theft) / Exploitation for Privilege EscalationAbus de l’impersonation via PrintSpoofer pour obtenir un shell SYSTEM.
Récupération de données locales (root/System)T1005Data from Local SystemLecture de fichiers sensibles (flags, configs) une fois le compte SYSTEM obtenu.

Synthèse de la chaîne d’attaque:

  1. Reconnaissance : scan complet (nmap -sS -A -Pn -p- -T4) → découverte de services : IIS (ports 80 & 49663), SMB (139/445) et RDP (3389).
  2. Mapping & énumération : brute‑force web (gobuster) → découverte du répertoire nt4wrksv ; énumération SMB → accès Guest au partage nt4wrksv.
  3. Collecte de credentials : récupération de passwords.txt dans le partage, décodage base64 → comptes identifiés (Bob, Bill).
  4. Accès initial : upload d’un reverse shell (ASPX) sur le partage web via SMB (Ingress Tool Transfer), puis déclenchement via navigateur → reverse shell obtenu.
  5. Post‑compromission & escalade : exploration locale, découverte du privilège SeImpersonatePrivilege ; abus via PrintSpoofer pour obtenir un shell SYSTEM (escalade).
  6. Impact : accès SYSTEM obtenu et lecture des données locales sensibles.

Retour d’expérience

Ce qui n’apparaît pas dans cet article, c’est la notion de temps passé, de tentatives et d’échecs.
L’enchaînement des commandes détaillées ci-dessus n’ont pas été réalisées d’une manière si linéaire et limpide.

Il y a tout d’abord une partie recherche d’informations liée aux différentes découvertes réalisées durant ce challenge, en commençant par les ports découverts liés à leurs services (et surtout leurs versions).

Ensuite je n’ai pas pensé tout de suite à faire une énumération web, du coup après avoir trouvé le partage SMB accessible en Guest, je n’ai pas tout de suite su quoi en faire.

Enfin, si je devais refaire cette room (ce qui est valable pour la prochaine), je suivrais une procédure plus claire, j’irais dans moins de direction à la fois pour être sûr de ne pas rater quelque chose.
J’ai d’ailleurs commencé à me faire un document regroupant par catégories les pistes à suivre ainsi que les outils à utiliser afin de ne pas me reposer les mêmes questions systématiquement.


Conclusion

Pour rappel : il s’agit de mon tout premier writeup, j’y ai passé beaucoup plus de temps que je ne pensais y passer mais ça aura été une expérience enrichissante.

Tout d’abord cet exercice m’a contraint à plus de rigueur afin de pouvoir restituer de manière la plus claire et compréhensive que possible pour d’éventuels lecteurs.
Ensuite j’ai passé plus de temps qu’à l’accoutumé sur chaque « trouvaille », me permettant ainsi de creuser plus loin ce qui a amélioré ma compréhension globale (et spécifique) des sujets abordés (SMB entre autres).
Enfin, j’espère que cet article pourra servir au maximum de personnes en quête de réponses sur cette room.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *