Mr Robot

IP: 10.10.168.220

With a quick nmap -T4 10.10.168.220 we see that we'll be dealing with at least SSH and HTTP(S).

Nmap scan report for 10.10.168.220
Host is up (0.20s latency).
Not shown: 997 filtered tcp ports (no-response)
PORT    STATE  SERVICE
22/tcp  closed ssh
80/tcp  open   http
443/tcp open   https

We'll run another scan to gain version information on these services: nmap -sVC -T4 10.10.168.220 -p22,80,443 -oN nmap-versions.txt

PORT    STATE  SERVICE  VERSION
22/tcp  closed ssh
80/tcp  open   http     Apache httpd
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache
443/tcp open   ssl/http Apache httpd
|_http-title: Site doesn't have a title (text/html).
| ssl-cert: Subject: commonName=www.example.com
| Not valid before: 2015-09-16T10:45:03
|_Not valid after:  2025-09-13T10:45:03
|_http-server-header: Apache

Let's start out by checking the website for vulnerabilities. Navigating to 80 in the browser brings us to a cool interactive Mr Robot style simulated login page, with some options we can run to watch short videos.

Navigating to https://10.10.168.220:443, however, presents us with a security risk warning due to the self signed SSL certificate (which we see is for www.example.com in the nmap scan above). I'll add this to my /etc/hosts file and check it out in the browser again, accepting the self-signed certificate to open the page:

Not surprisingly, we're served the same page as we saw on port 80, but we now have TLS encryption between us and the server...

I'll go ahead and continue exploring with the HTTP site on port 80 for now.

Entering join we're prompted for an email address. I enter a bogus one and it seems to accept it, saying "we'll be in touch".

This main webpage doesn't seem to have anything interesting for us, so let's start enumerating subdirectories with gobuster: gobuster dir -u http://10.10.168.220 --wordlist /usr/share/dirbuster/wordlists/directory-list-2.3-small.txt

Immediately, we find many useful looking results, including /sitemap, /0, /admin, /wp-content, /wp-login, /page1, /readme, /robots, /dashboard, and many others. It seems that this site is running on WordPress, which could be a potential entry point depending on the version and what pages we have access to.

In /license we find some some interesting strings: "what you do just pull code from Rapid9 or some s@#% since when did you become a script kitty?"... "do you want a password or something?"..."ZWxsaW90OkVSMjgtMDY1Mgo="

Decoded from base64, the final string reads elliot:ER28-0652, which could be a login for the WordPress admin portal.

Continuing with other eyecatching directories, we find: - /readme - "I like where you head is at. However I'm not going to help you" - /robots: - User-agent: * fsocity.dic key-1-of-3.txt"

From here, we can navigate to /key-1-of-3.txt to obtain our first flag.

At this point, I thought that hypothetically, it might be beneficial to switch to the HTTPS site so that our traffic is encrypted, especially since I'd now be submitting credentials (and trying to exploit the WordPress Server), and having this encrypted might make this more difficult to monitor/detect.

Using the potential credentials from eariler (elliot:ER28-0652) we're able to login to the WordPress Admin Dashboard for "user's Blog" at /wp-admin.

From this point, I want to get a reverse shell onto the machine. Let's try by abusing the theme editor: I'll start by saving and modifying a php reverse shell like that from PentestMonkey: https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php

In other rooms, I've modified the 404 Template to execute a reverse shell, so that's what I'll try first:

Modified 404.php template file for the Twenty Fifteen Theme

Open a listener on attacking machine with rlwrap nc -lnvp 53

Navigate to https://www.example.com/wp-content/themes/twentyfifteen/404.php in the browser to establish the reverse shell.

Sure enough, it worked! I'll upgrade this shell to be interactive: python -c 'import pty;pty.spawn("/bin/bash")'

In /home/robot we see that there are two files: key-2-of-3.txt and password.raw-md5, the latter of the two containing this string: robot:c3fcd3d76192e4007dfb496cca67e13b.

Before we try to crack this hash, I'll use hashid to ensure we aren't being deceived by the filename; it looks good.

Ran on attacking machine hashcat -a 0 -m 0 tocrack /usr/share/wordlists/rockyou.txt -o cracked.txt; cat cracked.txt

Using HashCat, we find that the original password is abcdefghijklmnopqrstuvwxyz.

Now we can su robot and enter this password to gain access to the robot user account and cat the second flag in this home directory.

I'm assuming the 3rd flag will require root privileges, so we'll start looking for privilege escalation vectors. Running sudo -l states: "Sorry, user robot may not run sudo on linux."

Now being a little stuck, I looked at the hint for the final key, which simply reads "nmap."

By running find / -type f -perm -04000 2>/dev/null to find binaries that have the SUID bit set, /usr/local/bin/nmap is in there.

I tried to follow https://gtfobins.github.io/gtfobins/nmap/#suid but didn't have luck, since we don't have sudo privileges with our current level of access. However, simply trying nmap --interactive and nmap> !sh as explained here gave me root.

Following the naming convention of the first two flags, we see that the final one is located in /root, and we're now able to submit it to finish the room.