Mirai features a Raspberry Pi device with default credentials that can be used to log in over SSH. Enumeration of the system reveals a USB block device that is located on the sdb disk, but the files have been deleted off of the USB. The strings utility can be used to view contents of files that have yet to be overwritten and still remain on the disk which leads to the root flag.
The initial visit to the IP just showed a blank page:
Next, I ran a scan with nmap:
Ports open:
- 22 (SSH)
- 53 (DNS)
- 80 (HTTP)
Since port 53 was open, I tried adding mirai.htb to my /etc/hosts file which is the typical naming convention for virtual hosts on HTB. Then, I visited the page:
The most interesting part of this page was that it mentioned that it's using Pi-hole which is a network-level ad blocker that runs on a Raspberry Pi. Next, I enumerated the domain to see if there were any interesting directories.
Brute-forcing directories with gobuster:
An /admin directory was found, so I visited that page which showed an admin dashboard for Pi-hole:
I tried logging in with default credentials but they didn't work. So, the next move was to try to login over SSH.
Since the system was using a Raspberry Pi, I assumed that it was running the most common OS for Raspberry Pis, Raspberry Pi OS. Therefore, I attempted to login over SSH using the default credentials.
username: pi
password: raspberry
The default creds worked, which provided the initial foothold. Looking around the system led to the user flag which can be found in the /Desktop directory.
I got permission denied when I tried to cd into /root, so next I checked what permissions the pi user was able to run with sudo.
The pi user could run any command with sudo without needing a password, so I used this to change the password of the root user.
After switching to the root user and changing directory into root, the root.txt file said that the original root.txt has been lost, but there might be a backup on the USB.
I used lsblk to list info on the block storage devices:
Of the output, the most interesting was sdb which was mounted at /media/usbstick, so I went there to see what was on the USB.
damnit.txt mentioned that the files were deleted off the USB stick, and listing out the contents of lost+found showed that there was nothing there:
Although the files were deleted off of the USB, the data isn't necessarily removed from the disk right away. Instead, it's marked as free space that can be overwritten by new data. The strings utility can be used to search /dev/sdb for ASCII strings and extract any contents that have yet to be overwritten on the disk. Using this tool can lead to the discovery of strings that reveal important information, in this case, the root flag.
