Bit9 + Carbon Black Threat Research Team Unveils Nefarious Intents of “Volume Shadows Copies”

Bit9 Carbon Black Threat Research Team Unveils Nefarious Intents of Volume Shadows Copies
Hex_Thirds
August 5, 2015 / Russell Nolen

Some variants of the CryptoLocker ransomware family are known for deleting all volume shadow copies to prevent restoring from backup. The ransomware does this by executing the “Vssadmin delete shadows /all” command. In this post we will focus on how volume shadow copies are being used for much more.

We have seen the volume shadow service used for a number of things ranging from malware to penetration testing tools. Below are a couple of links for some reading on using shadows in penetration testing:

  1. Volume Shadow Copies – The Lost Post
  2. Using Volume Shadow Copies from Python
  3. Volume Shadow Copy NTDS.dit Domain Hashes Remotely – Part 1
  4. Tim Tomes and Mark Baggett Lurking in the Shadows
  5. REM Volume Shadow Copy Management from CLI

Using Microsoft against itself with Volume Shadow

The Bit9 + Carbon Black Threat Research team has observed various techniques utilizing volume shadows. In this post we are going to focus on utilizing it for avoiding detection and anti-analysis. We have discovered an interesting technique in which attackers will: drop their malware on the file system; create a volume shadow; “mount” the shadow; start the malware; unmount; and, at times, even delete the shadow. The most interesting piece of this is that even after the unmounting and deleting, the executed malware will still run.

__________________________________

Also See: New “Crypto” Ransomware Lurks in the Shadows

__________________________________

Creating Shadows

On Windows 7 and Windows 8.1, the Vssadmin tool doesn’t have the ability to create shadows on the system. Starting with the Windows Vista SDK, Microsoft supplied a binary called Vshadow. Microsoft says the following about the Vshadow tool: “Vshadow is a command-line tool that you can use to create and manage volume shadow copies.”

The attackers now have a Microsoft signed binary that allows them to create shadows. They simply have to get the binary to the victim machine.

Once the Vshadow executable is on the victim, attackers use it to create a persistent shadow. (Persistent in this case means to survive between reboots.) To create a persistent shadow attackers utilize the “-p” option and point it toward the location on the file system they want to create a shadow of:

nolen1

In the above example, the attackers are creating a persistent shadow of the full C: drive. This will run for a few seconds and end with the following output:

nolen2

Keep note of the “Shadow copy device name.”

(\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3) as it will be used to mount the shadow.

Mounting of the Shadow

Now that the shadow with the malware has been created, it must be mounted. This is done using the “mklink” command:

nolen3

The /D argument is used to create a directory symbolic link (instead of a file symbolic link). When using the /D option with shadow copies, the trailing “\” at the end of the shadow name is used. The attackers are creating a symbolic link directory in C:\Windows\System32 to a directory called “msdc.” The symlink directory points to the shadow copy of the C drive created earlier. The malware was placed at the root of the C: drive when the shadow was created. A directory listing of C:\Windows\System32\msdc reveals the malware as seen below:

nolen4

Once the symlink has been created the contents of the shadow are now accessible via normal file system operations.

Starting the Malware

Once the file system setup is in place, the malware is started just like any other executable. When the malware is started and shown in a tool like process explorer it shows that it is running from C:\Windows\System32\msdc

nolen5

Unmounting and Deleting the Shadow

One of the most interesting things about this technique is that once the malware is started, the attackers can unmount and delete the shadow and the malware will still run. To unmount the shadow the attacker removes the directory with something such as the “rmdir” command. From here, the attacker needs to remove as much forensic evidence as possible and delete the shadow as well. The Vssadmin tool is used to delete individual shadows or all of them:

nolen6

The malware is still running in the background even after the unmounting and deletion.

As demonstrated in this short write up, this technique is a nice hiding mechanism that throws in a little anti-forensics with it.

Finding Vshadow Being Used

I tried to stick to indicators that could be used in various tools, but I will show exactly how to find them with Carbon Black.

Our first method for finding use of the Vshadow tool could be by looking for hashes. Each version of the SDK will have the Vshadow tool in it and will have an x86 and 64bit version. I have pulled down most of the SDK’s and extracted the hashes as seen below:

MD5 (vshadow-7-32.exe) = 3e1360a23ea5f9caf4987ccf35f2fcaf

MD5 (vshadow-7-64.exe) = 576b379a59d094fb7b06c261a96034a6

