Category: Pentesting Lab

When I set my lab up my primary concern was keeping costs fairly low. My needs were not, and probably still are not, for a powerful system. Just a capable one, even if only barely so. The setup I had fit the bill. A 90 dollar expense through eBay, another 25 or so for RAM got me a machine with dual Xeons, 32 GB RAM, it go the job done.

Then I turned it on. And then this happened with the power:

So in the interest of global warming and the future of humanity, I came up with another solution. I ended up on the SuperMicro e200-8d, which has a single Xeon with six cores, and 64 GB of RAM. All that with only a 60 watt power supply. This was significantly more expensive, though. Approximately 800 for the server alone and another 400 for RAM. I have enough room to expand to 128 GB but couldn’t justify the expense quite yet, given my usage.

Projects in the works: build my own AD forest, hook up some automation, enhanced pentesting lab, solve world hunger.

Here’s the new server sitting on top of the old one:

In Penetration Testing, Weidman walks you through pulling hashes from the Security Account Manager (SAM) database on a Windows machine. SysKey is the Microsoft utility that encrypts the SAM database. SysKey uses the bootkey for encryption, which is actually an amalgamation of four separate keys contained in hidden fields within the registry. Luckily there are some tools that do the hard work of extracting the key for us. 

In the text, bkhive is used to extract the key and then samdump2 is used to decrypt the SAM database and reveal the password hashes. The hashes must then be cracked using John the Ripper or another similar hash cracking tool.

When walking through the scenario in the text, there are a few issues. First, bkhive is no longer pre-installed on Kali. It isn’t necessary for it to be installed, as samdump2 can perform both functions, but the syntax is not readily apparent and searching on the Internet yields a lot of outdated information on using bkhive in conjunction with samdump2. Previously bkhive would be the tool that extracted the key from the SYSTEM hive and samdump2 would take that key, decrypt the SAM file. This gives you the password hashes and associated accounts for the machine. There are two solutions to get this working again: install older versions of bkhive and samdump2 software and use those or use samdump2 for both functions.

First, we’ll install the old versions. This is a bad way to do things, but doing this will allow you to follow the example in the text as written. This took longer to figure out than I care to admit.

The Kali repositories have bkhive available, however installing from the repo does not give you a usable application, instead building out directories in /usr/share and placing documentation in those. Older versions of the software are maintained online and can be downloaded:

wget http://http.us.debian.org/debian/pool/main/b/bkhive/bkhive_1.1.1-1_amd64.deb

apt-get install libssl-dev

dpkg -i bkhive_1.1.1-1_amd64.deb

 Now you have a version of bkhive that will work with the steps and syntax in the text. But the installed version of samdump2 still won’t accept the key as input, it is looking for the SYSTEM hive.

So to roll back the version of samdump2, first we have to install libssl1.0.0:

wget http://security.debian.org/debian-security/pool/updates/main/o/openssl/libssl1.0.0_1.0.1t-1+deb8u5_amd64.deb

dpkg -i libssl1.0.0_1.0.1t-1+deb8u5_amd64.deb

Now install the old version of samdump2:

wget http://http.us.debian.org/debian/pool/main/s/samdump2/samdump2_1.1.1-1.1_amd64.deb

Dpkg -i samdump2_1.1.1-1.1_amd64.deb

And now we follow the example in the text:

The simpler, and definitely preferable, alternative is just to use samdump2 for both key extraction and for pulling the hashes out of the SAM database. The syntax is pretty simple:

samdump2 SYSTEM SAM > hashes.txt

This command takes the location of the key to be extracted, the location of the SAM database, performs the extraction, decrypts the SAM database, and then outputs the results to hashes.txt. There are options for debugging if needed, available in the command help. Simple enough! Now using either method you have hashes ready to be cracked.

I wanted to add a little more detail to what I’m doing with reconnaissance, but I want to be careful not to just copy the stuff in the book. I don’t think that adds anything of value when trying to learn, plus I don’t think anyone would appreciate me uploading their book to the internet one chapter at a time.

