SANS Digital Forensics and Incident Response Blog: Tag - NTFS

NTFS $I30 Index Attributes: Evidence of Deleted and Overwritten Files

Daunting as it may seem, one of the most wonderful aspects of Windows forensics is its complexity. One of the fascinating aspects of digital forensics is how we often leverage conventional operating system features to provide information peripheral to their original design. One such feature is the Windows NTFS Index Attribute, also known as the … Continue reading NTFS $I30 Index Attributes: Evidence of Deleted and Overwritten Files

NTFS: Attributes Part One

In the previous post in this series on NTFS file systems, we were just dipping our feet in the complicated waters by examining the output of fsstat. Let's pick up where we left off. Below is the $AttrDef Attribute Values section of fsstat's output from the previous post:

$AttrDef Attribute Values:
$STANDARD_INFORMATION (16) Size: 48-72 Flags: Resident
$ATTRIBUTE_LIST (32) Size: No Limit Flags: Non-resident
$FILE_NAME (48) Size: 68-578 Flags: Resident,Index
$OBJECT_ID (64) Size: 0-256 Flags: Resident
$SECURITY_DESCRIPTOR (80) Size: No Limit Flags: Non-resident
$VOLUME_NAME (96) Size: 2-256 Flags: Resident
$VOLUME_INFORMATION (112) Size: 12-12


NTFS: An Introduction

Earlier this year, a life time ago in internet years, I published a series of posts on the FAT file system. Over the next few months, I'll be publishing a similar series on NTFS. Much of the information contained in these posts will come from Brian Carrier's excellent book, File System Forensic Analysis, articles from Microsoft and other sources. Where applicable, specific sources will be cited within each blog post.

On day one of SANS Sec 508: Computer Forensics, Investigation and Response we cover the most common file systems in detail. Almost without fail, someone asks if the material is really important


Perl and Forensics

Perl is a wonderful tool for forensics. With Perl I can write a short script that can do a variety of repetitive tasks in a short amount of time. I find that if I combine Perl scripts to process my command-line output, I can save myself large amounts of time during an investigation. Plus Perl can be used as a filter for data in that after running the script, I can feed the data into Autopsy or a hexeditor.

In a recent case I was working on, I needed to retrieve several keywords from the unallocated space on a NTFS partition and then review the clusters they were located in with Autopsy. Perl came to the rescue. After running a "strings -td | grep -i -f {keyword file} > keywords.asc" on the blkls file, I used the cut command to trim everything after the offsets. Next, I had to divide the offsets by 4096, as that was the block size, and send the result to blkcalc to get the actual cluster my keyword was located in. With 200 clusters to look at, I did not want to do this by

... Continue reading Perl and Forensics

Alternate Data Streams Overview

I'm sure it comes as no great shock that I am a member of a number of listserves on digital forensics. One question that seems to come up every few weeks is NTFS Alternate Data Streams. There have been many excellent articles on ADS, so I don't propose to go heavily into the details here. I will just include an overview and some of the better references. This is a basic overview. If you want more details, check out the links for some really good write-ups.

What are Alternate Data Streams?

Alternate Data Streams (ADS) have been around since the introduction of windows NTFS. They were designed to provide compatibility with the old Hierarchical File System (HFS) from Mac which uses something called resource forks. [