MD5 (vshadow-8-32.exe) = d0cd7ad91b2ff568275d497214ff185c

MD5 (vshadow-8-64.exe) = 97fd0f3c05f1707544a9a6a0c896b43e

MD5 (vshadow-8.1-32.exe) = d560c155b68121d98f8370e7deafbc4d

MD5 (vshadow-8.1-64.exe) = c5d2992c8cba0771f71fe4d7625a0b8b

MD5 (vshadow-vista-64.exe) = 53d3e33ad31af6716559f29e889aca49

In Carbon Black our query would be:

process_md5:3e1360a23ea5f9caf4987ccf35f2fcaf OR process_md5:576b379a59d094fb7b06c261a96034a6 OR process_md5:d0cd7ad91b2ff568275d497214ff185c OR process_md5:97fd0f3c05f1707544a9a6a0c896b43e OR process_md5:d560c155b68121d98f8370e7deafbc4d OR process_md5:c5d2992c8cba0771f71fe4d7625a0b8b OR process_md5:53d3e33ad31af6716559f29e889aca49

We could also look for the vshadow.exe file being executed by name and some command line options.

The query for that would look something like this:

process_name:vshadow.exe AND cmdline:”-p C:\”

This query returns positive results from Carbon Black, but an attacker can rename the executable to something like msdc.exe and this would get around this detection. If we look a little closer at the vshadow.exe process we can see it loads a few modules that don’t normally get loaded.

nolen7

One in particular that we are looking for is vss_ps.dll, which is a necessary component of the Volume Shadow Storage feature. Let’s change our query to do detection on loading of the dll.

modload:vss_ps.dll cmdline:”-p C:\”

If you are worried that an attacker would possibly make a shadow of something other than the root of the C drive, you can shorten the query to:

modload:vss_ps.dll cmdline:”-p”

In a 3,000-host environment, that query came back with only one process that matches the criteria. The process is the Windows process werfault.exe. So we can refine it to:

modload:vss_ps.dll cmdline:”-p” -path:System32\werfault.exe

Unfortunately since the command “mklink” is a function of cmd.exe (internal command) it is going to be hard for anything to log that unless there is a shell out such as “cmd.exe /C mklink /D…….”

In Carbon Black, the query for catching that would be:

cmdline:””C:\Windows\system32\cmd.exe” /c mklink /D”

Depending on your environment, this might flag false positives and should be used with some caution.

Let’s take a look at the process “malware.exe”. Using “Sysinternals Process Explorer,” we saw that the process looks like it is being executed from C:\Windows\System32\msdc.

nolen8

One feature of Carbon Black is that it sees the malware.exe process execution path. When taking a closer look at the malware.exe process in Carbon Black we can see that it logs the true file system path \Device\harddiskvolumeshadowcopy3\malware.exe.

nolen9

We can come up with a few searches that look for executables loading from the “\device” location. Looking for specific binaries being run from volume shadows would be the query:

path:device/harddiskvolumeshadowcopy*

If we wanted to look for processes being executed from any device (e.g., USB) the query would be:

path:device/harddiskvolume* (This will flag our malware being executed from the volume shadow, along with other processes being run from locations that have “device/harddiskvolume” in the path. Depending upon your environment this might cause false positives)

In summary, for detecting this attack we have the following queries:

Search by hashes:

process_md5:3e1360a23ea5f9caf4987ccf35f2fcaf OR process_md5:576b379a59d094fb7b06c261a96034a6 OR process_md5:d0cd7ad91b2ff568275d497214ff185c OR process_md5:97fd0f3c05f1707544a9a6a0c896b43e OR process_md5:d560c155b68121d98f8370e7deafbc4d OR process_md5:c5d2992c8cba0771f71fe4d7625a0b8b OR process_md5:53d3e33ad31af6716559f29e889aca49

Search for Vshadow being executed:

modload:vss_ps.dll cmdline:”-p C:\”

modload:vss_ps.dll cmdline:”-p” -path:System32\werfault.exe

Search for mklink being executed via a shell out:

cmdline:””C:\Windows\system32\cmd.exe” /c mklink /D”

Search for processes being executed from the volume shadow copy locations:

path:device/harddiskvolumeshadowcopy*

path:device/harddiskvolume*

 

TAGS: bit9 / Carbon Black / cryptolocker / ransomware / Russell Nolen / threat research / volume shadow copies

Related Posts