$DATA Attribute — Resident and Non-Resident

Resident $DATA — content inside the MFT record

When a file's content is small enough to fit within the MFT record alongside the header, $SI, $FN, and any other attributes, NTFS stores the data directly in the $DATA attribute as resident content. The threshold is approximately 700 bytes, though the exact limit depends on how much space the other attributes consume. A file with a short filename (one $FN attribute with namespace 0x03) has more room for resident data than a file with a long filename (two $FN attributes plus a longer name consuming more bytes).

The resident $DATA attribute has the standard attribute header (type 0x80, length, non-resident flag = 0), followed by the content size and content offset fields specific to resident attributes. The content offset (typically 0x18 from the attribute start) points to where the actual file data begins within the attribute. The content size tells you exactly how many bytes of file data are present.

This is forensically significant for two reasons. First, resident file content is physically part of the MFT record. When the file is deleted, the MFT entry is marked as free but the data remains in the record until the entry is reallocated for a new file. On a volume with many free MFT entries, deleted resident files can persist for weeks or months. Second, resident file content is captured by any tool that extracts the MFT — KAPE's $MFT target, FTK Imager's MFT extraction, or even a raw copy of the MFT file. You don't need the full disk image to recover resident data; you only need the MFT.

Small files that are commonly resident include batch scripts, small configuration files, PowerShell scripts, registry exports, CSV files, small text notes, and short email drafts. In an investigation, these are often among the most interesting files — a malicious batch script, a configuration file for a C2 implant, or a text file listing targeted data. If these files were deleted, their content may be fully recoverable from the MFT alone.

To extract resident data from a raw MFT record: locate the $DATA attribute (type 0x80) in the attribute chain, confirm the non-resident flag is 0, read the content offset and content size from the attribute header, and copy the specified number of bytes from the content offset. The extracted bytes are the literal file content — no decompression, no decoding, no cluster mapping required.

Non-resident $DATA — data run encoding

When a file exceeds the resident threshold, NTFS stores the content in clusters on the disk volume and records the cluster locations in a data run list within the $DATA attribute. The non-resident $DATA attribute header (identified by the non-resident flag = 1 at offset 0x08 of the attribute) contains additional fields not present in resident attributes: the starting VCN (Virtual Cluster Number — the logical offset within the file, usually 0 for the first data run), the ending VCN, the data run offset (where the run list begins within the attribute), the compression unit size, the allocated size (in bytes, rounded up to cluster boundaries), the real size (the actual file content size), and the initialized size (how much of the allocated space contains valid data).

The data run list is a compact binary encoding that maps the file's logical extent to physical clusters on the volume. Each run entry specifies a contiguous range of clusters: how many clusters in the run (the length) and where the run starts on disk (the offset). The encoding uses a header byte where the low nibble indicates the number of bytes used for the length and the high nibble indicates the number of bytes used for the offset.

A concrete example: the header byte 0x31 means the length field is 1 byte and the offset field is 3 bytes. If the next bytes are 08 56 34 12, the run length is 0x08 (8 clusters) and the starting cluster is 0x123456 (little-endian reading of 56 34 12). This run describes 8 contiguous clusters starting at cluster 0x123456 on the volume. To find the physical byte offset on disk, multiply the cluster number by the cluster size (typically 4,096 bytes): 0x123456 × 4,096.

The offset field in subsequent runs is signed and relative to the previous run's starting cluster. If the first run starts at cluster 0x123456 and the second run's offset field contains 0x000100, the second run starts at cluster 0x123456 + 0x000100 = 0x123556. This relative encoding saves space — most runs are near each other on disk (because NTFS tries to allocate contiguous clusters), so the offset differences fit in fewer bytes than absolute cluster numbers.

The run list is terminated by a 0x00 byte. When walking the run list, read the header byte; if it's 0x00, you've reached the end. Otherwise, extract the length and offset according to the nibble sizes, record the run, and advance to the next entry.

