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
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!
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
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
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 ...