SANS Digital Forensics and Incident Response Blog

SANS Digital Forensics and Incident Response Blog

Resident $DATA Residue in NTFS MFT Entries

Hal Pomeranz, Deer Run Associates


I came across a small but interesting artifact in the course of a recent investigation. Quick Google searching failed to find any documentation elsewhere, so here's a brief summary of my findings. The bottom line is that residue of old resident $DATA entries may exist in NTFS MFT records after the file data has grown large enough to become a non-resident attribute.

You can actually force this situation to occur yourself. First, create a small text file using Notepad or your preferred text editor (Carrier suggests limiting the file size to less than 700 bytes if you want the file to be stored as a resident attribute). Here's a picture of the MFT entry for the file I created:

MFT entry, resident $DATA attribute


Hex editor view of MFT entry with resident $DATA attribute

The $DATA attribute (0x80) starts at byte offset 432 (0x01B0). The non-resident flag is zero, meaning this is a resident $DATA attribute. The size of the resident data is 469 bytes (0x01D5) starting 24 bytes (0x18) from the beginning of the attribute. You can see the text starting at byte offset 456 (0x01C8) in the hex editor.

The interesting stuff happens when you add more data to your file. In my case, I added a little over 1K additional data in my Notepad buffer to force the attribute to become non-resident. I dumped out the MFT entry again, and here's the hex editor view:

MFT entry with non-resident $DATA attribute


Image of same MFT entry with non-resident $DATA attribute

The $DATA attribute still starts at byte offset 432. In the updated entry, however, the non-resident flag is 0x01, indicating that the $DATA attribute is non-resident. I'm not going to bother decoding the rest of the $DATA attribute because you can quite clearly see the 0xFFFFFFFF end of file marker that marks the end of the new MFT entry (byte offset 504).

The four bytes after the end of file marker are also modified. These four bytes take us to the end of the sector boundary. From that point forward, you can see the contents of the original resident $DATA. While it doesn't show in the images, the last 512 bytes of both MFT entries are the same.

This residual data gives us a fragment of the contents of a file at a particular point in time. This version of the file may have only existed for a brief period and not been captured in a Volume Shadow Copy or other backup. In my investigation I got a string hit on the residual data in the MFT entry while the current (and non-resident) version of the file did not contain the string of interest. Both versions ended up being relevant to the investigation, but the historical relic of the residual data made the combined find even more interesting.

Hal Pomeranz is an Independent Digital Investigator, a SANS Institute Faculty Fellow, and a GCFA. He doesn't always analyze NTFS, but when he does he often uses a hex editor. Hal will be teaching For508: Advanced Computer Forensic Analysis and Incident Response in San Antonio, Nov 27 - Dec 1.

12 Comments

Posted October 16, 2012 at 1:37 AM | Permalink | Reply

Rob Lee

Perhaps you call it MFT $Data Slack? That was a great write-up.

Posted October 16, 2012 at 9:57 AM | Permalink | Reply

Stumpy

Good stuff, looking at the raw MFT entries can often yield gold. I got a great result on a guy who accepted an evidential file was on his system but claimed no knowledge of it. The MFT entry showed the residual part of the original file name (the file name was changed from a very long string to a short string, the data was non-resident), indicating that the guy had renamed the file (no one else had access to the system). When presented with this, the guy "rolled over".

Posted October 16, 2012 at 3:38 PM | Permalink | Reply

David Cowen

We are also finding the resident file data in the $logfile but with some differences depending on OS version. Have you tested this on multiple versions of windows to see if the behavior varies?

Posted October 21, 2012 at 10:19 AM | Permalink | Reply

Hal Pomeranz

I've seen the behavior in both XP and Windows 7. But both of those are using NTFS v3.1 that was released with Windows XP. It might be interesting to go back to Windows 2000 and earlier and see how long this behavior has existed in NTFS. Personally, I don't have any systems that old in my life at the moment.

Posted October 17, 2012 at 1:37 AM | Permalink | Reply

proneer

It has been called MFT Slack, and It used in various ways in Incident Response.

Posted October 21, 2012 at 10:16 AM | Permalink | Reply

Hal Pomeranz

Thanks for the pointer to "MFT Slack". When I search on that, I turn up some relevant and interesting documents.

Posted October 22, 2012 at 7:57 PM | Permalink

proneer

You're right. "MFT Slack" is used for finding previous $INDX entry as well as previous $DATA. Check out my slides for more information, http://forensicinsight.org/archives/912 -> [2012-01-07] [INSIGHT] MFT

Posted October 18, 2012 at 4:16 AM | Permalink | Reply

Nick Klein

Hal, I was literally in FOR508 at SANS Singapore with Jess this week and when we covered resident data, I made a note to test this scenario. This makes me wonder what interesting files might exhibit this behaviour; start small and grow to become non-resident? Might be interesting to scan the MFT for other "MFT $Data Slack" Great write up, thanks!

Posted January 24, 2013 at 8:18 PM | Permalink | Reply

Steve Si

Even if the file is later reduced in size to < 700 bytes, the extent is still used by NTFS. i.e. once the file grows bigger than the $MFT $DATA area, the $data stack in never overwritten, even if the file is later reduced to 10 bytes!

Posted February 28, 2013 at 5:15 PM | Permalink | Reply

Marie

I am a current student who has been trying to wrap my mind around how to read a MFT entry. 0B1, 0x040000, =|....I literally was dumbfounded (to put it mildly) because our textbook didn't exactly go in depth. So I set out on a mission with my old pal Google to learn more and ran across this. Now, I totally get it.

You should consider writing books in the "For Dummies" series. And I'm not trying to be funny either.

Posted March 18, 2013 at 4:28 PM | Permalink | Reply

H. Carvey

Hal,

I finally got around to updating my MFT parser and was looking at resident data attributes when I remembered your post. I haven't seen anything like this...yet...but it would be cool to see in practice.

Posted April 24, 2013 at 9:17 AM | Permalink | Reply

Matt

The INDEX_ROOT attribute can also be found in MFT slack, I have found this resident data before a directory grows and moves into the INDEX_ALLOCATION attribute. This attribute can reveal the FilenameAttribute when type 48 is defined. Can be handy when a file may have been deleted from a suspect directory.

Post a Comment






Captcha

* Indicates a required field.