I’m always on the lookout for VulnHub VMs that teach real pentesting skills, and are not just puzzles.  I like them to be practical, and force you to learn techniques that you would use in the real world.  I feel Donkey Docker is one of these challenges.  As always we can begin with an nmap scan:

Not too much to go after, just HTTP and SSH.  Since this version of SSH is relatively current, let’s just stick to HTTP for now.  When you go to the URL you will see a nice little welcome page.  At this point we will spider the application.  You can use multiple tools to do this, but for now we can manually browse as there are only a few pages.  Whenever you visit a page, it is a good idea to inspect it through an HTTP interception proxy or by viewing the source code.  When browsing the “About” page, you will find an interesting HTML comment:

We will keep this in mind for later.  On the contact page we see a form.  These are usually interesting because they accept data provided by the user.  The functionality seems to be that of a contact form.  To further enumerate this application, we can hit it with dirb.  I recommend this for any web app as it can help find additional functionality. returns a HTTP 200 OK.  When we browse to this page, we can see it is for PHPMailer.  After going to Google and searching “phpmailer exploit” or “phpmailer vulnerability” it because clear that this software had some recent flaws.     We can find two recent CVEs, CVE-2016-10033 and CVE-2016-10045.  It’s always nice to get an easy win, so lets query Metasploit for a PHPMailer exploit:

We see two modules.  One of them is for WordPress, and as we have not found any evidence WordPress is running here we will stick to the first one.  We can go ahead and load this module and populate it with the information we know about the application.

  • We set TARGETURI to “/contact” because  that is where the mail form is located.
  • We set TRIGGERURI to / because we are assuming this will upload our file at the base of the web root.  We don’t really have any way of knowing this for sure, but we can take a guess.
  • We set the WEB_ROOT to “/www” based upon the clue we found in the HTML comments.
  • Set The RHOST to whatever IP Donkey Docker is at.

And then we exploit.  Now, depending on when you try this, it may not work.  That is because this Metasploit module originally did not follow re-directs on the trigger URI, which is needed to trigger the payload once uploaded.  I created a pull request for this, perhaps when you are reading this it is merged into the master branch.  If not, you will need to modify a line of code in the module, or hit the URI manually in your browser.  If you need to modify the code, look for the call to “send_request_cgi” and add an exclamation point at the end of the function like so:

After running the exploit you should see something like in this screenshot:

Once we have a shell we can do some basic enumeration.  Lets see what files are on this host:

main.sh is interesting.  Any scripts are usually worth investigating.

This script shows that there is a flag in /home/smith.  Lets take a look at the /etc/passwd file:

There is the smith user.  As silly as it may be, for this part of the challenge the password for smith is simply “smith”.  We can switch to the smith user by dropping into a shell and getting a TTY so we can enter a password interactively:

Now that we have user privileges, lets go ahead and pillage anything useful out of his home directory:

Aside from the flag, there is something interesting in the .ssh folder.  We have what looks like a private and public ssh key.  As we know from out nmap scan, SSH is open this host.

As we can see from the public key file, this SSH key can likely be used with the “orwell” user.  Lets go outside of our meterpreter shell and try to SSH in with that private key.  Copy the key over and set the permissions.

Now that we are SSH’d into the system, lets attempt to enumerate our current privilege level:

As you may have guessed, this next step may have something to do with Docker, as per the name of the VM. We can go back to Google to get some hints on what to do next.  I Googled “docker privilege escalation” and found this as the first result:


Here is a select like from the website that is quite useful:

“If you happen to have gotten access to a user-account on a machine, and that user is a member of the ‘docker’ group, running the following command will give you a root shell”

First off we can use the docker container command to see what containers there are.  To learn about the available docker commands, you can always use docker -h to get more info.

We can see that there is a container named “donkeydocker”.  Lets try to execute a command inside that container.

We can see by supplying the -i flag for interactive, the -t flag for a TTY, the donkeydocker container name, and a command such as /bin/bash, we can execute a root shell within the container.  It may seem as though we are done at this point, but we have to remember that we are “root” but only within that container.  It would be much better to see what exists outside just this container.  We can do this by mounting another container and using donkeydocker as a template, and mounting the actual root filesyem under “realroot”:

Now we have a new container.  Lets enter a root shell on that container like we did before:

And now we can see everything., including the final flag at /realroot/root/flag.txt.