Writeup by wook413

Recon

Nmap

I began the machine with a standard three-stage Nmap recon: a full TCP scan against all 65,535 ports, followed by a targeted service scan of the discovered ports, and a UDP scan of the top 10 ports.

Initial Access

FTP 21

Initial checks on the FTP service confirmed that anonymous login was disabled.

HTTP 3000

Shifting focus to HTTP service on port 3000, I ran the http-enum script, which identified /healthcheck, /manifest.json, and /debug . Given their naming conventions, they didn’t appear to house sensitive information at first glance.

Further inspection revealed that the service on port 3000 was Gitea v1.7.5 .

image-20260214133902764

A searchsploit query for this version yielded a matching exploit.

Since the exploit required valid credentials, I manually registered a new account on the page.

image-20260214133909195

I updated the exploit script with the target’s details and my Kali Linux IP/port to point to my HTTP server.

image-20260214133913521

Using msfvenom, I generated a payload named shell.sh . The exploit was configured to fetch this via port 2222, which, upon execution, would trigger a reverse shell back to my listener on port 21.

Upon running the exploit, the payload was successfully triggered.

Shell as chloe

I successfully established a shell session as the user chloe.

image-20260214133920537

Found local.txt

Privilege Escalation

I began manual enumeration for privilege escalation vectors and deployed pspy to monitor background processes, though no immediate leads were found.

image-20260214133945703

I eventually discovered giteadb credentials within the app.ini configuration file located at /etc/gitea.

I successfully logged in to the MariaDB instance using these credentials, but the database did not yield any further paths for escalation.

With manual leads exhausted, I transferred and executed linpeas.sh

linpeas immediately flagged a potential vulnrability in the PATH environment variable.

image-20260214134001173

I confirmed that I had write permissions for the /usr/local/bin directory.

Inspecting /etc/crontab , I noticed the run-parts binary was being called without its absolute path. Since /usr/local/bin comes before /usr/bin and /bin in the system’s PATH, I identified a clear opportunity for a PATH injection attack.

I placed a malicious script named run-parts .

Shortly after, I observed that the SUID bit had been successfully applied to /bin/bash.

Shell as root

I obtained a root shell by executing /bin/bash -p.

Found proof.txt