Category: dfir_ntfs

exFAT: orphan file name entries

~ msuhanov ~ 2 Comments

The exFAT file system was designed with Unicode file names and optional vendor-specific extensions in mind. To keep things simple, the file system specification allows the usage of multiple directory entries to describe a single file (so, additional file metadata is described in additional directory entries). This solution is similar to the VFAT extension for the FAT12/16/32 file systems, which was designed as a hack to the original file system format (originally, only one directory entry was used to describe a single file, so long file names were implemented as additional directory entries, which are “invisible” to operating systems without the VFAT support).

In the exFAT file system, a typical file consists of these entries (in this order, with no other entries between):

  • one file entry,
  • one stream extension entry,
  • one or more file name entries (as needed to store the file name),
  • zero, one or more vendor-specific entries (which can be ignored if not supported).

The first two entries describe all file metadata (its attributes, timestamps, data size, first cluster, etc.), while the file name entries contain strings to form the file name (each file name entry stores no more than 15 Unicode characters and the file name is no longer than 255 characters). Together, these entries are called a directory entry set (and it must contain at least three entries).

When a file is deleted, its directory entry set is marked as free. This process is very similar to what happens to a deleted file in the FAT12/16/32 file systems: the first byte of a directory entry is changed to mark it as free.

And, of course, it is possible to recover a deleted file when its directory set and data clusters are not overwritten. If the directory entry set is partially overwritten (with new directory entries), the following can be observed:

Continue reading “exFAT: orphan file name entries” →

$STANDARD_INFORMATION vs. $FILE_NAME

~ msuhanov ~ 2 Comments

There are two common misconceptions about NTFS:

  1. A typical file has 8 timestamps.
  2. Windows Explorer displays $STANDARD_INFORMATION timestamps.

A file with a single name has 12 timestamps: 4 timestamps come from the $STANDARD_INFORMATION attribute in a file record, 4 timestamps come from the $FILE_NAME attribute in the same file record, and 4 timestamps come from the $FILE_NAME attribute in an index record ($I30) of a parent directory.

If there is a short file name together with a long one, the number of timestamps is 20 (8 more timestamps come from two additional $FILE_NAME attributes in a file record and in an index record of a parent directory respectively).

You can also add an UUIDv1 timestamp from the $OBJECT_ID attribute, timestamps recorded in the USN journal and in the $LogFile journal. But these aren’t always present.

Things are more complicated with timestamps displayed by Windows Explorer.

Continue reading “$STANDARD_INFORMATION vs. $FILE_NAME” →

Offline shadow copies

~ msuhanov ~ 1 Comment

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” →

Extracting unallocated clusters from a shadow copy

~ msuhanov ~ 2 Comments

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” →

Scoped shadow copies

~ msuhanov ~ 4 Comments

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” →