Overview

This lab simulated a vulnerable Linux web server in a closed CTF environment. The objective was to follow a standard penetration testing workflow: discover the target, enumerate exposed services, identify weaknesses in the web application, gain initial access, escalate privileges, and capture three flags.

The attacking Kali machine was assigned 192.168.62.37, and the target machine was discovered at 192.168.62.124. Because SSH was closed and only web services were exposed, the engagement centered on web enumeration and WordPress exploitation paths.

Reconnaissance and Enumeration

The first phase focused on identifying live hosts and mapping the target's exposed services. The Kali machine's network address was confirmed with ip a, then a ping sweep using nmap -sn 192.168.62.0/24 revealed the CTF target at 192.168.62.124.

A full Nmap scan showed that 80/tcp and 443/tcp were open, indicating HTTP and HTTPS services. SSH on 22/tcp was closed, which confirmed that the realistic entry point was the web application rather than direct remote shell access.

Opening the target in a browser revealed a WordPress-based site. The /robots.txt file exposed two important entries: key-1-of-3.txt and fsocity.dic. Accessing the first file produced the first flag, while the second file provided a custom dictionary that could be cleaned with sort -u fsocity.dic > fsocity_unique.dic for later enumeration.

Web Application Enumeration

Directory brute forcing with DIRB and the custom wordlist revealed several useful paths, including /admin/, /login, /readme, /license, /intro, /blog/, and WordPress-related directories. The /login path redirected to the WordPress login page, confirming that WordPress was the main application target.

The likely username elliot was identified based on the challenge theme and validated through WordPress login error behavior. The application returned different errors for invalid usernames and valid usernames with incorrect passwords, creating a username enumeration weakness.

After the valid username was confirmed, Hydra was used against the WordPress login with the cleaned fsocity_unique.dic wordlist. The valid lab credential pair was found as elliot:ER28-0652, giving access to the WordPress dashboard.

Initial Access

After logging in as elliot, the account had access to the WordPress theme editor. The active theme was Twenty Fifteen, and the 404.php template was writable. This mattered because writable PHP templates can become a path from administrative web access to server-side code execution.

A PHP reverse shell was copied from Kali's webshell directory, modified to connect back to the attacking host at 192.168.62.37 on port 4444, and pasted into the writable 404.php file. A Netcat listener was started with nc -lvnp 4444, and the modified template was triggered in the browser.

The callback successfully returned a shell as the low-privileged daemon user. The shell was stabilized with python -c 'import pty; pty.spawn("/bin/bash")', followed by export TERM=xterm, making post-exploitation interaction more usable.

Privilege Escalation and Flag Collection

Post-exploitation enumeration revealed a user directory at /home/robot. The second flag, key-2-of-3.txt, was visible but could not initially be read by the daemon user because of file permissions.

Another file, password.raw-md5, was readable and contained an MD5 hash associated with the robot account. The hash was copied back to Kali and cracked with John the Ripper using the RockYou wordlist. The recovered password allowed switching users with su robot, after which the second flag could be read.

Further enumeration from the robot account included checking SUID binaries with find / -perm -4000 -type f 2>/dev/null. A misconfigured privileged binary provided the path to root. After exploiting the SUID misconfiguration, root access was obtained and the final flag, key-3-of-3.txt, was captured.

Findings and Security Lessons

This lab demonstrated how multiple small weaknesses can combine into full system compromise. The exposed robots.txt entries disclosed both a flag and a useful wordlist. WordPress login behavior allowed username enumeration. Weak passwords were recoverable through dictionary-based attacks. Excessive WordPress administrative permissions allowed direct PHP file editing, which led to remote code execution. Local SUID misconfiguration then enabled privilege escalation from a normal user to root.

• Do not expose sensitive files. Files like flags, dictionaries, backups, credentials, and internal notes should never be placed in web-accessible directories.
• Harden login responses. Applications should avoid revealing whether a username is valid through different error messages.
• Use stronger authentication. Passwords should be unique, complex, and resistant to common dictionary attacks.
• Restrict WordPress theme editing. Dashboard-level PHP editing should be disabled unless there is a clear operational need.
• Audit privilege boundaries. SUID binaries, file permissions, and local escalation paths should be reviewed regularly.