Penetration testing is not vulnerability scanning and should not be confused. Vulnerability scanning is one of the first parts of the penetration test process.
I recently received the go-ahead for an external penetration test which referred to the test as “a scan”. This is not the first time I have seen penetration testing and vulnerability scanning confused, and I suspect it will not be the last. To illustrate the very real differences, I offer the following, real world example:
During 2010, a colleague and I were involved in an internal penetration test. In accordance with considered industry best practice, once the scope was confirmed, we kicked off with our initial reconnaissance, port-scanning, enumeration of targets, and so on. We then fired up our favourite vulnerability scanner to look for any low-hanging fruit and left it running in the background while we proceeded to manually inspect some likely targets.
The network as a whole was largely based on Windows Server 2008 R2, although there were a couple of Windows Server 2003 R2 hosts knocking around. Password policies were configured with reasonable settings for password history, password complexity, password length, and password expiry, and none of the usual suspects like “admin:admin” or “backup:companyname”, appeared to be in evidence. The client was pretty hot on patching and anti-virus cover, with an average two week lead time between patches being released and deployed.
After a while, the vulnerability scanner completed its run, and, as expected, returned little of immediate interest, at least nothing it flagged as high risk. So now we were down to manual trawling through the results and hosts’ services looking for anything more subtle.
After a little while, we found a file share called exchange$, which allowed read permission to all authenticated users. Within this folder were a few tutorial documents relating to deployment of Exchange 2007, migration of data from 2003 and so on; nothing terribly exciting, or so we initially thought. Closer inspection revealed a hidden folder called “backups$”. This folder was considerably more interesting, containing several files including company-dc01_c_drive.vhd, last modified six months previously.
This file, for those unfamiliar with VHD files, was a full backup of the system drive of a Windows 2008 Active Directory Domain Controller in Microsoft’s custom “Virtual Hard Disk” format. With a bit of technical persuasion it was possible to mount and access this file, and then extract the password hashes from the Active Directory database. The vast majority of the password hashes for privileged accounts were in the recommended NTLMv2 format, and dictionary attacks were unsuccessful. However, one account had an associated LM hash, was a member of the “Domain Admins” group, and according to the user account properties, had a password which was not set to expire. The password, after an overnight brute force attack with some pre-prepared rainbow tables was discovered as 12 characters long, complex, and not a recognisable phrase. However, it was cracked, and valid, and consequently, full control of the entire Active Directory domain had been achieved.
No vulnerability scanner that I am aware of could have done this. At most, it would have identified a user account in the “Domain Admins” group, with a non-expiring password, and a network share called exchange$. Three low risk, possibly even medium risk issues, which would most likely slip off the radar as low priority. The penetration test, on the other hand, revealed these to be a critical combination of issues, which led to complete domain compromise.
So, in conclusion, penetration testing is not vulnerability scanning.