So to take it a little further and focus more on OSCP objectives, as I’ve understood from my research, we want to do as much of this enumeration as we can without tools like Nessus. The first thing to try is running nmap scripts. Nmap comes with a ton of scripts loaded that can gauge for vulnerabilities, perform exploits, detect service versions, plus a ton of other things. For my purposes I’m only running the default scripts to just get an idea of what they do.

We get a ton of information here. From the top, we see FTP. It has run a script and tested anonymous logon and found that open. We can dig just a little deeper and see if we can find anything else with netcat:

Netcat displays the version and would allow us to log in. We can do a search and find that there doesn’t seem to be any exploits associated with this particular version of Filezilla. Moving on, we see that SMTP was listed along with a list of available commands. From here we can attempt to verify any possible account names we may think we have. The nmap scan shows us that ports 80 and 443 are hosting websites is XAMPP 1.7.2. We can verify this pretty easily:

We can use netcat again to connect and find out a little more information about the server. What kind of web server is it running? What supporting services?

This is my first time really using netcat operationally, I’m familiar with the functionality and syntax but now we’re in it. As you see above, I get what appears to be an error. Even though we get an error, we still get the information we were looking for. The server is running Apache 2.2.12, WebDAV 2 is running which we know from the text should be examined for default credentials, and php 5.3 is running.

I tried to dig more into the error and decided to fire up Aule (vulnerable Ubuntu machine that is designed for use with the book) and try that. So the website works:

And we try netcat:

And get a similar error, but again we get the header information we were looking for. This needs more testing, right now on every server I have with a website I get back the “bad request” error but it isn’t the end of the world since I get the header info and that is my objective right now.

One of the things the book points out about Lorien is that it is running phpmyadmin, because it comes in XAMPP. Since it is there in black and white, we know to check it. But how could we use a tool to find this out if it were not in the book? Using Nikto we can scan Lorien to see more information about available web interfaces:

I ran it this way to just get an idea of the output. For Lorien I got a lot of output and it was easier to pipe the Nikto results into a text file and go through it that way. Nikto enumerates each available directory and we can look at the web pages associated with those. Like the /server-status page:

The server information we have here matches up with the results of the Nikto scan, the netcat results, the nmap scan, the Nessus scan, and the OpenVAS scan. Which is cheating, since Nessus and OpenVAS actually use nmap. But still important to note the different ways to get needed info.

Further down the directory list we see /server-info:

Again, we see the server info. But there is much more. We have the root directory right there, which if we didn’t already know would help us with directory traversal. We have the location of various configuration files. Hey let’s look at at mod_alias.c, the Apache file that maps URL requests to aliases (among other things):

We see several accessible directories and can try each one. Hey look, it’s phpmyadmin:

We can look at this service and determine vulnerabilities, but the page is helpful as well:

Oh my…

There are some other issues to identify here from the book, but I’m more concerned with how to get the info on my own and using tools I know rather than just reading the vulnerability info from the book. We have enough information now to move forward. One thing I do want to investigate is credentials. From the book we know that WebDAV is running here with default credentials, however I need to identify the best way to discover that using available tools. 

This is finals/project presentation time at school so I have no idea when I will get a chance to move forward with my lab. At least a week I am thinking.

We perform reconnaissance in order to learn about the environment. This is a pretty simple concept, but important to keep in mind. Yes, you’re running nmap, but why are you running it? To identify system attributes. Why? Each action must be considered in context of the ultimate goal. The ultimate goal in our case is access to data on a target machine. How do we get there? Let’s break it down.

We do scans in order to identify attack surface and possible vulnerabilities. Easy enough, but important to consider when planning. Each tool may have strengths and weaknesses, but understanding what the tool is telling you is more important.

In my lab, keep these names in mind: Morgoth is our attacker (Kali rolling release, whatever they’re up to), Lorien is an XP machine running SP2, and Ulmo is a Win7 machine running SP1 with no updates.

