When triaging a live system or performing live forensic acquisition, we often need to copy registry hives from a disk. Currently, there are five common ways to do this:
- execute the “reg save <hive> <file>” command;
- call the RegSaveKeyEx/RegSaveKey routine from an acquisition tool;
- copy a hive file from an existing shadow copy;
- copy a hive file from a newly created shadow copy;
- directly read a hive file from an NTFS volume.
Are there any pros and cons of each way?
Continue reading “Exporting registry hives from a live system”
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?
Continue reading “Offline shadow copies”
Yes, shadow copies may contain a relatively small number of unallocated clusters. In this post, I will describe a new way to extract such clusters for further analysis.
The problem with unallocated clusters in shadow copies is that the volsnap driver doesn’t care about them. This driver can snapshot some unallocated ranges, but most of them are out-of-scope.
When reading unallocated clusters from a shadow copy, data from the current state of a volume can be returned. Obviously, this data has nothing to do with the shadow copy:
However unexpectedly when I ran the Encase Recover Folders feature across the HarddiskShadowcopy5 volume it found traces of the Sony folder and in fact many other files post dating the creation of the shadow copy.
The Encase Recover Folders feature parses unallocated clusters looking for folder metadata. It seems that it found data in unallocated clusters relating to the current volume. Therefore I believe that any deleted but recoverable data within the shadow copies needs to be treated with caution.
Null bytes instead of real data can be returned as well.
There is no way to distinguish between “real” and “fake” unallocated data when reading a shadow copy using the device exposed by the volsnap driver (“HarddiskVolumeShadowCopy<N>“).
Continue reading “Extracting unallocated clusters from a shadow copy”
Have you ever heard of scoped shadow copies? They have been around since the release of Windows 8, but not much information is available on this topic.
A shadow copy becomes scoped when data blocks not required by the system restore process are excluded from copy-on-write operations. When you create a restore point, a scoped shadow copy is created by default for a system volume (in Windows 8, 8.1 & 10).
Continue reading “Scoped 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.
Continue reading “Things you probably didn’t know about shadow copies”