Blog: SANS Digital Forensics and Incident Response Blog: Author - Hal Pomeranz

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


April 19th: Community Night at SANS NoVA!

Mike Wilkinson's DFIROnline Meetups continue to provide huge value to the community. The next one happens to fall on April 19th, during the SANS Northern Virginia event. We thought it would be fun to provide a space for people to gather and mingle while watching the presentations.

If you happen to be in the area, please join us on Thursday, April 19th! You do NOT have to be registered for the SANS conference to attend. All are welcome. SANS will be providing the beverages.

We will begin gathering at 7:15pm and the presentations begin at 8pm. Find us at:

Junior Ballroom 1/2
Sheraton Reston Hotel
11810 Sunrise Valley Dr.
Reston, VA 20191

We look forward to seeing everybody there!

Understanding EXT4 (Part 5): Large Extents

Hal Pomeranz, Deer Run Associates

I've received a lot of positive feedback from the forensics community about this series of articles, but what's really rewarding is when other forensics researchers teach me something I didn't know. I recently received an email from a colleague in Europe who was looking at the extent trees for a large file in his EXT4 file system and saw something he couldn't explain.

To replicate the finding I created a large file-- about 4GB in size. Recall from our discussion in Part 1 of this series that there is a 16-bit field to store the size of an extent. However, the high bit in that field is reserved to mark a preallocated extent, so you can only have 32K blocks in an extent. Assuming a typical 4K block size, that means


How to Mount Dirty EXT4 File Systems

Hal Pomeranz, Deer Run Associates

As some of you may remember, I've previously written about a technique for mounting EXT3 file system images with the read-only option, even when power was abruptly removed from the system-- as is typical during forensic seizure-- and the file system is still "dirty". In these cases, my technique involves using an alternate superblock, which will not have the "needs journal recovery" flag set, and using the "-t ext2" option to ignore any entries in the EXT3 file system's journal.

In the last year, however, I've been starting to see cases where I've had to analyze the newer EXT4 file system (hence my


Understanding EXT4 (Part 4): Demolition Derby

Hal Pomeranz, Deer Run Associates

In Part 3 of this series we looked at the EXT4 extent tree structure for dealing with very large or very fragmented files-- basically any situation where you need more than the four extent structures available in the inode. Go back and read that part now if you haven't already, because what I'm going to be talking about here follows directly from that discussion.

Extent Structures After Deletion

I got curious about what would happen when I deleted my /var/log/messages file. How does the inode change? What happens to block 131090, which holds my extent tree structure? Well, there's really only one way to find out: I deleted the file... carefully so I didn't lose ...