Advanced MFT Edge Cases

Compressed files

NTFS compression stores file data in compressed form on disk while presenting the uncompressed data to applications through the filesystem API. The compression operates on 16-cluster compression units — NTFS compresses each 16-cluster block independently, and if the compressed result is smaller than 16 clusters, the saved space is represented as sparse runs in the data run list.

In the MFT record, compressed files are identified by the flag 0x0800 in the $SI attribute's permission flags field. The $DATA attribute's allocated size is smaller than the real size (the opposite of the normal relationship, where allocated size is equal to or slightly larger than real size due to cluster rounding). The data run list contains runs with zero offsets — these represent the sparse (saved) space within compressed units.

Forensic implications: when recovering a compressed file's content, you must decompress the data after extracting it from the cluster ranges. Raw cluster extraction produces compressed data that is not directly interpretable. MFTECmd correctly reports both the allocated size and real size for compressed files, but examiners who work directly with raw data must account for the compression.

Compressed files are relatively uncommon on modern Windows installations — Windows 10/11 does not compress files by default, and NTFS compression is generally discouraged due to performance impact. However, older systems, servers with disk space constraints, and systems where an administrator enabled compression on specific folders may contain compressed files.

EFS-encrypted files

The Encrypting File System (EFS) encrypts file content at the NTFS level. The file's $DATA attribute contains ciphertext rather than plaintext — the data is encrypted with a file encryption key (FEK), which is itself encrypted with the user's public key and stored in a $LOGGED_UTILITY_STREAM attribute (type 0x100) on the MFT record.

In MFTECmd output, EFS-encrypted files are identified by the flag 0x4000 in the $SI flags. The filename, timestamps, parent directory, and file size are all readable — encryption only affects the $DATA content, not the metadata. This means MFT-based timeline construction and deleted file metadata recovery work normally on encrypted files. The limitation is content recovery: extracting the $DATA content produces encrypted bytes that require the user's decryption key.

For forensic analysis of EFS-encrypted files, three approaches: recover the user's EFS certificate from their Windows profile (the certificate is stored in the user's certificate store and can be exported if you have the user's password or a domain recovery agent certificate), use a domain EFS recovery agent certificate (if configured by the organization), or analyze the file metadata without accessing the content. In many investigations, the metadata alone (filename, timestamps, parent directory, file size) is sufficient — you can prove the file existed and was accessed without needing to read its content.

Hard links and their forensic impact

Hard links create multiple directory entries pointing to the same MFT record. The MFT record has a hard link count greater than 1 (header offset 0x12), and contains multiple $FILE_NAME attributes — one for each hard link. Each $FN attribute has a different parent directory reference and potentially a different filename, but they all share the same $DATA attribute.

In MFTECmd output, hard-linked files appear as multiple rows with the same EntryNumber but different FileName and ParentPath values. The key forensic consideration is not to count hard links as separate files — they are different names for the same data. If a file appears in both C:\Windows\System32\ and C:\Windows\SysWOW64\ with the same entry number, it is one file with two names, not two files.

Hard links are commonly used by Windows itself (many System32 files are hard-linked to their SysWOW64 counterparts on 64-bit systems) and by the Windows Component Store (WinSxS). They are also used by some installation frameworks and occasionally by attackers who create hard links to legitimate system files as a persistence mechanism.

Junction points and symbolic links

Junctions and symbolic links are NTFS reparse points — special directory or file entries that redirect filesystem access to a different location. They are identified in the MFT by the presence of a $REPARSE_POINT attribute (type 0xC0) containing the target path.

Junctions are directory-only, local-volume-only redirects. C:\Users\Default User is a junction pointing to C:\Users\Default. Junctions are transparent to applications — accessing the junction is the same as accessing the target. Windows uses junctions extensively for backward compatibility paths.

Symbolic links can be files or directories and can cross volume boundaries. They function similarly to junctions but are more flexible. Symbolic links were introduced in Windows Vista and are used less frequently than junctions.

Forensic implications: when you encounter a junction or symlink in an investigation, the files "inside" the junction don't actually exist at that path — they exist at the target path. An examiner who reports finding suspicious files in a junction directory is actually reporting files at the target location. MFTECmd reports reparse points in its output — check the ReparseTarget column to identify the real file location.

Extension records

When a file has more attributes than fit in a single 1,024-byte MFT record (many Alternate Data Streams, very long filenames, complex security descriptors, or numerous hard links), NTFS creates extension records — additional MFT entries that hold the overflow attributes. The base record's header at offset 0x20 (base record reference) is zero, and the extension record's base record reference points back to the base entry.

MFTECmd handles extension records automatically — it consolidates the base and extension attributes into a single output. When working with raw hex, check the base record reference at offset 0x20: if non-zero, the record you're examining is an extension. Navigate to the base record (identified by the entry number in the base reference) to find the primary attributes ($SI, first $FN, primary $DATA).

Extension records are uncommon — most files fit comfortably in a single MFT record. Files most likely to have extensions: files with many ADS, files with extremely long paths, and files with complex access control lists. In forensic analysis, extension records rarely cause issues because MFTECmd handles them transparently, but recognizing them in raw hex prevents confusion when an MFT record appears to lack expected attributes.

ReFS — a different filesystem entirely

ReFS (Resilient File System) is Microsoft's successor to NTFS, designed for data integrity and resilience. ReFS is used on Windows Server Storage Spaces Direct volumes and is available as a formatting option on some Windows 11 configurations. ReFS does not use an MFT — it uses B+ tree metadata structures that are fundamentally different from NTFS.

If you encounter a ReFS volume in an investigation, MFT analysis does not apply. The forensic tooling for ReFS is significantly less mature than NTFS tooling — as of 2026, no equivalent of MFTECmd exists for ReFS metadata. Analysis of ReFS volumes typically requires X-Ways Forensics or EnCase, which have limited but growing ReFS support.

The key forensic considerations for ReFS: no $FILE_NAME timestamps (removing the primary timestomping detection method), no $I30 slack (removing directory-level deleted file recovery), and no resident data recovery (ReFS uses a different small-file storage mechanism). The loss of these forensic capabilities makes ReFS evidence significantly harder to analyze than NTFS evidence.

In practice, you will rarely encounter ReFS on workstation evidence. It is primarily used on server storage volumes. When you do encounter it, document the filesystem type in your report and note the limitations of the analysis compared to NTFS evidence.