To suit up first off we need to add a couple of things to Morgoth. Kali comes with a ton of tools but I want a couple non-standard ones just to have a comparison. Nmap is great and I know Nessus well, but if we’re going to do this I want to see what results look like from multiple sources and compare, then try and figure out why they might give different results. So I chose to install Angry IP Scanner and OpenVAS. Neither of these are tools I have any experience with but they give that alternative comparison.

Installing ipscan is simple, we open a browser on Morgoth and navigate to http://http://angryip.org/download/ and download the .deb file. Open a terminal and install:

sudo dpkg -i ipscan_(versionnum)_(cpu).deb

Easy. Now to install OpenVAS, the Open Security folks have kindly packaged it up and put it in the Kali repo. So simply run:

sudo apt-get install openvas

And there we go. At this point, I ran out of space on my hard drive and had to take a brief detour. So it goes. So a reminder, make sure the basics of your system are good, or at least take a snapshot of your VM so you don’t end up like me spending a day rebuilding. After downloading and installing OpenVAS, run the initial setup script:

sudo openvas-setup

This will set up the OpenVAS database and download plugins. It takes a bit of time. Once it is done, it will give you the admin password. Navigate to the web console at 127.0.0.1:9392 and you log into the console with admin as the username and the password generated during setup. It’s now ready to scan.

First we start off with nmap. I’m sticking with results on Lorien just to save time. Results are being recorded in KeepNote, an open source reporting tool included in the Kali build. Not going to waste time going through every option with nmap, for the purposes of this test I ran SYN, UDP, and version scans. The SYN scan results are below:

We should run ipscan at this point to compare the results. Type in ipscan at the command prompt to launch the ipscan interface. The tool is pretty intuitive, you input the IP of the target and run it. You do need to expand the port range if you are looking to do a port scan. Below is an example of a port scan with Angry IP Scanner:

The takeaway when comparing results between these tools is that they seem to be geared at different purposes. Angry IP Scanner is much quicker than nmap, especially on multiple targets. Nmap can provide more detailed information in a more easily exploitable format, so I think your choice really boils down to your goals. In each case ask the question: what is the tool telling me? We are seeing externally available IP and port information for the target system. This points to services the system is running, attackable surface. Knowledge of vulnerabilities in those services can come through independent research, or from a vulnerability scanner.

OpenVAS and Nessus provide very similar results. Here are the Nessus results:

And the OpenVAS results:

The results are similar, but there are some differences. OpenVAS was apparently branched out from Nessus back when it was open source, so there are bound to be similarities. Nessus has the familiar plugins with easy to remember plugin numbers, OpenVAS has Network Vulnerability Tests (NVTs) listed by a complicated OID. The default report in OpenVAS lists findings by CVSS score and provides some context that Nessus doesn’t, for instance listing Lorien as running on an outdated OS. Simple finding that is readily apparent by the Nessus results, but the distinctions are important. It is worth running both tools to see what, if any, differences come up. Nessus Home edition is not nearly as intuitive and easy to use as the Enterprise edition, learning to use the API may help with that.

Now we’re at the point with the lab where we have identified services and vulnerabilities. Moving forward. I have a list of projects now. I plan on doing the next chapter, which I am fairly excited about for it’s focus on ARP/DNS poisoning. I am also interested in recreating the Poisontap device. It does not look like I will make my December 1st deadline for wrapping this book up but I think there is value in trying to take the lessons a bit further and learn something.

So after setting up the NAS yesterday my goal for today was to get back into python. As an update on that, my python is coming along, I finished Python Crash Course and most of the way through Automate the Boring Stuff with Python. I’ve been through the first 4 chapters of Penetration Testing, and have learned a lot of cool stuff.

This summer has been very productive for me, all things considered. But it is drawing to an end, sadly, and with school starting up this week I’ll have less time for my side projects. So I should have been pressing ahead with working the python projects from the books or working the pentesting chapters… but instead ADD won the day and I am finishing out building my lab.

I installed ESXi to run from a USB on my Dell Poweredge 1950. After upgrading it to now have 32 GB of RAM, more than enough for my purposes. Right now I’m just running the pentest lab, which should only consist of a few machines at any given time, but I have other projects in mind down the line that this will be useful for.

