Offline shadow copies

This was already described here, but let’s revisit the topic.

Let’s install the Windows Server 2016 operating system on a machine, install all available updates, configure the machine as a domain controller and an RDP server, create several domain user accounts. Then, create a shadow copy and delete it. After some time, create a new shadow copy and keep the machine running for a while, then create another shadow copy. How many shadow copies are there? Two (the oldest one was deleted, thus not counted).

Let’s simulate a remote attack against this domain controller. The attack involves dumping the ntds.dit file. In order to copy that file, I will use an approach outlined in this guide: create a shadow copy, copy the ntds.dit file from it, then delete this shadow copy to remove my tracks (all these actions are performed over an RDP connection, just like a real attack).

Finally, let the system run for some time and occasionally create two more shadow copies. How many shadow copies are there now?

Five, not four:

• two shadow copies created before the attack;
• one shadow copy created during the attack;
• two shadow copies created after the attack.

But the shadow copy created by an attacker has been deleted! Or not? Let’s take a look at the output of the “vssadmin list shadows /for=F:” command (in Windows 10; an EnCase image of the drive used in the test was mounted read-only using the Arsenal Image Mounter tool, version: 3.2.126), here is a screenshot:

Clearly, we have four shadow copies displayed. And here is the output of the vsc_mount tool:

Shadow copies are enabled
  Stack position: 1, timestamp (UTC): 2020-07-12 22:04:24.777386
  Stack position: 2, timestamp (UTC): 2020-07-12 23:06:03.223402
  Stack position: 3, timestamp (UTC): 2020-07-13 00:27:05.974676
  Stack position: 4, timestamp (UTC): 2020-07-13 08:51:27.956654
  Stack position: 5, timestamp (UTC): 2020-07-13 19:14:12.315986

Five shadow copies! And, when mounted, the third one contains a temporary directory which was used to store “exfiltrated” data (the directory was deleted before the fourth shadow copy has been created). And here is the explanation taken from my post linked above:

Every shadow copy contains “delta data” relative to the next shadow copy or, if this is the last shadow copy, relative to the volume. So, an old shadow copy depends on all subsequent shadow copies (otherwise, “delta data” would never end up in a consistent volume snapshot).

If a shadow copy is going to be deleted and there is a dependent shadow copy, then this (the one being deleted) shadow copy is just marked as offline (and, thus, hidden). But its data is still there.

Attackers use shadow copies to read locked files from hacked systems. Often, attackers delete shadow copies they created and used. But not all deleted shadow copies are really deleted.

Also, here is a related message found in the volsnap driver:

Some snapshots may be marked ‘visible’, meaning they were exposed as a local volume or file share. Some detected snapshots may be marked ‘deleted’, meaning they are no longer available for use and their diff area space will be reclaimed when all older snapshots are deleted.

It’s simple: if a shadow copy to be deleted isn’t the oldest one and not all shadow copies are going to be deleted during an operation, then this shadow copy is marked as offline. Also, such copies can’t be opened and read using the “HarddiskVolumeShadowCopy<N>” device.

So, if anyone wants to cover their tracks while dumping the ntds.dit file, use an existing shadow copy. Or delete all shadow copies after doing the job. Or use a custom tool to read the NTFS file system directly.

And blue teams should be aware of offline shadow copies. These shadow copies aren’t exposed by tools that rely on “HarddiskVolumeShadowCopy<N>” devices.