Approximately 1 year ago today, Tim Tomes and I did a presentation on Volume Shadow Copies (VSC) at Hack3rCon II. Hack3rCon^3 just wrapped up, and I’ve officially been shamed into finally publishing the details of the research. Many of the faithful PDC readers will know most of these details, as some of them were included as pieces to posts on other topics, but I will try to provide a little something new.
Volume Shadow Copies
The Volume Shadow Copy Service (VSS) maintains copies of every 16k block that is changed on an NTFS disk. Then at certain times it packages up all those 16k blocks and puts them up into a Volume Shadow Copy (VSC). The times aren’t strictly predictable, but by default it will create a VSC automatically with the installation of new software and patches. Also, a VSC will be created every couple of days on Vista and every couple of weeks on Windows 7. On Windows 2008 Server you can use VSSADMIN to create a VSC. On Windows 7 VSSADMIN is not capable of creating VSCs from the command line, but VSCs can be created manually through the GUI or by using VSSOwn (more on this later). How much drive space is used by VSC varies by OS. By default, Windows 7 reserves 5% of hard drive for Volume Shadow copies and Vista reserves 15%. Therefore, how many volume shadow copies and how far back they go will depend upon the size of the drive and how quickly the data on the drive changes. Generally speaking, you can usually find a VSC that is 1 month old on Windows 7 and 3 months on Vista.
You can get a list of all the existing Volume Shadow Copies with the command “vssadmin list shadows”
The date in box 1 is the date on which the VSC was created. Box 2 contains the path to the VSC that we use to access the data in the VSC. To access the data in a VSC you can mount it to a directory or use the full path to the resource including the PATH from Box 2 above. Here are a couple of practical applications for VSCs in a penetration test.
Application 1 – Hiding Malware:
You can use a VSC to hide malware on a compromised system for persistence. Here is an attack scenario. The attacker gains access to the system. He then copies all his malware to the target, creates a VSC and deletes the malware from the main drive. The malware is completely invisible to the systems administrator. It has been deleted! He can even SHRED the file and over write the bits with random ones and zeros, but his malware still sits safely tucked away in the VSC where Antivirus software will not detect it. Even if you mount the VSC and antivirus software tries to delete the malware it can’t. The VSC is read only and it cannot be changed. Your only option is to delete the entire VSC. The Hack3rCon II talk focused on this use of VSS. You can see the video of that talk here:
http://lanmaster53.com/talks/#hack3rcon2
Application 2 – Accessing Locked files
You can also use VSCs to gain access to files that are locked by the OS on the main drive (SAM, SYSTEM, NTDS.DIT, etc). This means you can safely steal the hashes from a running domain controller without injecting into the LSASS process and potentially crashing the server. An article explaining this process can be found here:
http://secweekly2.wpengine.com/2011/11/02/safely-dumping-hashes-from-liv/
Application 3 – Finding Old data
Finally, you can find access to files that have been deleted from the main drive. So if the system administrator deleted “passwords.txt” from his desktop the day before the penetration test started, you can find it in the VSC. This is a bit like TimeMachine for OS X users. You can step back in time and grab backed up copies of files.
How to use them:
To use VSCs, there are a few things you must know. First, you can mount VSCs using the “mklink” command and creating a symbolic link to the VSC device object. The syntax for “mklink” is as follows:
Once you are in the “Link2VSC” directory, you can access all of the files that were on the drive on the date that the VSC was created.
You can also access the files in the VSC directly and copy them to the main drive with a simple copy command. For example:
copy \?GLOBALROOTDeviceHarddiskVolumeShadowCopy1pathtolockedfile c:destination
This copies files from a VSC to the main drive and file locks are no longer a hindrance. You can also execute code directly from a VSC using WMIC! When making a call to WMIC, you have to change the syntax a bit. Instead of “\?” you have to use the syntax “\.”. For example:
wmic process call create \.GLOBALROOTDeviceHarddiskVolumeShadowCopy1windowssystem32cmd.exe
There are some really nice things about VSCs. Specifically, they are read only, and Antivirus software doesn’t scan VSCs. When you mount a VSC to access malware, or use WMIC to execute malware, then AV real time detection will detect it. However, you can work around it. To access the VSC, you have to be an administrator. Therefore, if you are using VSCs, then you already have the rights required to temporarily disable the hosts AV and access the data stored in the VSC without detection. But wait! There’s more. You don’t actually have to disable the AV. Instead, you can use common configurations of Antivirus product to avoid detection. For example, many antivirus products do not scan mounted network volumes. It could be bad if all of your workstations scanned the file server at the same time when their daily schedule scan kicks off. Therefore, you can mount the VSC and then access it as a network volume.
mklink /D c:tempdrv \.GLOBALROOTDeviceHarddiskVolumeShadowCopy14
net share drv=c:tempdrv
net use f: \127.0.0.1drv
f:malwarebackdoor.exe
The Tool
While VSC manipulation is extremely useful, there is the aforementioned problem: no way to create a VSC from the command line in Windows 7. Sure, you can do it through the GUI, but who uses that thing? So as part of the research, I wrote a short script that creates a VSC from the command line and allows you to execute things from it. You plant your malware directory, create a snapshop, and then delete the directory from them main drive. To create a snapshot you do this:
cscript vssown.vbs /create
Then I gave my script to my good friend @Lanmaster53 who went feature crazy on it and added a bunch of cool stuff! You want Windows 7 to store more than 5% of the changes? You want it reserve 50% for volume shadow copies? You can change that. You want to disable the VSC service while you are not on the box? Got that. The user disabled that service so you need to start it? Got you covered. There is even a nice feature that will generate echo statements so you can copy and paste it into a remote netcat session and build the script on a remote host. The tool is called VSSOwn and can be found here:
http://ptscripts.googlecode.com/svn-history/r1/trunk/windows/vssown.vbs
We believe this only unlocks the potential for the usefulness of the VSS and VSCs. Let us know if you come up with any new uses and enjoy your new found capability!
Have fun.
Join me for SANS 504 Hacker Techniques, Exploits & Incident Handling November 27th – December 2nd 2012 in lovely San Antonio Texas.
Mark Baggett
On Twitter @markbaggett
