Writeup by wook413

Recon

Nmap

As a standard procedure, I initiated 3 different Nmap scans. The first covered all 65,535 TCP ports to ensure no service was missed. The second was a targeted service scan on identified ports to determine versions, and the third focused on the top 10 UDP ports.

Initial Access

HTTP 80

I mapped the target IP address to marketing.pg in the /etc/hosts file for easier navigation.

Only ports 22 and 80 were open. For the HTTP service, I ran the http-enum Nmap script for quick wins, which revealed /old and /vendor directories.

Although the index.html files in the root and /old appeared identical, I discovered a hidden link to customers-survey.marketing.pg within the source code of the /old page.

image-20260208152241451

image-20260208152247571

image-20260208152253203

I added this subdomain to my /etc/hosts file as well.

Navigating to the subdomain revealed a LimeSurvey instance.

image-20260208152259295

Using gobuster for directory brute-forcing and researching for default credentials, I successfully logged in as admin:password .

image-20260208152306493

image-20260208152311212

image-20260208152317584

I found this Github repository leveraging a plugin exploit to gain Remote Code Execution. The author also wrote the instruction on how to perform the exploit very clearly.

https://github.com/Y1LD1R1M-1337/Limesurvey-RCE

I created a config.xml and a PHP reverse shell, archived them as a ZIP file.

image-20260208152326321

Uploaded them via Configuration → Plugins → Upload & Install. Upon activating the plugin, I received a reverse shell as the www-data user.

image-20260208152332343

Shell as www-data

While manually enumerating the system, I found database credentials in /var/www/LimeSurvey/application/config/config.php .

image-20260208152340910

Although the MySQL database contained no sensitive information, I successfully performed password reuse by testing these credentials against the user t.miller . This allowed me to pivot to a user shell.

Shell as t.miller

Found local.txt

Privilege Escalation

Running sudo -l showed that t.miller could run /usr/bin/sync.sh as the user m.sander .

The sync.sh script is a file synchronization tool that overwrites a target file (/home/m.sander/personal/notes.txt ) if a difference is detected.

By providing an empty file as an argument, the diff command within the script leaked the entire contents of the target file to the terminal. However, it didn’t lead me to anything exploitable.

Checking /etc/group revealed that both t.miller and m.sander belonged to the mlocate group.

There is mlocate.db file that belongs to mlocate group.

image-20260208152351325

I examined the mlocate.db file using grep -a (to treat the binary as text), which exposed a hidden file: /home/m.sander/personal/creds-for-2022.txt .

image-20260208152356677

The script blocks any path containing the string “m.sander.” To bypass this, I created a symbolic link in my current directory pointing to the credentials file creds-for-2022.txt .

Since the link name did not contain the forbidden string, the script processed it, and the diff output revealed the passwords.

Shell as m.sander

After logging in as m.sander , I checked the sudo permissions and found that the user had full sudo privileges (ALL:ALL).

Shell as root

I executed sudo /bin/bash -p to obtain a root shell and completed the challenge.

Found proof.txt