Category: artifacts

Do researchers handle exFAT volumes correctly?

~ msuhanov ~ 1 Comment

Let’s conduct a simple experiment. In the Ext4 file system, I create two files (“1.txt” and “2.txt”).

touch 1.txt 2.txt

Then, I gather file system metadata (including timestamps) for these files:

sudo debugfs -R 'stat /path_to/the_file/1.txt' /dev/block_device
sudo debugfs -R 'stat /path_to/the_file/2.txt' /dev/block_device

In my case, the output is:

For “1.txt”:

Inode: 23918802   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 2882061095    Version: 0x00000000:00000001
User:  1000   Group:  1000   Project:     0   Size: 0
File ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
 atime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
 mtime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
crtime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
Size of extra inode fields: 32
Inode checksum: 0x9906b43e
EXTENTS:

For “2.txt”:

Inode: 23921678   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 2369567438    Version: 0x00000000:00000001
User:  1000   Group:  1000   Project:     0   Size: 0
File ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
 atime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
 mtime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
crtime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
Size of extra inode fields: 32
Inode checksum: 0x9b052019
EXTENTS:

Now, I’m going to store something in these files. I will use the bash shell to append some text to the first file (using the output redirection syntax) and the gedit text editor to modify the second one.

echo 123 >> 1.txt
gedit 2.txt # In the gedit window, I will type "456" and hit Ctrl-S.

And let’s get the timestamps for these files again…

For “1.txt”:

Inode: 23918802   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 2882061095    Version: 0x00000000:00000001
User:  1000   Group:  1000   Project:     0   Size: 4
File ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x6399eed2:68debfb8 -- Wed Dec 14 18:42:10 2022
 atime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
 mtime: 0x6399eed2:68debfb8 -- Wed Dec 14 18:42:10 2022
crtime: 0x6399ee07:e1dbba28 -- Wed Dec 14 18:38:47 2022
Size of extra inode fields: 32
Inode checksum: 0x4a517d18
EXTENTS:
(0):95716043

For “2.txt”:

Inode: 23860507   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 534549923    Version: 0x00000000:00000001
User:  1000   Group:  1000   Project:     0   Size: 4
File ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x6399eed8:16d4b85c -- Wed Dec 14 18:42:16 2022
 atime: 0x6399eed8:14ec7284 -- Wed Dec 14 18:42:16 2022
 mtime: 0x6399eed8:16d4b85c -- Wed Dec 14 18:42:16 2022
crtime: 0x6399eed8:14ec7284 -- Wed Dec 14 18:42:16 2022
Size of extra inode fields: 32
Inode checksum: 0x2b67e3c3
EXTENTS:
(0):96358507

Do you see anything unusual?

Continue reading “Do researchers handle exFAT volumes correctly?” →

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

macOS & FAT directories

~ msuhanov ~ 1 Comment

Previously, I wrote about things you probably didn’t know about FAT. Now, let’s continue the story!

In FAT12/16/32 file systems, each directory (except the root directory) contains two special entries:

  • dot (“.”);
  • dot-dot (“..”).

The first one (dot) refers to the directory itself, while the second one (dot-dot) refers to the parent directory. Apparently, these entries were introduced to keep file system implementations simple, so there is no need to generate those entries on the fly (this is what happens to file systems not wasting their space to store dot and dot-dot entries in every directory).

Since two special entries are regular 8.3 directory entries, they contain timestamps (Created, Modified, Last Accessed). According to Microsoft, these timestamps should be set like this:

[…] and all of the date and time fields in both of these entries are set to the same values as they were in the directory entry for the directory that you just created.

FATGEN, 1.03 (DOC)

So, the timestamps in the dot-dot directory entry have no connection to the parent directory of that directory (they aren’t copied from the corresponding timestamp fields of the parent directory). Both special entries have their timestamps set to the same values as in the directory itself.

For example, all these entries are expected to share the same timestamps:

  • E:\test
  • E:\test\.
  • E:\test\..

But are these timestamps always synchronized?

Continue reading “macOS & FAT directories” →

Shadow copies become less visible

~ msuhanov ~ 6 Comments

<offtopic>You may find this article interesting: Measured Boot and Malware Signatures: exploring two vulnerabilities found in the Windows loader. It’s about two registry-related vulnerabilities found in the Windows loader.</offtopic>

Many examiners use tools like Arsenal Image Mounter to access shadow copies on disk images. I don’t recommend this method, because you won’t see offline shadow copies, but many of us still rely on it.

And it seems there will be more caveats…

Continue reading “Shadow copies become less visible” →

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

The NT kernel can ignore your hardware clock during the boot

~ msuhanov ~ 1 Comment

This started as an attempt to solve a puzzle:

Some virtualization software allows a user to launch a virtual machine with its real-time clock starting ticking from custom base time. For example, a user can launch a virtual machine with base time set to 2020-12-31 23:59:59 UTC, the real-time clock inside this virtual machine will start ticking from that value, regardless of the current date and time set on a host. I use this feature to test artifacts without telling Windows to move the clock.

However, if you decide to go back and restart the same virtual machine without defining custom base time (also without Internet access and without changing the date and time settings in the running operating system), the guest operating system won’t necessary use the current date and time (as set on a host). In some cases, it will continue to run using the previously defined (future) date.

How is that possible?

Continue reading “The NT kernel can ignore your hardware clock during the boot” →

Containerized registry hives in Windows

~ msuhanov ~ Leave a comment

If you read my Windows registry file format specification, you might already know about layered keys. Today, let’s talk about them in more detail.

Some editions of Windows 10 are capable of running Windows containers using Docker. Each Docker container is based on an immutable image with all modified data stored in an overlay. When a Windows container is used, the system has to record modifications affecting both the file system and the registry.

In 2016, Microsoft implemented new functionality called layered keys to allow programs access a merged view of keys and values from two or more registry hives! Now, this functionality is utilized by Docker…

Continue reading “Containerized registry hives in Windows” →

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