VulnHub (BSides Vancouver: 2018 (Workshop)

It’s aboot respect, it’s aboot dignity, it’s aboot getting root.

As always we started with an nmap scan.

Nmap -sC -sV -v -p- -oA nmapAll

From this we determined that there were three open ports 21, 22, and 80.

Since port 21 showed that anonymous login was allowed, we tried browsing to the page. We found a text file containing possible users.

Great, we found a list of possible users which should come in handy. We switched our focus to port 80 and we took a look at the “robots.txt” file.

We determined that there was one entry in the robots.txt file which by the path name is probably a wordpress site.

Browsing to that path we found a wordpress blog. Based on the blog post we assume that the IT administrator John is the administrator for this site. We also assumed that his username is “john” based on the user text file we found earlier.

Since the user list is small and using some lessons from the Mr. Robot VulnHub VM, we just manually tried usernames from the users text file to determine their existence.

Using this technique we determine that the users “admin” and “john” are users on the site. We determined this by the error message stating the that password was incorrect. For a user that did not exist it simply stated “invalid username.” Also by looking at the blog posts on the site, we arrived at the same conclusion.

Note that the only two posts were authored by the users “john” and “admin.”

Our favorite wordlist for brute forcing in CTFs is “10k-most-common.txt” from SecLists. This can be found at Using this wordlist, we leveraged the password brute force function in WPScan.

WPScan did not provide a clear hit but stated an unknown response on the combination “john” and “enigma.”

With this username and password combination, we attempted to login.


At this point we normally go the Appearance tab and leverage the Theme Editor function to modify one of the php templates with some malicious php code to generate a reverse shell. Since we were being lazy, we decided to automate this process and utilize Yertle to upload a malicious plugin which generates a reverse shell for us.

Before launching the above command. We started the netcat listener below.

We obtained a shell and had access to the user “www-data.” With this access, we did some basic enumeration to determine other users on the machine. We accomplished this by view the “/etc/passwd” file.

We determined that there were five interesting users which correlated to the users we found initially in the text file on ftp. After poking around the home directories of the users and some configuration files, we found what appeared to be the mysql username and password.

We were unable to authenticate with the credentials “john” and “thiscannotbeit” locally to the mysql service. Also we were unable to ssh with the credentials assuming that passwords were reused. Ssh was using key based authentication for john. Anne allows password authentication but we were unable to determine the credentials. Guess “thiscannotbeit” really wasn’t the password.

Next we uploaded to the machine to automate some of the enumeration process for us. We used the “-t” flag for thorough checks.

Based on the script we found some interesting results. We saw that the cleanup file was owned by root and was able to be modified by anyone.

We determined that the cleanup file executes every minute by the root user.

Viewing the file, we determine that it was cleaning out the apache logs.

Next, we created a simple reverse shell script on our local machine.

We utilized “wget” which was already present on the victim machine and overwrote the cleanup file with our malicious one.

We started a netcat listener and waited for the cronjob to execute.

We got shell and the root flag!

Extra: The root flag bothered me indicating that there are other methods so I decided to keep digging.

Using hydra we found the password for the anne user.

Note: The IP changed because I kept digging using my Desktop. I was utilizing my laptop for initial access.

Luckily “anne” has sudo access to all commands and we can simply switch to root.

It also seems to be vulnerable to dirty cow but as expected it is not extremely reliable and although would provide me root would crash shortly after.