NOTE: This is not a tutorial on the Mr Robot machine hosted by Try Hack Me. It is simply an overview of the strategy used to defeat the box, and a reference for that strategy.

The target machine was a simple server hosting a webpage. Other than the web ports, and SSH, there was nothing else to exploit. I ran across the wordpress construct right after I did a dirbuster search on the box. As soon as I saw ‘wp-content’ in the list, I felt pretty comfortable about the organization of the folders. Knowing the wordpress structure through years of experience allowed me to notice if anything of importance stood out. It also allowed me to play with a tool with which I don’t have much experience… wpscan.

It’s not uncommon to run multiple scans at once and look at results in real time as they present themselves. I mentioned the dirbuster results, but also ran wpscan as soon as wordpress was discovered. I didn’t have many results on that tool other than some suggestions for referenced attacks using meterpreter (wasn’t interested in that here), and some information about versions.

Two things stood out for me: the theme with an out of date version, and the robots.txt file that was found. I went down the path of the twentyfifteen theme first. Using Google, I found references to a ton of cross-site scripting attacks. I definitely wouldn’t mind doing that, but i have not gone heavily into web app testing at this point in the journey; so I wanted to stay away from that if possible. I spent around fifteen minutes researching what was possible, and learning at the same time when I decided to move on. Robots.txt was the next thing to explore.

In all of the courses and books that I’ve read, it says to enumerate the easy things. In this case, it was as easy as following the link in the screenshot above; so I did. This revealed a couple of files. One was called key-1-of-3, and the other file was a .dic, which I assume is a dictonary. I went ahead and put in the first flag (key) and moved on to downloading that other file. As a side note, I would normally hate to download random things from ‘practice hacking’ sites, but I have a segmented network with a single instance of Kali, so I wasn’t worried.

The downloaded file was simple text, and revealed a listing of words similar to the common password file we all use on Kali called rockyou.txt. Having used many wordlists in the past, this one was pretty easy to figure out what to do; but I wanted to learn more about wpscan instead of reverting back to my hashcat program. I did what any hacker does… google’d the best way to use it. There was only one problem at this point, though… I didn’t have a user name to go with the password list. That’s when the Nikto scan came into play.

One of the concurrent scans that I ran alongside NMAP, Dirbuster, and WPscan was a tool called Nikto. I’m sure there are several more ways to use this tool more efficiently, but for now, I just run it directly against the host to see if I get anything interesting back. In this case, it was that file. After pasting it into a web browser, I got some stupid text making fun of me being a hacker… but I saw on the side of the browser that you could scroll down. I’ve seen several youtube vids where the hacker simply zooms out immensely to reveal any hidden items, but scrolling down in my case was just fine. On the bottom of the page was a base64 encoded string (it had the ‘=’ at the end). So I decoded it…

I found it unfortunate that the user name and password were staring me in the face there… it’s certainly great when something like gaining access to credentials is achieved, but this one could keep me from learning the other tools if it was a lazy night… but none the less, I now had a user name (and password). Fortunately for me, it wasn’t a lazy night! I was still interested in using WPScan to see if I could gain access to a password using that dictionary file. So on I played.

I don’t normally add syntax to these types of blog posts, but I think it’s pertinent since it was the first time that I learned the WPScan tool. So here’s the syntax that I used to find the password to elliot:

sudo wpscan --url 10.10.131.43 --passwords fsocity.dic --usernames elliot

There were over a thousand entries, and wpscan was taking quite a while to accomplish this task, so I decided to break it into 100 word chunks and run wpscan several times. I had no idea if this would work, but it worked like a charm. The password was found in one of those chunks, and matched the one that I previously found through the base64 decryption. Now, I had an initial vector into the box using these credentials.

The first stop was the login page, which worked like a charm. As I mentioned, I’m extremely familiar with WordPress, and know my way around. It was pretty easy to see that elliot had admin rights to the box. With his admin rights, it meant that I could change the php code in any of the pages instead of having to try out the cross site scripting stuff that I googled earlier. So using the quick reference page on this website, I googled for a php reverse shell code, and pasted it in. Doing this was great because every time I needed a shell, I could just refresh whatever page I put that code into… worked like a charm.

The shell that I got was owned by ‘daemon’ and was not a tty. Luckily, I had been through this several times before in other challenges. It was as simple as using a python script to spawn a tty shell. This shortcut was on my quick reference page too.

There wasn’t much I could do with these privileges, but again, I remembered some of the other challenges i had encountered called vulnversity. In a very similar situation where privilege escalation was needed, a find command was used to see which programs had SUID which lets the file run with the permissions of the owner, instead of the user trying to run the file.

So in this case, I was only ‘daemon’ but wanted to run files that were owned by others. Again, this is a good reference, so I’ll put the syntax here:

find / -perm -u=s -type f 2>/dev/null

Quite a few things were revealed there (and I tried quite a few), but the one that stood out was nmap and ping. There’s an interactive mode (had to google again which showed the mr robot tutorials for the ‘– interactive’ command for nmap. As a side note, I don’t mind using these when needed, and I highly encourage referencing writeups when stuck on a situation. In the same screenshot, it showed the ‘!sh’ (which I had seen before). Here’s my screen shot that led me down the path of escalation:

From there, with root privs, it was pretty easy to traverse to the /root directory and find the last key to the challenge. I don’t think I mentioned key number 2 in this. It was in the /robot home directory which is pretty common in these capture the flags scenarios.

So with that, the challenge was completed. All in all, it took me a bit under two hours to complete, and probably would have taken a bit longer had I not used the screenshot in the tutorial that I found.

Summary of Things Learned

Every challenge is fun, but in this one, I loved finding a WordPress installation to manipulate. I was sort of hoping that I could use more than just the WPScan to pwn the box, but in the end, it was simply a set of clues that led to the end result. I would go back and play with that cross site scripting, however at this point, I’d like to move on. I am reading a book right now called “Web Application Hacker’s Handbook” and will get more in depth with trying out these web hacks later on.

So what did I learn?

• Enumerate using the easiest things (robot.txt)
• Scan with multiple tools at one time (already my practice)
• Never be afraid to google for commands
• WPScan – fun, but there’s much more to learn
• NMAP –interactive, used to get a prompt
• !sh, used to elevate the shell (common)
• Watch out for rabbit-holes if you aren’t getting anywhere