Test de pénétration en boîte noire contre HackSudo Thor : exploitation de CVE-2014-6271 Shellshock RCE via Apache mod_cgi, enchaînée avec une mauvaise configuration de sudo et une injection bash eval pour une élévation de privilèges complète. Inclut un outil de force brute personnalisé conscient des CSRF et une automatisation RPC Metasploit.
heventafese/penetration-testing-walkthrough-hacksudo-thor
Cible : HackSudo Thor de VulnHub
Objectif : Obtenir un accès root et lire/root/proof.txt
Environnement : Laboratoire VirtualBox isolé segmenté par un pare-feu pfSense
Ce référentiel documente un test de pénétration en boîte noire partiel mené sur HackSudo Thor, une machine virtuelle intentionnellement vulnérable publiée sur VulnHub par Vishal Waghmare. L'objectif était de simuler une attaque réelle où un attaquant externe tente de compromettre un système interne isolé avec pour objectif principal d'obtenir un accès root et de lire le contenu de /root/proof.txt.
L'évaluation suit le cycle de vie complet du test de pénétration : reconnaissance passive, découverte du réseau, énumération, évaluation des vulnérabilités, exploitation, élévation de privilèges, post-exploitation et dissimulation des traces.
Les principaux outils utilisés étaient Nmap pour le scan réseau, Nessus pour l'évaluation des vulnérabilités, et le Metasploit Framework comme plateforme principale d'exploitation et de post-exploitation. John the Ripper, Hashcat et des Rainbow Tables en ligne ont été utilisés pendant l'étape de cassage de mots de passe, bien que toutes les tentatives aient finalement échoué en raison de la robustesse de l'algorithme de hachage utilisé.
Le laboratoire virtuel a été entièrement construit dans VirtualBox et conçu pour simuler un réseau d'entreprise réaliste avec trois zones de sécurité distinctes, toutes gérées par un pare-feu pfSense 2.7.2. Les trois réseaux NAT ont été configurés comme suit : une zone WAN simulant l'internet public où se trouve la machine attaquante Kali, une zone DMZ hébergeant la machine cible, et une zone LAN interne contenant des machines hors périmètre.``` Internet Zone — NatNetwork (10.0.2.0/24) │ │ Kali Linux 2025.4 [attacker] — 10.0.2.9 │ pfSense WAN interface — 10.0.2.8 │ ├── pfSense Firewall (boundary device) │ ├── DMZ Zone — DMZnat (10.0.4.0/24) │ ├── HackSudo Thor [TARGET] — 10.0.4.3 │ └── DVWA — 10.0.4.4 (out of scope) │ └── LAN Zone — LANnat (10.0.3.0/24) ├── Metasploitable 2 — 10.0.3.5 (out of scope) └── Windows XP Cyberlab — 10.0.3.4 (out of scope)
*Zones de sécurité de la topologie logique du réseau gérées par pfSense*
L'interface WAN a reçu l'adresse `10.0.2.8/24` via DHCP, l'interface LAN a été configurée en `10.0.3.1/24` et l'interface OPT1 (DMZ) en `10.0.4.1/24`. Pour introduire une erreur de configuration volontaire dans le laboratoire, le port 80 a été intentionnellement laissé exposé sur l'interface WAN de pfSense, simulant une exposition courante de panneau d'administration dans le monde réel qui a servi de point d'entrée principal vers le réseau interne.
---
## Résumé de la chaîne d'attaque```
[Kali Linux — 10.0.2.9]
│
│ CSRF-aware Python brute force → admin / pfsense
▼
[pfSense webConfigurator — 10.0.2.8:80]
│
│ Firewall rules disabled → DMZ and LAN now reachable
▼
[HackSudo Thor — 10.0.4.3]
│
│ Shellshock RCE (CVE-2014-6271)
│ Apache mod_cgi → /cgi-bin/shell.sh
▼
[Meterpreter shell — www-data]
│
│ sudo -u thor /home/thor/hammer.sh
│ Command injection via eval → bash -i payload
▼
[Interactive shell — thor]
│
│ GTFOBins: sudo service ../../bin/bash
▼
[Root shell]
│
├── /root/proof.txt captured ✅
├── /etc/shadow + /etc/passwd exfiltrated
└── SSH RSA backdoor planted
Avant tout contact avec l'environnement cible, des informations ont été collectées exclusivement à partir de sources publiques. Les deux sources principales étaient la page d'entrée officielle de VulnHub pour HackSudo Thor et le profil GitHub public de l'auteur.
La page VulnHub confirmait que la cible était un système basé sur Linux, classé facile à moyen, avec pour objectif la recherche du fichier proof.txt. L'examen du profil GitHub de l'auteur a fourni des informations supplémentaires. Vishal Waghmare conçoit systématiquement des machines Linux de type boot-to-root où l'élévation de privilèges est le défi central de toute la série HackSudo. Cela a façonné le modèle de menace pour les phases actives : les services HTTP et SSH étaient la surface d'attaque la plus probable, et le chemin d'élévation était prévu comme impliquant une mauvaise configuration de sudo, un abus de binaire SUID ou l'exploitation d'un service personnalisé.
Ce type d'analyse des schémas de l'auteur est également important dans un engagement réel. Comprendre comment un système a probablement été conçu et quelles catégories de faiblesse son administrateur est susceptible de répéter donne une direction avant même l'envoi d'un seul paquet.
| Champ | Détail |
|---|---|
| Cible | HackSudo Thor |
| Auteur | Vishal Waghmare (@hacksudo) |
| Date de sortie | 3 août 2021 |
| Difficulté | Facile à Moyen |
| OS | Linux (Debian) |
| Format | VirtualBox OVA |
| DHCP | Activé |
| Surface d'attaque prévue | HTTP, SSH, mauvaise config de sudo probable |
Cette phase a consisté à prendre un contact actif direct avec l'environnement. L'objectif était d'identifier tous les hôtes actifs, de comprendre la frontière du réseau et de construire une image complète de la surface d'attaque avant de se concentrer sur la cible principale.
Un léger balayage ping Nmap (-sn) a d'abord été exécuté sur le sous-réseau WAN (10.0.2.0/24) pour découvrir les hôtes actifs avec un minimum de bruit. Trois hôtes ont été identifiés : 10.0.2.1 et 10.0.2.2 étaient des adresses standard de l'infrastructure VirtualBox, ce qui laissait 10.0.2.8 comme seul hôte non infrastructurel. Cette machine est devenue l'objet d'attention immédiat.
Un balayage SYN furtif complet contre 10.0.2.8 n'a retourné aucun résultat. Ce comportement était attendu et non une erreur. Les pare-feu d'entreprise sont conçus pour être insensibles au balayage de ports, en supprimant silencieusement les paquets plutôt qu'en répondant. L'absence de résultats était elle-même une confirmation qu'il s'agissait d'un périphérique frontal filtrant activement le trafic.