CTF Walkthrough – DerpNStink:1

Hi all! Welcome to another CTF Walkthrough guide, today we’re going to be tackling the DerpnStink:1 CTF available from Vulnhub created by Bryan Smith. This CTF isn’t too bad, it has examples of why you should keep plugins up to date and more. There’s 4 flags to capture and you need to get root in order to win. You also don’t need to decrypt the flags as they hold no value.  If you don’t want to read through this guide then feel free to watch my full video guide located at the bottom of this article. Also if you want to stalk me on social media feel free! My twitter is @Jackk1337 / @JackkTutorials, Instagram is Jackk1337, Facebook is JackkTutorials & finally my YouTube is JackkTutorials. Anyway… Lets begin…

To start with it’s a case of finding the IP Address of the target machine, luckily this isn’t difficult at all with a simple Nmap scan to find our target and running services. Issuing the command ‘nmap -sS′ scans my network and finds all devices and services. Considering Kali & this CTF is the only thing on the network this command is fine. Here are the results…

[email protected]:~# nmap -sS

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-28 17:49 BST
Nmap scan report for
Host is up (0.00013s latency).
All 1000 scanned ports on are closed
MAC Address: 00:50:56:ED:84:CE (VMware)

Nmap scan report for
Host is up (0.00038s latency).
Not shown: 997 closed ports
21/tcp open ftp
22/tcp open ssh
80/tcp open http
MAC Address: 00:0C:29:03:73:E9 (VMware)

Nice and easy, we have 3 services to play with… Lets take a look at the HTTP service first. So browsing to the IP Address gives us this:

My general rule of thumb when it comes to CTF websites is that if the creator has designed some kind of webpage then I will inspect the source code and see if any flags are hidden there. If it is some kind of CRM then I don’t bother. So in this case I inspected the source code to see if I could find a flag. Hitting F12 brings up the Developer Console and I had a look through the simple source code and found the first flag hidden in a bunch of  nested <div> tags.

So we have our first flag:



So I also checked our the ‘robots.txt’ file but there was nothing of use there. So I loaded up Dirbuster and gave the URL a quick scan to find some folders and files. After a couple of seconds I had some results:

So I found some directories here. /webnotes had nothing of interest in it, however /weblog gave me a DNS error as it was trying to resolve derpnstink.local. Easy enough to sort by just adding the domain to my hosts file and trying again… And what do you know… WordPress!

After a quick look around I found nothing of interest, so it was time to start getting access to the webserver via wordpress. So I headed over to /wp-login.php and guessed the login credentials of admin:admin… But wait! The admin account isn’t an admin account! All I have access to is the slideshow… But why would I only have access to the slideshow… Lets load up wpscan and see if there is an issue here.

You can see from the screenshot that there is a Arbitrary File Upload vulnerability which is going to allow me to upload a file to server… Like a webshell… Let’s do it. So I researched the vulnerability on exploit-db and found a python script that can upload a webshell to the webserver with just the admin credentials. So I downloaded that and gave it a go (The script is here and details about the vulnerability is here).

There’s a lot going on in the above screenshot so I’ll explain. On the left I have a msfconsole session running waiting for the connection from the webserver. Top right I’ve generated a php shell using msfvenom and on the bottom right I am using the script from exploit-db to upload that shell to the webserver. If you look at the msfconsole terminal you can see that browsing to that link has given me shell access. So that’s good!

So now that I have shell access it’s time to have a look around. What I’ve found is that in the /home directory there are two other directories called /mrderp & /stinky. But www-data cannot access these. Also there is now privilege issues after checking with unix-privesc-check. Also the /root dir is off limits. So I decided to go back to the /var/www/html folder and take a look in the wp-config.php file (The configuration file for WordPress). My plan was to check the database and bruteforce the true WordPress admin account.

So the above screenshot shows that I have taken the login details from the wp-config.php file and used them to view the data in the wp_users table where wordpress users are stored. My plan is to bruteforce the hash with hashcat to get the password and see if that password can get me anywhere else. So I take the hash, load it into hashcat and proceed to crack it.

[email protected]:~# hashcat -a 0 -m 400 hash.hash /usr/share/wordlists/rockyou.txt

This command specifies to do a wordlist attack on the hash file in ‘hash.hash’ using the ‘rockyou.txt’ wordlist. The hash type is 400, also known as phppass(WordPress)

After not too long I found the password to be ‘wedgie57’. So lets go find some user accounts on this linux box by downloading the /etc/passwd file and taking a peak. Inside there we find…

stinky:x:1001:1001:Uncle Stinky,,,:/home/stinky:/bin/bash
ftp:x:118:126:ftp daemon,,,:/srv/ftp:/bin/false
mrderp:x:1000:1000:Mr. Derp,,,:/home/mrderp:/bin/bash

Alright so we go two user accounts here. Stinky & MrDerp. The true admin account of the WordPress site was a user called ‘unclestinky’ (Refer to table dump screenshot) so maybe the same password was used twice. Lets try SSH…

Alright so we’re not allowed in at all. Cool… What about mrderp’s account?

Mrderp accounts allows us to use a password but I couldn’t guess it or bruteforce it. What about ftp? We haven’t looked at that yet…

That worked! The credentials stinky:wedgie57 worked to login to this account. So I had a look around and found some files of value. That was a conversation about a network packet capture that could be saved somewhere on this linux box, and also a RSA private key.. Probably for the SSH account. Nothing else on this box, so I took the key.txt file and left the FTP account and returned to the terminal to try attempt another login with the [email protected] account but passing in the key file.

And there we go, we have SSH access to stinky’s account. So I had another look around here and found the network capture that mrderp & stinky were talking about. Opening it up in wireshark I filtered the traffic to HTTP and only looked at the wp-login POST data to see what login attempt was made.

The first login is by unclestinky into wordpress. We already knew his credentials…

The second login is mrderp, assuming that he’s used the same password on his account for SSH we can probably login. So I gave it a go…

With that password I was able to login.

The next bit took a bit of digging, but essentially there is a helpdesk log that has a pastebin url in it. Visiting the pastebin link gave this result:

mrderp ALL=(ALL) /home/mrderp/binaries/derpy*

What this shows is the commands that run as root using mrderp’s account. So I created a .sh file in a new directory called binaries with the following:



And when I run the command

sudo /binaries/derpy.sh

it escalates us to root!

And there we go, we are root! Not too bad… Let’s talk about the flags.



This was found a nested <div> tag on the main webpage.


This was found on the true admin control panel on wordpress when logging in as unclestinky


This was found on the Desktop of stinky’s user account


This was found on the Desktop of root’s account.


So there you go! 4 flags and root on this CTF. I hope you enjoyed the walkthrough! More to come… Below is my video of the walkthrough!

Leave a Reply

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