The Lab

Before we get into the technical aspects we need a place to work to test out tools and ideas. If we did this on any website it would be called hacking, and we don't want to do that. So, to that end I have created a lab that is sheltered from the Internet (and my normal home network for that matter). Other then some Windows licensing everything else I use is free.

The physical

I have one system with a dual core Xeon processor, 5 GB of RAM and 150 GB of hard drive space. I know it's fairly dated hardware, but it will be enough for our needs. Of course you can use anything you have, there is no real need to go out and buy something new just for this.

Software

I am running CentOS as the main operating system with Virtual Box to host multiple virtual machines (guests). I'm using CentOS because I'm comfortable with it. I've been running Red Hat based systems since it came on floppies, but I digress.

Let's move on to selecting what we want in our lab. Here is my short list of systems I have running; BackTrack5R2, 2 x Windows XP, Metasploitable, DVL (Damn Vulnerable Linux), Linux web server hosting Web Goat, and Windows 2003. I also created a simple VM that I can load a bootable ISO image into.  You may have noticed I have two Windows XP machines running.  This is so I can use one for Windows based tools (as an attacker) and one as a target.

Now that you have an idea as to what operating systems you want to run it's time to build some VMs.  To help maximize hardware resources I do not run a GUI on the hosting server, which means we'll have to set up the VMs from the command line.  Don't worry, it's easier then you think.  In fact here's a quick script I put together to make it even easier.  Of course this is something I wrote with my needs in mind. I would recommend examining each option and tweak it to meet your needs.

#!/bin/bash


# Vars
# -----
LOGFILE="VM_Setup_Log.log"
VMNAME="BackTrack"
OSTYPE="Linux"
HDSIZE="20000" # 20GB
ISOPATH="/VM/ISOs/"
ISONAME="BT5R2-GNOME-32.iso"
VMPORT="5007"
RAM="1024"
BASEFD="/VM/Machines/"
BASEHD="/VM/HardDrives/"
NIC="eth1"



# Build the VM
VBoxManage createvm --name $VMNAME --ostype $OSTYPE --register --basefolder $BASEFD
VBoxManage createhd --filename $BASEHD$VMNAME".vdi" --size $HDSIZE
VBoxManage modifyvm $VMNAME --memory $RAM --acpi on --boot1 dvd --nic1 nat --nictype1 Am79C973 --nic1 bridged --bridgeadapter1 $NIC --cableconnected1 on --pae on --audio none --clipboard disabled --usb off --snapshotfolder $BASEFD$VMNAME"/SnapShots"

VBoxManage storagectl $VMNAME --name "IDE Controller" --add ide --controller PIIX4
VBoxManage storageattach $VMNAME --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium $BASEHD$VMNAME".vdi"
VBoxManage storageattach $VMNAME --storagectl "IDE Controller" --port 0 --device 1 --type dvddrive --medium $ISOPATH$ISONAME
VBoxManage modifyvm $VMNAME --vrdeport $VMPOR

 

Much like CentOS, I'm utilizing Virtual Box due to my familiarity level. Since I'm not running a GUI on the host (the actual physical server) all VMs run in “headless mode”. This can easily be accomplished by starting the VM from a command line with something like: VBoxHeadless --startvm BackTrack (where BackTrack is the name of your VM).

Tip:  Put an ampersand (&) sign after the command to run it in the background.

 Now that the VM is running in headless mode we need a way to log into it.  Point your remote desktop client (rdesktop on Linux) at the IP address of the host server and the port number you set in the script (the VMPORT variable).  It should look something like rdesktop -g 90% 192.168.1.1:5007.  This will give you access to the console of that virtual machine.

Tip:  Don't forget to allow the ports you use through your host firewall.

And here is what it looks like.  If all has gone well you should now have a basic lab up and running, ready for use to test out tools.

 

Footprinting

Now, assuming all went well in the pre-engagement meeting we should have our scope defined so we can get to work.

The first phase of any pen test is to footprint, or learn about your target.  Depending on the level of testing the client is requesting this could be quick or a quite extensive endeavor.  We'll assume the client has given us little information so we discuss footprinting in a bit more detail.

