HackTheBox: Mirai Walkthrough
This walkthrough is gonna dive into a virus. Not that kind of virus. A computer virus. The box is called Mirai, and it represents the kind of machine that the infamous Mirai virus targeted to become part of its botnet. This malware still exists and is constantly scanning the internet, but it is most famous for its past DDoS attacks against Rutgers University and many high profile websites on the internet.
So here’s the box.
Enumeration
I began by running a script for a staged nmap scan that I recently wrote, and which can be found on my Github:
A number of open ports were found, most of which provided little value for this box. Visiting 10.10.10.48:80 in the browser yielded nothing. Adding the IP address to the /etc/hosts file under the name mirai.htb yielded some different results. Visiting mirai.htb:80 gave me a 403 error. Visiting mirai.htb:32400 gave me the login page for a Plex server, which after some inspection didn’t seem to provide anything of interest.
Obviously, further enumeration was needed. I ran gobuster to see what directories existed:
10.10.10.48/admin was the administration page for Pi-hole:
None of the directories for mirai.htb:32400 were interesting.
Now, given that the Mirai virus targets machines with default credentials, I decided to try to exploit that. Pihole doesn’t have default credentials, nor do Plex servers. However, as its name implies, Pihole often runs on a Raspberry Pi, which DOES have the default credentials pi:raspberry. Time to see if that works.
Exploitation, Internal Enumeration, and Grabbing Flags
Since SSH was set up on this server, I tried to log in via that.
In this case, it worked!
Note that pi is a part of the sudo group, that means that there is effectively no privilege escalation necessary for this box. However, internal enumeration is still important to understand what to do next. In this case, I decided to run a script I found online for Linux privilege escalation called LinPEAS. The output of this script is long, but here are some of the important findings for this box:
The script didn’t reveal much besides the fact that there’s a USB stick mounted. I switched to root and tried to grab the flags:
Hmm. So the root.txt file was lost… How does one go about recovering it? This is the neat thing about this machine. You have to know/learn a bit about digital forensics to complete this box. In my case, I used xxd to see if the file still physically existed on the USB, grepping out lines with only 0 or f:
And I found the flag! Worth noting that this method is not scalable and really only worked because there wasn’t a lot on the USB. I later learned of some other methods for analyzing the contents of a drive. You could use grep. You could also use the strings command. For bigger, fuller drives you could use an application called testdrive. Nonetheless, I gained something out of this box and now have a few more tools at my disposal.
