Vulnhub – (TopHatSec) Freshly Writeup

Here goes with my first writeup of a VM from Vulnhub, of the “Freshly” VM courtesy of TopHatSec. (I hope to not ramble on with this post….but no promises!)

This challenge appealed to me as it is a Web-based attack one, which i feel i’m pretty strong on. So after downloading the VM (OVA), and importing it into VirtualBox, first things first is to find the IP address of it on my VirtualBox Host-Only network.


netdiscover-result is the IP of the VirtualBox “Host-Only” network DHCP Server. is the IP of the VirtualBox “Host-Only” network host adapter(on my laptop) is…..well theres no other VM’s running, so this must be our target IP.


Next it’s time for a quick and simple scan with NMAP to see what ports are open.


OK, so looks like we have Apache running, and listening on 3 different ports, 80, 443 and 8080. Lets have a quick browse of each, see what we see.

Port 80


Thanks Obi-Wan Kenobi!.  Not much else on this page, the source code simply points to the animated gif.

Port 443

Accept the invalid cert warning and we get:


K….again, a quick view of the source code and it shows us some JavaScript code, which i’m assuming performs the re-direct when you click the link…..but i’m hopeless on JavaScript, so just ignored it for now.

After being directed, we get to what looks like a WordPress site for a site called “Old Candy Site”.


Port 8080

This looks like the same page as the one running on port 443, just not HTTPS.

I first targetted the WordPress site running on 8080, as i know WordPress has a heap of vulnerabilities.   A quick scan of the site using wpscan, gave the following results (condensed to show the bits we care about)



OK, so theres a few plugins that have vulnerabilities.  I did check out the links provided by wpscan for each one.  The Cart66 Lite SQL Injection vulnerability required that you already be logged in for it to work, so i ignored this.

The ProPlayer SQL Injection vulnerability looked like an issue with the file playlist-controller.php not sanitizing input correctly.  When trying to play the video on the front page of the site (played using ProPlayer) it just sat there and seemed to be buffering.


Closer inspection of the source code for the page, showed it was trying to play a video titled “Vintage-Old-1970s-General-Foods-Pop-Rocks-Candy-Commercial.mp4” but from a WordPress site running on IP


If i changed the IP it was looking for to the current server IP, and tried browsing for the video it displayed it OK.  So maybe simply an old reference to the original sites IP?  Or something for us to maybe exploit?


I started digging into anything we could do with this, but didn’t get anywhere…so left it.

The 3rd and final WordPress plugin exploit for the “All In One SEO” Authentication Bypass seemed to be related to being able to modify a meta tag without being authenticated, again, didn’t seem too interesting, so i left this too.

I quickly checked to see if we could access the WordPress admin page on /wp-admin, and we could.  Something to remember for later.wp-admin

OK…so nothing majorly obvious yet, so i now turned back to the site running on port 80 showing the Star Wars gif.

There was no robots.txt, so i thought i’d check to see what other directories might be on the site, using DirBuster. (I usually use the wordlist “usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt“.


And straight away, it finds the a php file named “login.php“.


A quick look in our browser:


Ohhh, whats this?  Looks like a simple login box, lets throw some values in there. (I used “abc” for the username and “def” for the password)


It returns back a “0“.  OK, and how about the ole “‘ OR 1=1 —  trick in the username field.



OK, so this time it returned a “1 so maybe it’s returning the number of returned rows for the result.   At this stage i tried various things, including adding in some UNION SELECT statements, but it didn’t seem to return much, other than the “0” or “1“.  No other info, no SQL errors…nothing.  As it looks like this is some kind of SQL query thats happening, i fired up sqlmap, and see what it could find.

(Note At first i wasn’t having much luck, my sqlmap wasn’t returning anything of interest, and seeming to not find the fields injectable.  I then realised i was running an OLD version of sqlmap…so first things first i cloned a new version using git.)

(Another Note – As we want to get sqlmap to test against the fields on login.php, we need to provide it with some data to be sent using POST.  A nice easy way to get this info, is to enter the values as before and run the request through Burp Suite, it will capture the POST data request.


OK…so lets fire off sqlmap, see what it finds.


Ohh, looks like the “user” field is vulnerable to “time-based blind” injection…whatever the hell that is.

At this stage, i then started enumerating any database info i could (database names, table names, columns etc)

List Databases



OK, so theres 7 databases.  We can ignore “information_schema, mysql, performance_schema and phpmyadmin” for now.  The login database contained some entries, but nothing special and users seemed to be empty.

But i wonder what the database named “wordpress8080 could be for?  Maybe a WordPress site running on port 8080?  We’ll now dump the contents of this database.


Now as i mentioned before, this is a “time based” SQL injection, which i’ve never heard of before.  This site gives a good explanation of it, but the jist is, that depending on how long the SQL server takes to respond to a request, you might be able to get information out of the database.  This does mean that results returned to sqlmap aren’t instantaneous, and take a while.  To give you an idea of how long it takes…here’s a nice little animated gif 🙂


But eventually we get all the info.


Nice, so looks like we’ve got some possible credentials for the WordPress site, lets give it a go.

wp-login wp-success

WooHoo!   OK…so we’ve got admin rights to the WordPress site, but we ideally need to be able to browse and access the underlieing filesystem…which i know can’t be done from within WordPress.  The solution?  We’ll as we can create a page on the WordPress site, lets do it….but lets create a much more fun page….a PHP web shell page 🙂

There are a few ways todo this, either modifying an existing PHP file on the site, such as the 404.php file.  But for this example i’m going to create a WordPress plugin, upload it, then use it to gain access to the server filesystem.

There are various types of PHP web shells, some that allow various functions, some php reverse shell ones which connect back to a listener you have running.  For this, we’ll just use the following simple code:

 Plugin Name: Super Fast WordPress Plugin!!!
 Plugin URI:
 Description: Makes your WordPress site run 200% faster!!!
 Author: dook
 Version: 1.0
 Author URI:

The first few bits, are some items which WordPress requires for a plugin…as you can see, i gave it a nice name, and description 🙂

The “guts” is the last line…which is pretty basic.  It takes a user provided value (e.g “ls”) runs that command, and returns the result.

The code is saved as “dookshell.php” then zipped up into a file named “”.

Now back in the WordPress admin page, we browse into “Plugins” section select “Add New” then “Upload Plugin”.  Browse for the zip file, and select “Install Now”.


Once uploaded successfully, it’s Activated using the link, then we’re taken back to the Plugins list, and it should be listed along with the others.


Cool, so it’s uploaded, activated and happy.  To access and use this plugin, browse to: then add ?cmd= then whatever we want to run, so for example “ls“.

So the full url will be:


And we get a directory listing…in this case of the dookshell directory, which just contains our webshell file.

At this point, i started looking around for a “flag” or a “secret” file.  Nothing in the www directory, nothing in root, we can’t access the “root” directory, as this PHP file is running with the rights of the web server.  I then decided to see if i could display the contents of /etc/passwd using “cat”.




WooHoo!  I really enjoyed this challenge, as i’ve recently been learning more on SQL Injection. Now there are apparently a couple of ways to get into this VM, so i’m going to have a bit more of a snoop around, and if i find another way in, i’ll do another writeup.

Cheers VulnHub! And Cheers Top-Hat-Sec!


Leave a Reply

Your email address will not be published. Required fields are marked *