Scavenger — HackTheBox Write-up

Scavenger is a Linux machine that involves a lot of enumeration, SQL Injection through WHOIS service, analyzing a PCAP file,an access log file and privilege escalation through a Linux Kernel module!

Initial Reconnaissance

As always the write-up starts with an nmap script and version scan

There are six open ports, the web-page gave me a virtual hosts configuration error.

I tried to do anonymous login to the vsFTPd service but it is disabled so I wasn’t able to get anything from this service.

Anonymous login

On whois service which uses a MariaDB database, I was able to confirm that it is vulnerable to some SQL Injections that leads me to four domains.


Putting a basic SQL Injection payload a’) OR 1=1#” shows whois results on the following four domains:

On four domains I performed directory scanning but didn’t give me anything useful. I was able to to find a few PoC exploits on pwnhats and rentahacker virtual-hosts but its a dead end.

When I zone transferred on the hxxp://www.rentahacker.htb it gave me a list of hosts of hxxp://www.rentahacker.htb

It took me forever to figure out zone transferring! Don’t forget the basics!

When I browsed the subdomain sec03 it was already been hacked by another team.

On the comments section from the hxxp://rentahacker.htbit was revealed that they were already pwned by the team 31163 HAXXOR

Since the website was already pwned by a hacker team, I looked for potential backdoors that was left by the hackers. So I performed another directory scan on the hxxp://sec03.renthacker.htb


One of the interesting results from the directory scan was the shell.php. Fuzzing the parameters gave me the hidden parameter, which I can use to perform command injections through the web shell.

Initial Foothold and Privilege Escalation

So the shell.php?hidden= is a web shell backdoor that was left by the hackers who pwned the machine. Now that I was able to get an initial foothold on the machine, the first thing that came to my mind is to look for configuration files that contains hard-coded passwords.

Going to the config directory of the wordpress, I was able to get the password for ib01c03 user.

Using the credentials of ib01c03 user to login on the FTP service gave me a better shell to enumerate the files inside the machine.

The next thing that I did was enumerate more directories and files inside the machine as the ib01c03 user. I came across on the /var/mail files and transferred the file ib01c03 and fortunately I got another credentials for ib01ftp user.

Logging in as the ib01ftp user, I was able to get some important files from the incidents directory.

The directory contains an access log file, a PCAP file, and a note file.

The note says that the hackers who pwned the machine knows the valid credentials and abused a specific vulnerability that gave them access to the server.

Reading the PCAP file I was able to get the credentials for the pwnhats@pwnhats.htb user.

The password also works for the ib01c01 user!

Privilege Escalation to Root

I generated an ssh key and uploaded it to the ssh directory but it didn’t worked since I don’t have a permission to upload files through FTP.

On the /home/ib01c01/... directory, there was a Kernel module rootkit that was probably left by the hackers. Going back to the PCAP file, I was able to view the code of the root.ko file and its magic word!

Using the magic word g0tR00t doesn’t work, it might be already changed from the machine. By viewing the first few lines of the root.ko module I was able to see some words that might be the magic word. Also since the word g0tR0ot doesn’t work, I tried the combinations Pr1vGet and g3tPr1v

Using g3tPriv as the magic word, I was able to view the contents of the root directory which means I already have root access on the web shell.

Make sure the payload is URL encoded or it won’t work!

But the web shell with the rootkit payload isn’t enough. I uploaded my ssh keys to the ssh folder on the root directory to get a better interactive shell!

Unfortunately, it still asks for root's password.

So the reason why I cannot ssh using root user is because the group support is only allowed to perform ssh logins.

Also outgoing connections are only gonna work if it comes from port 20.

So to bypass all these configurations, first thing I did was to delete the first line on the /etc/ssh/sshd_config file.


Then restart the ssh.service


After restarting the ssh.service I made sure that I successfully deleted the first line on the ssh configuration.

Now that I successfully deleted the first line on the ssh configuration, I uploaded my ssh keys to the /root/.ssh/authorized_keys and was able to login successfully as root!

echo+"g3tPr1v"+>+/dev/ttyR0%3becho+"Put your keys here"+>+/root/.ssh/authorized_keys

Change the file’s permission!






Just another script kiddie

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store