Category: NTFS

Playing with case-insensitive file names

~ msuhanov ~ 4 Comments

Although NTFS has been designed with case-sensitivity in mind, it’s used mostly in the case-insensitive environment. One can natively store, within the same directory, two or more files with their names differing only in case, but Windows-based tools won’t deal with them correctly. To provide true case-sensitivity, Microsoft implemented an additional layer, per-directory case-sensitivity, as described here, here, and here.

But there are several issues with usual, case-insensitive, operations…

Continue reading “Playing with case-insensitive file names” →

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

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

Storage Reserve blocks some tools from thoroughly wiping unallocated space

~ msuhanov ~ 2 Comments

Storage Reserve is a relatively new feature that keeps some disk space in a system volume available for downloading and installing Windows updates. Its implementation is simple – the current amount of free space visible to applications is decreased, so the “no space left” condition occurs before the space is really exhausted.

Take a look at these screenshots:

81-f
Windows 8.1

20h1-f
Windows 10

Both of them illustrate the same drive. On the first screenshot, this drive is attached to a Windows 8.1 installation. On the second one, the same drive (actually, exactly the same image of a virtual drive) is attached to a Windows 10 “20H1” installation. And the amount of free space reported by these operating systems is different!

Continue reading “Storage Reserve blocks some tools from thoroughly wiping unallocated space” →

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

Trim and unallocated space

~ msuhanov ~ 1 Comment

Have you ever heard that solid-state drives destroy evidence? Let’s revisit the facts before going further.

When first solid-state drives appeared, there was no Trim command. There was no easy way for a drive to reclaim unused blocks of user data (i.e., data exposed to a host as drive contents) for the wear-leveling process.

To mitigate this problem, manufacturers did a clever trick: they began producing file-system-aware solid state drives!

Some articles deny the existence of such a trick, but the truth is that some ancient solid-state drives were capable of parsing a partition table and an NTFS file system to locate unallocated (free) clusters and reclaim their blocks for the wear-leveling process (thus, wiping remnant data in these clusters).

Continue reading “Trim and unallocated space” →

OneDrive and NTFS last access timestamps

~ msuhanov ~ Leave a comment

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:

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

Deceptive NTFS short file names

~ msuhanov ~ 1 Comment

Are you aware of DLL hijacking? If yes, let’s suppose there is a program that executes the following line of code:

LoadLibrary('riched32.dll');

Its executable has the following name: “i_use_riched32.exe” (just as an example).

Now, take a look at the following contents of a directory containing this executable, the screenshots were taken of three tools: Explorer, FTK Imager Lite, The Sleuth Kit (each one points to the same directory).

svl-explorer
Explorer

svl-ftki
FTK Imager Lite

svl-tsk
The Sleuth Kit

Is the “riched32.dll” library hijacked for the “i_use_riched32.exe” executable? Let’s assume that no attempts to hijack the library have been made outside of the directory shown above.

Continue reading “Deceptive NTFS short file names” →

The “\$Extend\$Deleted” directory

~ msuhanov ~ 4 Comments

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.

(Source.)

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