The installation was painless. Download the software, available for a free trial from VMWare, or get it licensed from another source. I am still with George Mason University, so we have a deal where we get licensed VMWare products for free. The download, at least in the case of mine, comes with two files. One is a .iso file that will be the server installation files. The other is the management client for Windows.

Burn the .iso file to  disc, it could also be burned to a USB if you aren’t from the ancient past, but I went with the disc because I am a wasteful American, and because I wasn’t sure how the server would react loading the software from USB to USB similar to the NAS4Free install. Probably would work fine though. Insert the “destination” USB into the back of the server. Power the server on, insert the disc, navigate to the boot menu, and boot from disc. The installation to USB is quite easy, follow the prompts and when instructed remove the disc and reboot.

Upon reboot, bring up the BIOS menu and set the boot order. This will differ from server to server.  On my server, the rear USB interface is treated as a hard drive for boot order purposes, and the individual hard drives can be sorted for boot order, so I set the USB drive as the main “hard drive” for boot and set the boot priority for hard drive to 1. This will differ from server to server.

Once the server comes up, navigate in a web browser to the listed IP (assuming you have DHCP configured and the server was automagically assigned an IP, if not….). If the webpage for ESXi displays, then you’ve won. You can download the vSphere client from the link of the webpage or use the file from the initial software download. Install this software on your Windows client, following the default prompts. Once installed, start the software and navigate to the server’s IP. Authenticate using the username root and the password you set up during installation.

Open the NAS management console, in this case I used NAS4Free of course. Navigate to the Services>NFS menu. First head to the Shares tab and input the name of the share and the network to which the share should be accessible. Then select Save and Apply Changes. Remember that every time you do anything with NAS4Free, you have to select Apply Changes.

Once complete navigate back to the Settings tab. Ensure that Enable is selected. I chose to enable NFSv4, I don’t know what the difference is really beyond what was immediately available on Wikipedia, so that’s a problem for future me. But it seems like the smart move. Select Save and Restart to bring the share up. You have to repeat this step and the previous one for each disk to be shared.

Back in vSphere, navigate to the Inventory tab. You should see a prompt to create a data store, if not go to the Configuration tab. Select Add Storage and then select NFS Store and then Next.

On the next window, input the IP of the NAS server and the path, not the name, of the share you are adding. Give it a unique name and hit next.

Repeat this process for each disk you have to mount on the NAS. Once completed, you should see each disk attached to VMWare within vSphere.

Since I had already created several VMs on my laptop, in order to get them onto the datastore I will have to export them from VMWare Workstation and then import into vSphere. In order to export the VMs, in VMWare Workstation select the VM to be exported and then go to File>Export to OVF. In vSphere, g to File>Deploy OVF Template and select the template in order to import the VM into vSphere.

Once imported, navigate to the system in vSphere and console in to change the IP and hostname, if necessary. Pretty easy stuff, minimal surprises or roadblocks. This is basically an enterprise deployment of VMWare, minus the STIGing and other concerns. Which will come in a future update I am sure!

First off, errata from the last post. Working through the Weidman book, the copy of Windows XP SP 3 I listed doesn’t work for the exploits listed in the book and the security updates applied can’t be uninstalled. Windows XP SP2 does work, however I have yet to find a good, clean source for this.

Time to move on and set up the home NAS that will support my VMWare infrastructure. I decided on NAS4Free, since FreeNAS no longer supports x86 systems and my intent is to repurpose an old 32 bit system to support this. This isn’t necessarily the “right” or “best” way to do this, but it is what it is. And it works, very well. We’re doing an embedded USB install here, for ease of use and (hopefully, we’ll see) updating.

Use Win32 Disk Imager, located here to place the NAS4FREE image onto a USB. The image depends on the type of system, I’m using an old 32 bit system so I picked the 32 bit image for version 10.3.0.3. Pick the appropriate image from here and download that. Using the tool to load the image is pretty painless.

