[Source: blog.microsoft.com]

What is Vshadow?

Vshadow (vshadow.exe) is a command line utility for managing volume shadow copies.  This tool is included within the Windows SDK and is signed by Microsoft (more on this later).

Vshadow has a lot of functionality, including the ability to execute scripts and invoke commands in support of volume shadow snapshot management.  Not surprisingly, these capabilities can be abused for privileged-level evasion, persistence, and file extraction.

In this blog post, we will discuss Vshadow command execution, auto-start persistence, and sensitive file copy using Vshadow to extract the Active Directory (AD) database for offline hash dumping and password cracking.

Command Execution

Executing commands with Vshadow is dependent upon a ‘successful’ interaction with a shadow copy operation (e.g. creating a snapshot, removing a snapshot, doing something with a snapshot, etc.).  Vshadow.exe supports the -exec parameter, which can be used to execute a binary (.exe) or a script (.bat/.cmd).  The -exec parameter does not support command arguments, so payload execution needs to be wrapped up within the context of these limitations.

Before proceeding, let’s consider a few other requirements for command execution.  Firstly, we need to have privileges on the machine (e.g. administrator) as working with volume snapshots (and invoking the Volume Shadow Service) is deemed a sensitive operation.  Secondly, we need to get the Vshadow executable onto the target machine.  If the Windows SDK is already installed, then all we have to do is locate the path to the binary on disk.  Otherwise, we’ll have to transfer it over.  Lastly, we need to ensure that our payload is wrapped up as discussed previously.  For our command execution example, we will simply use notepad.exe as our payload.

Invoking a payload with vshadow.exe is not exactly the stealthiest method, but we can operate the tool in such a way to minimize our footprint.  The basic structure of our command is as follows:

vshadow.exe -nw -exec=<\path\to\exe> <system drive>

Specifying -nw allows us to create a shadow copy without invoking shadow copy writers.  Effectively, this is a non-persistent shadow copy, which will not leave “physical” disk evidence (*Please note that this does not necessarily prevent the detection of shadow copy creation as we are still going through the simulated process). Now, let’s run the following command:

vshadow.exe -nw -exec=c:\windows\system32\notepad.exe c:

The output is shown in the following screenshot:

Successful execution of Vshadow in this context will create a ‘faux’ shadow copy set, then launch the payload (notepad.exe) as specified by the -exec parameter.  A few interesting things are happening here that may be useful for defensive and forensics folks to know…

• Vshadow.exe will not finish executing until the child process is finished executing.
• The payload (notepad.exe) is a child process of vshadow.exe.

• Successful execution of Vshadow will kick off the Volume Shadow Service (VSS) as indicated by System Event ID 7036 and invocation of the VSSVC.exe process.

Auto-Start Persistence & Evasion

Since Vshadow is a signed binary and has command execution capability, we have a candidate for potentially evading AutoRuns (to a degree).  As an example, let’s add persistence (via a Registry Run Key) for our ‘evil’ payload by entering the following command:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v VSSBackup /t REG_EXPAND_SZ /d "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64\vshadow.exe -nw -exec=c:\windows\system32\notepad.exe c:"

In AutoRuns, we will not see our Logon Entry when filtering for “Microsoft Entries” as shown below:

However, if we de-select “Microsoft Entries” and enable “Windows Entries”, we will see a record for our persistence mechanism:

The reason for this visibility is due to the fact that vshadow.exe was not signed with the Windows certificate.  However, this Autoruns entry may still ‘blend in’ pretty well if vshadow.exe is dropped to a better file location on disk and has a convincing name.  Expanding on the entry may or may not foil a determined analyst:

Sensitive File Extraction – AD Database

Switching gears, let’s get back to the spirit of Vshadow and use it natively for ‘living off the land’ operations.  Since we can create snapshots with the VSS, let’s use this utility to extract the Active Directory Database (ntds.dit) on a Domain Controller (DC) and dump the hashes offline using secretsdump.py

Firstly, we copy over vshadow.exe to our DC (Windows 2K12 in this example) and create a persistent shadow copy (without writers) of the “c:” using the -p parameter as follows:

vshadow.exe -p -nw C:

Note the Shadow Copy Set ID (the UUID) and Volume Name within the following screenshot as these will be used in subsequent commands:

Secondly, we copy the the AD Database from the shadow copy using the Volume name as follows:

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\ntds\ntds.dit c:\ntds.dit.bak

The following output shows that the copy operation was successful:

Thirdly, we extract the SYSTEM hive from the Registry.  We will need this to dump the contents of the AD database:

reg.exe save hklm\system c:\system.bak

The following output shows that the registry operation was successful:

Next, let’s ensure that our files extracted as expected:

dir *.bak

Our two files are present as indicated by the following screenshot:

For good measure, let’s clean up and remove our shadow copy by specifying the shadow set ID:

vshadow -dx={46d3c3ee-2840-4152-ba5c-450ea401869a}

The operation was successful as indicated below:

Finally, let’s move our loot (ntds.dit.bak and system.bak) to dump the hashes offline with secretsdump.py.  The following command is used:

secretsdump.py -ntds ntds.dit.bak -system system.bak LOCAL

And success! We have used Vshadow as a facilitator to acquire the domain hashes!

Other Research

• For comprehensive information about autorun evasion techniques, check out the evading-autoruns presentation slides.  This fantastic presentation was given by the Huntress Labs folks at DerbyCon 7 (2017).
• @PyroTek3 maintains an excellent website at ADsecurity.org.  This post showcases many methods used by attackers to retrieve/dump the AD database, including the use of tools that leverage VSS (e.g. vssadmin, ntdsutil, etc).
• @keydet89 blogged about the use of vshadow in support of an interesting malware loading technique seen in the wild a few years ago.  Definitely check out his analysis as well the links that he provides for posts by Carbon Black and a presentation by Ryan Nolette at BSides Boston (2016) on the same subject.

Conclusion

In addition to monitoring for the indicators above, defenders may want to keep an eye out for odd Volume Shadow Service (VSS) behavior such as random creations/deletions and any activity that involves the AD database file (ntds.dit).  Also, monitor for command invocation of vshadow.exe switches.  File hashes and names may change, but “-nw -exec=” and “-p -nw” will likely persist.  As always, if you have questions or comments, feel free to reach out to me here or on Twitter.  Thank you for taking the time to read about Vshadow!

Next

Check out “Part 2” -> DiskShadow: The Return of VSS Evasion, Persistence, and Active Directory Database Extraction