Things you probably didn’t know about shadow copies

1. Shadow copies can contain invalid data

During the development of the parser for shadow copies, I observed many systems containing invalid data in shadow copies. For unknown reasons, some allocated files may contain null blocks instead of valid data blocks as well as blocks of data which should not be there.

For example, one system had a shadow copy with an EVTX file containing a null block instead of a valid ElfChnk record. And another system had some binary data with several recognizable ASCII URLs in a JPEG file (the image was damaged and could not be viewed; however, there was a valid image file at the same location in the main volume, this file didn’t have those ASCII URLs); the same system also had an NTFS-compressed file with invalid data (only the beginning of the first compression unit can be decompressed, remaining data is invalid).

In all cases, I verified that invalid data was reported by both the parser and the volsnap driver (there was no discrepancy between data returned by them, so the parser wasn’t bad, the shadow copies were bad).

So, there is something that corrupts “shadow data” in rare cases.

2. Windows can report “shadow data” that never existed on the drive

No magic. The volsnap driver has a longstanding bug which results in the following behavior: when some (not all) unused blocks are read, the output buffer for such a read request is left intact (its bytes are not modified). If the output buffer was filled with remnant data before the read request, this data isn’t overwritten with anything; the remnant data is then reported to an application as file data.

This behavior was observed with deleted files and with some allocated files (which are not a part of a shadow copy).

Be careful!

3. Shadow copies can be hidden

Let’s create two shadow copies for a system drive and then delete the latest one. Now, the vssadmin tool reports one shadow copy. However, two shadow copies actually exist (and an attempt to read the second one will fail, see the screenshot).

Let’s reboot and create another shadow copy. Now, the vssadmin tool reports two shadow copies. But, in fact, there are three shadow copies!

Another shadow copy can be created and results will be similar.

The explanation is the following.

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.