Once that is complete, set the system to boot from USB in the BIOS setting and reboot, with your USB attached. Connect a second USB stick to the system. Once the system completes booting, select the first option in order to create an embedded USB install. The system will then prompt you to select a “source” disk, you should pick the USB with the image loaded onto it. The system will then prompt you for a “destination” disk, select the second USB drive. The install will then complete and the server will become available on 192.168.1.250 on your local network. This can be changed from the console if needed.

From a desktop, navigate in a web browser to http://192.168.1.250 and login using the username admin and the password nas4free. Once logged in you can change these values in the System>General menu. Navigate to the Disks>Management menu.

In order to manage the disk, they must first be imported. This walkthrough assumes the disks have no data on them. Select Import Disks under the HDD Management tab. Once completed, switch to the HDD Format tab. It defaults to ZFS Storage Pool, but since ZFS is incompatible with Windows I switched this to UFS. Select UFS, select all disks, and select Next to continue to the next menu. The Minimum Free Space setting defaults to 8%, leave that at the default and input a volume name. Select Next again and begin the formatting process. Once that is complete, it is time to mount the drives.

There is an option to create a RAID, after some deliberation I decided against it. RAIDs are really useful for fault tolerance, which isn’t a requirement in my home lab. If you aren’t running real-time backups suited for a home network (ie crashplan, carbonite, custom solution, etc) then this may be a consideration.

Navigate to the Services>CIFS/SMB menu. Select the Shares tab and create shares for each disk, using a custom name for each. Once complete, navigate back to the Settings tab and ensure that Enable is selected under CIFS (it is on the right side). Once this is complete, save and restart. The shares will not be accessible until you select Save and Restart.

Once this is complete, map the drives under Windows and they should be accessible. Map them as the name, so \\192.168.1.250\mount_1 from my example picture would map the first disk. Step 1 was setting up the VMs. Step 2: Make a NAS is complete. Now to get the ESXi server up…

As I mentioned previously, I am going to start  working through Georgia Weidman’s book, Penetration Testing, as a sort of primer on penetration testing. The first step in the process is to build a lab. Once my school account opens up and I can access all of that sweet free VMWare software I will be building out an ESXi server with FreeNAS storage and migrating all of this to that server, but for now I am using VMWare Workstation and running these on the Toshiba laptop mentioned in my last post. It works, even if I am anxious to build out the real home system I want.

All of these instructions are assuming VMWare Workstation 12 and x64 Kali environment. This took me about two weeks to do  and then go back and redo for documentation, working on it an hour or two per day. A motivated person could do it in a day I am sure. I spent a lot of time experimenting and trying to get different things to work, such as a Windows 7 x64 build working with SQL Express.

Kali can be downloaded as a pre-built VM from https://www.offensive-security.com/kali-linux-vmware-virtualbox-image-download/ and imported into VMWare Workstation. This is a very simple process. Before powering the VM on, go into the CPU settings and change the processor to Intel VT-x/EPT or AMD-V/RVI, which will be necessary in order to run Android emulators:

Once in, change the password for the root account and create a user.

useradd -m xxxxx
usermod -a -G sudo xxxxx

Next, perform a system update using:

apt-get install update
apt-get install upgrade

Installing Nessus is a very easy process. Navigate to https://www.tenable.com/products/nessus-home and register for the code. The code will be emailed to you, and you can download the software. Once the .deb file is downloaded you install it using dpkg-i and follow the configuration instructions.

This is where the modern versions of software and Kali start to diverge from the book. The mingw-64 compiler is already loaded into Kali and should have been updated in the previous step. Download Hyperion 1.2 from the following link: http://nullsecurity.net/tools/binary.html. Unzip it and use the following command to compile it:

