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”
You might already know that the NTFS “Last Access” updates will be back by default in Windows 10 “20H1”. Previously, there were back for installations with small system volumes only. What is the reason behind this? Why do we need last access timestamps?
If you visit the “Configure Storage Sense or run it now” page in the “Settings” window of Windows 10 “19H2”, you may notice the “Delete files in my Downloads folder if they have been there for over” option. The same option in “20H1” reads: “Delete files in my Downloads folder if they haven’t been opened for more than“.
So, this old new NTFS feature has something to do with Storage Sense. It’s a component used to delete unneeded files “to keep your storage optimized”. And the “Last Access” updates are a good way to detect such unneeded files (and the “StorageUsage.dll” library actually uses last access timestamps to find “cold” files).
But there is something you might not notice. Look at the same settings page in Windows 10 “19H2” and read:
Content will become online-only if not opened for more than"
Wait a minute! The “Last Access” updates are on for a relatively small subset of Windows 10 “19H2” installations only… Does this option really work for systems with large system volumes?
Continue reading “OneDrive and NTFS last access timestamps”
Have you ever encountered on-disk artifacts originating from another system?
Typically, this is something you see when a custom operating system image had been deployed to multiple computers by IT staff (on-disk artifacts appeared before the image is captured become a part of that image).
But there are some minor artifacts existing in installation images coming from Microsoft!
Continue reading “Prepopulated artifacts”
This is a reply to the Sunday Funday 4/5/20 challenge. The goal of this post is to document the process, not just the results. You have been warned.
The Background Activity Moderator (BAM) is a Windows 10 thing that does… something! Because we don’t know much about it.
We know that this thing provides evidence of execution by listing executables under the following registry key:
Each piece of evidence is stored as a registry value (REG_BINARY), its name is set to an executable path and its data is set to a binary structure with a FILETIME timestamp inside (this is believed to be the last execution timestamp).
Continue reading “BAM internals”
In the Linux world, a deleted file which is still open isn’t actually removed from a disk. Instead, it’s just unlinked from the directory structure. This is why a system call used to remove files is named “unlink”.
unlink() deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open, the file is deleted and the space it was using is made available for reuse.
If the name was the last link to a file but any processes still have the file open, the file will remain in existence until the last file descriptor referring to it is closed.
The same behavior can be observed in other Unix-like operating systems.
But in Windows 10, similar behavior can be seen too!
Continue reading “The “\$Extend\$Deleted” directory”
Many unexpected things happen under the hood when you do live forensics. Tools used to acquire data from running Windows systems often utilize direct access to logical drives to copy locked files and extract NTFS metadata. But did you know that NTFS metadata is updated when you read a logical drive directly?
Continue reading “You write to a logical drive when you read from it”
There are forensic tools capable of carving file records and index entries ($I30) from memory dumps, but there is much more NTFS-related metadata which isn’t exposed by usual memory forensics frameworks. For example, file control blocks.
Continue reading “Carving file control blocks from memory dumps”
Here is a list of open research topics in Windows forensics. All topics in this list are relevant to my research. Feel free to pick one for your research. Originally, I wrote this list for myself, but it’s better to make it public.
More topics and ideas (in other areas too) can be found here and here.
Continue reading “Windows forensics: open research topics”
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”