A Journey into NTFS: Part 1

Today’s post kicks off a multi-part series looking at NTFS. Yes, I’m diverting from the normal schedule to launch this series. Over the next n posts, I’m going to look at parts of the New Technology File System, what the data means, how we can parse it, and how the data may be applied to an investigation. I often find that reliance on a particular tool, set of tools, or methodology, is based on the data that the tool shows you. While relying on that is not necessarily evil, we may be leaving evidence on the table. I still work with analysts and students who are not aware that NTFS files have more than four timestamps! I’m hoping this series will reverse some of this.

There is somewhat of an order to this series — it will make more sense as I go along. Whilst it would be fun to walk through MFT entries sequentially, I’m going to explain a few things before getting into relevant artifacts.

Let’s start at the cluster level. Today, I’m going to focus on the two metadata files $Bitmap and $BadClus.

$Bitmap

The first file I’ll examine is $Bitmap. This file contains the status of clusters in the filesystem. As you can imagine, clusters can have one of two states: used, or unused. This file tracks those allocations. The NTFS metadata file $Bitmap is located at MFT entry 6.

Let’s take a look at this artifact using The Sleuth Kit’s istat command:

:/mnt/ewf# istat ewf1 6

Output:

istat output for MFT entry 6, $Bitmap

Note that I will be going through NTFS attributes in a (soon) future post, so for now just stick with me. Let’s look at a few takeaways from this output:

• This file has $STANDARD_INFORMATION and $FILE_NAME attributes (again, more on these soon); these timestamps correspond to the filesystem creation. We’ll see this in several NTFS files, and can be used as a timeline starting point.
• The $DATA attribute of this file is what contains the cluster allocation information. There is one bit for each cluster in the filesystem, starting at bit 0. If the bit is set to 1, that means the cluster is allocated. If the bit is set to 0, then obviously it’s not.
• As expected, because there is data on the drive, we have clusters in use by the $DATA attribute. This is simply a confirmation that the filesystem has allocated data.

Here’s a screenshot of the beginning of this file:

Screenshot from FTK Imager showing contents of $Bitmap

Notice that these clusters are mostly allocated, except for offset 2B and 2C, where we’ve got the values 0F and 00, respectively. 0F converts to 00001111, which gives us an idea of the allocation of those particular clusters. Given the position, it appears as though clusters 348–359 are unallocated.

Let’s use another Sleuth Kit Tool, blkstat, to determine whether or not my math checks out:

:/mnt/ewf# for i in {347..360}; do blkstat ewf1 ${i}; done

Output from the tool blkstat

$BadClus

Continuing along the trend of looking at cluster management, the second NTFS file I’m going to look at is $BadClus. The name for this file is somewhat of a giveaway; this is what NTFS uses to keep track of bad clusters.

This file is located at MFT entry 8, and will often be resident unless you have a large number of bad clusters. Let’s use istat to view data and attributes about this file:

:/mnt/ewf# istat ewf1 8

istat output for MFT entry 8, $BadClus

Again, we have timestamps that we can correlate to the creation of the filesystem. Note that these timestamps line up with previous attributes we’ve seen. Notice also that this file has two $DATA attributes: $DATA (No name) and $Bad. $Bad is where bad clusters would be identified.

Do you notice any discrepancies in the output? Note how the $Bad attribute is non-resident, and has a size of 26,578,251,776 — but yet no cluster allocation? This is a good sign that, thus far, bad clusters have not been detected by the filesystem. Furthermore, we can use this as another reference point for our disk. Let’s look at some different output real quick:

:/mnt/ewf# fsstat ewf1

fsstat output from test image

Within the Content information, we have sector and cluster size information, as well ranges for both. Multiply either out, and we get within 6 sectors or one cluster of our $BadClus:$Bad total size. If it has to, Windows will label the entire disk as bad!

Until tomorrow, Happy Forensicating!