i686-w64-mingw32-c++ Hyperion-1.2/Src/Crypter/*.cpp -o hyperion.exe

Veil Evasion set up is by the book and simple, but it will take quite a bit of time. Once that is complete, make the Ettercap config changes detailed in the book. Then it is time to move on to the Android SDK. First to make some changes required by the SDK to run the phone emulators properly. Run the following command to add libraries required by the SDK:

sudo apt-get install lib32z1 lib32ncurses5 lib32stdc++6

Then two environment variables must be set. The first tells the SDK to use Kali’s libraries, installed in the previous step. The second tells the SDK what the SDK root directory is. Add the following two lines to /etc/environment:

ANDROID_EMULATOR_USE_SYSTEM_LIBS=1
ANDROID_SDK_ROOT=/root/Android/Sdk

Once those have been added, add a script to the /etc/profile.d directory that exports the two environment variables:

export ANDROID_EMULATOR_USE_SYSTEM_LIBS=1
export ANDROID_SDK_ROOT=/root/Android/Sdk

Download the Android SDK for Linux at : https://developer.android.com/studio/index.html. Unzip it and then navigate to the bin directory within the unzipped files and run the studio.sh script. That should start the Android Studio software. Prior to creating the emulated smartphones, download the associated packages with each smartphone image. You find those by opening the SDK Manager within Android Studio and selecting the “Show All Packages” button. Once selected, you can view supporting packages for the images. Select the packages for download that support the Android versions mentioned in the book.

Once these downloads are complete, navigate to the AVD Manager utility with Android Studio and create a new smartphone image for each image listed in the book, being sure to select the correct version of Android.

There is an issue in my version of Android Studio in which ARM emulated smartphones must have their config files manually pointed to the correct image. The config files are located in a default installation at /root/.android/avd and there should be a separate directory for each smartphone created in the SDK Manager. Within each directory, navigate to the config.ini file and note the image.sysdir.l path. The smartphones will be listed by API version, below is the config.ini entry for API 8:

This points to an unknown directory in the default installation. To correct this, change the image.sysdir.l path to point to the relative path of the installed image for the smartphone. For the newer API 7 and 8 versions, this is located in the platform directory, at $INSTALL_DIR/platforms/android-X/images, as seen below:

The image for the API 18 emulator is located in $INSTALL_DIR/system-images/android-18/default/armeabi-v7a after installation, as seen below:

You should now be able to run the emulators from the SDK Manager window. When running ARM emulators in an x86 framework, expect to receive the following warning:

Building a Windows XP machine can be tricky. I tried to build one from disc but had issues with the VMWare SCSI driver. The driver is available Here: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005208.  I tried pre-loading the driver but was unable to get this to work and in the interest of saving time I went another route. Test VMs for Windows XP are still available from Microsoft, although they do not publish the link. The link is located here: http://www.askvg.com/download-free-windows-xp-vista-and-windows-7-vhd-image-files-for-microsoft-virtual-pc/. After extracting the .vhd file, follow the steps at http://alstechtips.blogspot.com/2013/11/how-to-migrate-vhd-to-vmware-workstation.html in order to import the .vhd file for use. After successful import, log into the server and install the network drivers located at https://downloadcenter.intel.com/download/18717.

For software associated with the book, download Firefox first. IE 8 will be unsupported on the websites needed to download the software detailed in the book. The software associated with Windows XP installs according to the book description with the exception of mona, which is now located at https://github.com/corelan/mona/ instead of the link given in the book.

The Ubuntu VM can be downloaded via the torrent link given in the book. The book provides the password for unpacking the files, and importing the VM did not have any issues.

Building a Windows 7 VM is significantly easier than the Windows XP VM was. There are no driver issues with the stock Windows 7 SP1 x86 build, so you can install from disc or you can use this link to find a Windows 7 test VM and follow the directions to import it to VMWare. Once installed, again download Firefox to access the software needed to follow along with the book, since IE 8 will not be able to. Note that if you try and use a Windows 7 SP1 x64 build, the version of SQLExpress in the torrent package will not install correctly. There is an x64 version available from Microsoft, but I did not have much luck getting SP3 to install correctly even with the x64 package. Rather than spend more time trying to get this to work under an x64 platform, I moved forward with an x86 platform and it worked without a hitch.

References:

• https://www.nostarch.com/pentesting
• https://www.cybrary.it/forums/topic/how-to-make-hyperion-exe-work-in-kali/
• http://stackoverflow.com/questions/28864785/cannot-run-emulator-in-android-studio
• http://alstechtips.blogspot.com/2013/11/how-to-migrate-vhd-to-vmware-workstation.html
• http://www.askvg.com/download-free-windows-xp-vista-and-windows-7-vhd-image-files-for-microsoft-virtual-pc/
• http://stackoverflow.com/questions/28864785/cannot-run-emulator-in-android-studio
• http://gianlucacosta.info/android-studio-ubuntu
• https://downloadcenter.intel.com/download/18717
• http://www.intel.com/content/www/us/en/support/network-and-i-o/ethernet-products/000005504.html

So, having solved all other problems, I want to learn more about the offensive side of security. The best way to do that, that I can see, is to really get a good lab going and work through some material. So here’s my new goal: a year from now I want to take the OSCP. I’m giving myself a year because there’s no ticking clock, and I want to be thorough and learn the material and this gives me time to learn on my own and to get involved in at least 2, possibly 3 CTFs between now and then with Bsides DC, Baltimore, and Shmoocon all coming up.

Step 1: identify material. There’s some official OSCP materials available at the usual places. But that’s no good, you want to pay for that. And besides, you want to be able to interact with the instructor and other students. And yet now is not a good time to take the official material due to a new school semester starting soon (incident handling and “big data” classes, should be fun). Georgia Weidman’s book on pentesting, cunningly titled Penetration Testing, gets great reviews from people in the industry and after going through the first couple of chapters it seems on point. So, I’m going with this to start. Also going to work my way through Black Hat Python by Justin Seitz finally, improve and focus my coding skills. So I’m going to use this blog to track progress through this material and figure out where to go next.

Step 2: make a lab. I am cheap, and am determined to make a lab as cheap as possible while still having as much potential as I need. I made it through nearly two years of college in an IT program using only an Acer C-720 Chromebook that I picked up for $150 bucks back in the day. I am confident I can make this work. So I am taking two approaches. First, is my laptop that I replaced that chromebook with, a Toshiba Satellite C-55 that I picked up last fall for about $400. That laptop plus a quick memory upgrade to 16 GB has been pretty formidable. More than enough to run a few low budget VMs, and probably to run through some basic offensive lessons.

But, of course, I want more. So a year or so ago I picked up a 1U Dell 1900 Poweredge server from eBay. It’s an older server, definitely not up to modern standards. But it also cost $90. It came with 16 GB RAM, but I was able to get that up to 32 GB with a total cost of about $24. The goal with this is to wait until GMU activates my Dreamspark account again this fall, download the free ESXi software available from there, and configure and run multiple VMs from there and run through scenarios remotely when possible.

So that leaves me with the following:

• 2.2 GHz Intel Core i5 laptop with 16 GB RAM
• Dual 2 GHz Intel Xeon server with 32 GB RAM
• still rockin the chromebook

Total cost of all of this comes out to about $650, but considering the only thing I actually purchased for this initiative was the memory for the server I had sitting in a closet, I think so far so good.

I’ve set up the initial Kali VM from the Weidman pentesting book on the laptop, but since the book is a bit older there are some things that don’t quite fit with the new version of Kali and probably just the passage of time. I’ll get through them as I come to any problems.

So far that’s the only thing I have had time to do though because in the past month life has interfered. I gave my first talk at NovaHackers, it wasn’t great because I was nervous and stepped on what I had planned to say, but whatever. It was nice to meet people and see the great talks. Tomorrow is another meeting. I’ve learned Python, using Python Crash Course by Eric Matthes, which is a good teaching tool. I’m transitioning to a new job over the course of the next few weeks. I’m even thinking up new blog ideas and possibly even talks. I want to do one possibly on Nessus API, that could be something that is useful. We will see. Passed the CEH, I hate to say things are easy but really, it is, how they charge that much money for it I have no idea. Still hoping to do this blog ever week, even if I did fall behind for a month.