For fragmented files, multiple runs describe non-contiguous cluster ranges. A heavily fragmented file might have dozens of runs. The data run list maps the complete physical layout of the file on disk — essential for recovering file content from a raw disk image when the filesystem structures are damaged.

Alternate Data Streams

NTFS supports multiple $DATA attributes per MFT record. The default (unnamed) $DATA attribute contains the file's primary content — what you see when you open the file. Named $DATA attributes are Alternate Data Streams (ADS) — additional data payloads attached to the file but invisible to standard directory listings, dir commands, and Windows Explorer.

An ADS is identified in the MFT record by a $DATA attribute (type 0x80) with a non-zero name length in the attribute header. The name follows the attribute header and precedes the content (for resident ADS) or data run list (for non-resident ADS). The name is in UTF-16LE, just like filenames in $FN attributes.

To access an ADS from the command line: type filename:streamname or notepad filename:streamname. To list ADS on a file: dir /r filename. To list ADS using PowerShell: Get-Item filename -Stream *. MFTECmd reports ADS in its output — look for entries with the same MFT entry number but different $DATA attribute names.

Forensically, ADS has two significant applications:

Zone.Identifier — legitimate browser tracking. When Internet Explorer, Edge, or Chrome downloads a file, Windows writes a Zone.Identifier ADS containing the download URL and the security zone (typically Zone 3 = Internet). This is the mechanism behind the "This file was downloaded from the Internet" warning dialog. The Zone.Identifier ADS is forensic evidence that a file was downloaded from a specific URL. Many users and even some investigators don't realize this metadata exists because it's invisible in normal file operations. In the insider threat scenario (INC-NE-2026-0915), Zone.Identifier streams on files copied to USB can reveal that the files were originally downloaded from cloud storage before being moved to local storage and then to USB.

Malware data hiding. Attackers store malicious payloads in ADS of legitimate files. A benign-looking text file readme.txt can have an ADS readme.txt:payload.exe containing a full executable. The file's displayed size in Explorer reflects only the primary $DATA attribute — the ADS content is not included. Antivirus solutions have improved their ADS scanning over the years, but some still miss ADS payloads during routine scans. In the MFT, ADS appear as additional $DATA attributes on the same MFT record — the examiner who walks the complete attribute chain will find them.

Data attribute and file recovery assessment

When assessing whether a deleted file's content is recoverable, the $DATA attribute type determines your approach:

Resident $DATA (deleted file): High probability of recovery. The content is in the MFT record. As long as the MFT entry has not been reallocated to a new file, the resident data is intact. Check the MFT record flags (offset 0x16) — if flags = 0x00 (file, not in use), the entry is available but not yet reallocated. The content is likely intact. If the flags indicate the entry is now in use (0x01 or 0x03), the record has been reallocated and the previous file's data is gone.

Non-resident $DATA (deleted file, HDD): Moderate probability of recovery. The data run list in the MFT record still points to the clusters that contained the file's data. If those clusters have not been overwritten by new files, the content is intact. Check the volume bitmap to determine whether the clusters are still marked as free (unallocated). Unallocated clusters on an HDD retain their data until new data is written to them.

Non-resident $DATA (deleted file, SSD): Low probability of recovery. TRIM commands may have zeroed the clusters after deletion. Even if the volume bitmap shows the clusters as free, the underlying flash blocks may have been erased by the SSD controller's garbage collection. Extract the clusters and check whether they contain data or are zeroed. If zeroed, the data is unrecoverable from the SSD — though a pre-deletion backup, Volume Shadow Copy, or the USN Journal may provide alternative evidence of the file's existence and characteristics.

Non-resident $DATA (deleted file, fragmented): The data run list shows multiple non-contiguous cluster ranges. Each range must be checked independently — some clusters may be intact while others have been overwritten. Partial recovery is possible: the intact clusters provide fragments of the file content, and depending on the file format, these fragments may be interpretable (text files, log files) or useless (encrypted containers, compressed archives where partial data cannot be decompressed).