TryHackMe: Overpass 2 — Hacked

Walkthrough
In this article, I will be providing a walkthrough for the Overpass 2 — Hacked room, a free
room available on the TryHackMe platform created by NinjaJc01. I have provided a link to the
TryHackMe platform in the references below for anyone interested in trying out this free room.

Disclaimer
This is a walkthrough room and not your conventional CTF room, however this article will still
contain some spoilers. I believe you will enjoy this room more if you attempt it yourself first and
then come back to this article if you get stuck or need a hint!

Room Background — Overpass has been

hacked!
The following background is provided for this free room.

Overpass has been hacked! The SOC team (Paradox, congratulations on the promotion) noticed
suspicious activity on a late night shift while looking at shibes, and managed to capture packets
as the attack happened.

Can you work out how the attacker got in, and hack your way back into Overpass’ production
server?

Forensics — Analyse the PCAP

The room starts by providing a PCAP file that contains the packets captured during the attack.
There are five questions that need to be answered by forensically analyzing the captured network
packets. Using Wireshark, I opened the PCAP file to analyze the network packets and start
answering the questions.

sudo wireshark overpass2.pcapng

1. What was the URL of the page they used to upload a reverse shell?
Using Wireshark, I right clicked on the first TCP packet, moved down to the follow option and
then selected TCP Stream. This enables me to follow the TCP protocol stream and view a
protocol in the way that the application layer sees it.

Looking at the first TCP packet in the stream, I can see the URL of the page used by the
attackers to upload their reverse shell.

2. What payload did the attacker use to gain access?

Looking at the next TCP packet in the stream, I can see that the attacker used the upload.php
page to upload a file called payload.php which contains their reverse shell.
3. What password did the attacker use to privesc?

I found another TCP packet in the stream which shows what the attacker did once they gained a
reverse shell on the target machine. The attacker first checks what user they are by using the id
command, which shows that they are the user www-data. They next use python to import the
pty module and spawn a new, more stable shell. They then list the contents of the upload
directory and look at the contents of a hidden file called .overpass. The attacker then uses the su
command to switch to the user james and enters the password, escalating their privilege on the
target machine.

4. How did the attacker establish persistence?

Once the attacker had escalated their privileges, they changed to jame’s home directory and used
sudo -l to see what commands they could run with root permission. I can see that the user james
is permitted to run all commands as root using sudo based on the output in the packet capture.
The attacker then proceeds to look at the hashes stored in the /etc/shadow file.
The attacker proceeds to clone a Github repository to the target machine which enables them to
create an SSH backdoor.
5. Using the fasttrack wordlist, how many of the system passwords were crackable?

There are 5 users created on the target machine as seen in the shadow file above. Using a
password cracking tool such as John the Ripper and the specified wordlist fasttrack, I can
determine how many passwords were crackable. I start by first copying the last five rows of the
shadow file in the network capture to a new file called passwords. Next I run John the Ripper
tool to crack the hashes.

sudo john --wordlist=/usr/share/wordlists/fasttrack.txt passwords

I can see from the output that 4 hashes were cracked.

Research — Analyse the Code

The next stage for this room involves analyzing the code used for the backdoor. I can retrieve the
code by using the Github link found earlier while forensically analyzing the PCAP file.

1. What’s the default hash for the backdoor?

Looking through the contents of the repository downloaded from Github, I can see a file called
main.go. I decided to examine this file using Sublime and while looking through the first few
lines of code, I could see the default hash string for the backdoor.
2. What’s the hardcoded salt for the backdoor?

Moving down through the code in the main.go file, I found a function called verifypass which
takes three parameters, one of which is called salt.

Further down, I found a function called passwordHandler which used a hardcoded string value
for the salt parameter.

3. What was the hash that the attacker used? — go back to the PCAP for this!

Going back to the PCAP file analysed earlier, it is possible to see that after the attacker has
cloned the Github repository and has generated an RSA key pair, the attacker then proceeds to
make the backdoor file executable and executes the binary with a hash specified using the -a
parameter.
4. Crack the hash using rockyou and a cracking tool of your choice. What’s the password?

After recovering the hash, I can use the tool hashcat and the wordlist rockyou to crack the hash
recovered above. Using the tool hash-identifier, I can confirm that the hash recovered used the
SHA-512 algorithm. From examining the code for the backdoor earlier, I know that the SHA-512
hash is created using the password and then the salt in that order (i.e. password:salt).

I can visit the hashcat wiki (see references) and look for a hash mode that matches how the hash
was created. I can see that the hash mode 1710 is suitable.

1710 | sha512($pass.$salt) | Raw Hash, Salted and/or Iterated

To crack the hash, I need to provide the SHA-512 hash found in the packet capture used by the
attacker and the hardcoded salt found in the main.go file (i.e. hash:salt). I added the hash:salt
to a file and then used the hashcat command seen below to crack the hash.

hashcat -m 1710 -a 0 -o cracked.txt hash.txt rockyou.txt

This was successful and I was able to recover the password.

Attack — Get Back In!
The final stage for this room is to take control of the Overpass production server again and
retrieve the user and root flags. I started by scanning the target machine with NMAP.

nmap -sV -sC -Pn -v -oN nmap_report 10.10.219.135

This scan revealed three open ports on the target machine.

1. The attacker defaced the website. What message did they leave as a heading?

Typing the IP address into my browser presents a web page with what appears to be a cactus
eating a cookie (I assume 😅).

Looking at the page source gives me the full message the attackers left as a heading.
User Flag

From the NMAP scan results above, I can see that port 22 and 2222 both have the SSH service
running. Based on the information I have collected so far, I tried logging in as the user james
with the original password for the account as seen when examining the PCAP file. This fails for
both port 22 and 2222. I then tried the password retrieved from cracking the SHA-512 hash
earlier with hashcat. This failed for port 22 but worked for port 2222.

ssh -p 2222 [email protected]

Once logged in, I can navigate to the home directory for James and retrieve the user flag.

Root Flag

At first, I believed that the user james was able to run any command with root privileges using
sudo based on the information found in the PCAP file earlier. However, I found that this was not
true and I could not use sudo to run any commands as root. I decided to move back to james
home directory and see if there were any interesting files. I immediately noticed that there was a
hidden binary file owned by root in the directory called .suid_bash.

I can execute this binary file which will create a new shell for me with root privileges.

./.suid_bash -p
I can then change directory to the root directory and retrieve the root flag.

Closing Remarks
I really enjoyed this free room and how it incorporated multiple stages before attacking the target
machine. This style of room was similar to the Recovery CTF room I had completed not too
long ago, which involved triaging an incident and fixing the damage done, but was not as
unconventional.

I really enjoy rooms like this where you need to investigate an incident and understand what
happened before fixing the damage done or using the evidence collected to attack the machine
and get flags. I hope to see more rooms like this on the TryHackMe platform in the near future.
Thanks for reading till the end and keep hacking 😄!

References
 https://tryhackme.com/
 https://hashcat.net/wiki/doku.php?id=hashcat