The easiest way to start would be to do online searching with Google.  Although not directly related to penetration testing, the book "Google Hacking" offers many great examples of how to utilize Google for in depth information gathering.  Other good places to search would be; DNS records, Whois, social media sites, archive sites, career sites, blogs & forums, government sites, and Internet Authority sites.  Each one of these yields different information that could be useful in a pen test.  I don't have time to cover each of these, so I would recommend exploring a few of them on your own.  It should also be noted that this is by no means an exhaustive list of places to look, but it should give you a good starting point.

Other techniques that would fall into the category of footprinting would be; assessing a physical location, dumpster diving for information, and social engineering of employees. Again, I don't have time to cover these at this point (maybe later).

Now, depending on what you find from all your searching you may go down very different paths.  To keep it somewhat simple we'll pick an easier scenario.

Let's say we've been asked to footprint the Acme Corporation to see what information they might have online.  First let's take a look at their corporate site and see what we can find.  Although websites are designed to be viewed online it would be a good idea to pull a copy down to your local system so we can take a closer look at it.  This can be done with a tool or something as simple as utilizing wget from a Linux terminal.

Why pull down the site you ask?  So we can review the code of course.  Like all of us coders have a lot of work to do so they forget things from time to time.  The developer may have left useful comments or other goodies in the code that will give us some insight.

While examining the Acme site we notice there is a careers section.  We see there are a few openings in IT, one of which is for a web developer.  In the posting they are looking for someone with ASP.NET and SharePoint knowledge.  This tells of a few things about their environment right off.  First, it sounds like they're heavy into Microsoft and second they either host or at minimum develop their own sites for internal and external use.  This is important because if we find useful information during our code review of their external site, some of that information could be helpful once we're inside.

Along with the career section on the corporate site we also find several openings listed on other job sites.  This helps us paint a picture of what type of technology they are using.  This may not help us at this point, but will become crucial later when we get inside.

This is an over simplified example, but I hope it helps get the point across.  Footprinting is often over looked or done to quickly.  There is a lot of information out there that people may not be aware of.  This is by no means an all encompassing guide to footprinting a company, this is just the tip of the iceberg.  Having good information will make the testing good better and quicker.  As they say, a little pre planning pays dividends later.

Pre-Engagement

Since we're talking about penetration testing and not hacking, we need to first have a conversation with our client (target) to find out what they want from the test.  Given that we're the good guys we should only be doing this type of testing after we have a customer requesting a test of their systems.

Like most things there are different levels of a penetration test.  It could be as simple as testing a specific set of IP addresses, a single physical location, or even just one web application.  Or the testing could be as complex as performing a full simulation of an attack and do exactly what a real attacker would do.

The complexity will also be guided by how much information the client gives us.  If this is a smaller assessment they may give us all the information we need; username/password, IP addresses, etc.  This would be known as a "white box" test.  On the other end of the spectrum there is what's known as a "black box" test.  In this scenario little to no information is given, and we must go gather all the information ourselves.  The client may also choose to limit the number of internal people who know about the test.  This gives the added advantage of testing their response mechanisms.

Regardless of the complexity of the test, you should require a written and signed document giving us permission to perform these tests.  Since some of our actions can boarder on illegal activities, it is extremely important to have written permission from you customer up front, before beginning any work.

To learn more about pre-engagement activities please see the Penetration Testing Execution Standard.

The Beginning

Why this blog?

I'm starting this blog to document my education into penetration testing. I have been in security for quite a number of years now, but I never had the opportunity to perform a honest to goodness penetration test. I have been taking some classes and doing research into this arena and it appeals to me. So much in fact, that I have decided to dedicate most of my free time to learning more about it.

Given my years of experience I will be assuming the reader has some knowledge or security.  If I talk about a topic or technology you are don't know, please ask.

I have no doubt that there will be mistakes made and challenges to over come, but I'm up to that task. I invite everyone with a desire to learn along for the ride.

Are we going to learn how to hack?

No. This is not going to be a tutorial on how to become a hacker; on the contrary, we will be focusing on penetration testing. Some think of a penetration tester as legal or ethical hacker. Although that might be 'technically' true, there's more to a penetration test. In this blog I hope to cover all aspects on becoming a good penetration tester. This will include things such as; Proper procedures, tools & techniques, and of course creating reports.

What tools will you use?

Good question. Of course there are the staples; BackTrack, BurpSuite, Nmap, Metasploit, Nessus, etc. I plan on covering these for starters, but I have no doubt I'll find new ones along the way. All the tools and code I find or create will be documented here in this blog, free for anyone to use and learn from.