NE Scenarios and Advanced Edge Cases

Scenario 1 — Insider data exfiltration (INC-NE-2026-0915)

The departing engineer at Northgate Engineering copied proprietary manufacturing specifications to USB and cloud storage over a 6-week period. MFT analysis targets the engineer's workstation (DESKTOP-NGE-ENG14) to answer three questions: what files were copied, when were they copied, and where were they staged.

Identifying copied files. The copy indicator ($SI Modified before $SI Created) identifies every file that was copied to the workstation. Filter MFTECmd output for the engineer's profile directories (C:\Users\[username]\), the Documents and Desktop folders, and any non-standard directories. Sort by Created0x10. Entries where LastModified0x10 is earlier than Created0x10 are copies. The Created0x10 timestamp is when the copy was made. The LastModified0x10 timestamp is when the file was last edited at its original location — potentially months or years ago, reflecting the file's production history.

The copy indicator analysis produces a complete list of files copied to the workstation during any time period. Filter to the 6-week investigation window to identify the relevant copies. Files copied before the investigation window may be routine work activity. Files copied during the 6-week window — particularly files from restricted network shares containing manufacturing specifications — are exfiltration candidates.

Staging directory analysis. Look for directories created during the investigation window that contain clusters of copied files. A directory named something innocuous ("Project Archive", "Backup", "Personal") that contains 50 files with copy indicators all dated within the investigation window is a staging directory. The directory's own MFT record shows its creation time (when the directory was created for staging) and the $I30 index entries show when files were added.

If the staging directory was cleaned up (files deleted after USB transfer), the deleted MFT entries may still be recoverable. If the MFT entries were reallocated, the $I30 slack in the directory's index records may still contain the filenames and timestamps of the deleted files (Section 1.5). Check the directory's $SI Entry Modified timestamp as well. A directory that was created, had 50 files added, then had all 50 files deleted will show a recent Entry Modified timestamp even if the directory itself is now empty. The gap between the directory's Created timestamp and its Entry Modified timestamp spans the entire staging operation.

Timeline construction. Build a chronological timeline of copy operations by sorting the copied files by Created0x10. This shows the exfiltration pattern: which files were copied first, whether the copying occurred in sessions (clusters of copies separated by hours or days), and whether the pattern accelerated as the departure date approached. The timeline may show daily copying sessions during the engineer's lunch break, weekend access, or late-night sessions — each pattern provides evidence about the intent and method.

The nanosecond precision of the timestamps reveals whether the copies were performed manually (one file at a time, with gaps between copies as the user navigates) or by a tool (rapid sequential timestamps with consistent intervals). Manual copying produces irregular intervals. Scripted or drag-and-drop batch copying produces regular intervals. This distinction affects how you characterize the behavior in your report.

Scenario 2 — Ransomware attack (INC-NE-2026-1022)

The ransomware attack at Northgate Engineering involved 72 hours of activity from initial phishing access to encryption deployment. MFT analysis targets the patient zero workstation (DESKTOP-NGE-FIN01) and the encrypted server (SRV-NGE-FS01) to establish the attack timeline, identify attacker tools, and scope the encryption damage.

Mass modification timeline. The encryption event produces a characteristic MFT pattern: thousands of files with $SI Modified timestamps within a narrow time window (the encryption duration). Filter MFTECmd output for files with LastModified0x10 within the suspected encryption window. Sort by timestamp to determine the encryption start time, the encryption speed (files per second), and the encryption scope (which directories were affected, in what order).

The nanosecond precision of FILETIME timestamps reveals the encryption sequence: which directory was encrypted first, which was encrypted last, and how the ransomware traversed the filesystem. This information helps reconstruct the ransomware's directory walking algorithm and may identify directories that were skipped (perhaps the ransomware encountered an error or was terminated before completing).

Attacker tool detection. The attacker deployed tools (the ransomware executable, lateral movement tools, credential dumping utilities) in specific directories. Filter MFTECmd output for new executables (.exe, .dll, .bat, .ps1) created during the 72-hour intrusion window. Apply the timestomping detection methodology (Section 1.9) to every identified executable — attackers routinely timestomp their tools to blend with legitimate system files.

The $FN Created timestamps on attacker tools provide the real deployment timeline: when each tool was placed on the system, the sequence of tool deployment (reconnaissance tools first, then credential tools, then lateral movement tools, then the ransomware itself), and the time gaps between deployment stages. These gaps reveal the attacker's operational rhythm. A 12-hour gap between reconnaissance and credential dumping may indicate the attacker was operating from a different time zone and resumed work the next day. A 30-second gap suggests automated scripting.

Deleted tool recovery. After encryption, some attackers clean up their tools — deleting the deployment scripts, the lateral movement executables, and the credential dumping utilities. MFT analysis of freed entries in the attacker's staging directories may recover the deleted tools. The deployment batch script (if small enough to be resident) may be fully recoverable from its freed MFT entry, revealing the exact commands used to deploy the ransomware across the network.

Check $I30 slack in the attacker's staging directories as well. Even if the freed MFT entries have been reallocated, the directory's index slack may preserve the tool filenames and deployment timestamps. This evidence can establish the scope of the attacker's toolkit even when the tools themselves are unrecoverable.

Encryption scope assessment. The MFT provides a precise count of affected files. Filter for files with $SI Modified timestamps in the encryption window and group by parent directory. The result is a directory-by-directory encryption map: which shares were encrypted, how many files in each, and the total encrypted volume. This data feeds directly into the insurance claim (demonstrating the scope of damage) and the regulatory notification (identifying which data categories were affected).

Scenario 3 — Unauthorized access dispute (INC-NE-2026-1130)

The access dispute is the most constrained of the three scenarios from an MFT perspective. The employee claims they never accessed a restricted file share. MFT analysis alone cannot resolve this claim because MFT timestamps do not record which user performed a file operation — they record that the operation occurred. Resolving the access question requires correlating MFT evidence with user-specific artifacts: ShellBags (folder navigation), LNK files (file opening), Event Logs (authentication to the file server), and session data (logon/logoff times).

What the MFT can contribute to this investigation:

Accessed timestamp evidence (limited). On the file server (SRV-NGE-FS01), the files in the restricted share have $SI Accessed timestamps. If NtfsDisableLastAccessUpdate is not enabled on the server (servers often have this enabled by default on Windows Server 2019+), the Accessed timestamps may show when the files were last read. If the Accessed timestamp falls within the employee's authenticated session time, it is consistent with access — but not proof, because other users may have accessed the same files.

No modification evidence. If the employee only browsed the restricted share without downloading or editing files, the $SI Modified timestamp on the share's files would be unchanged. This is consistent with both "the employee accessed the files (read-only)" and "the employee never accessed the files (someone else changed the Accessed timestamp)." The MFT evidence is ambiguous for read-only access. However, if the employee's workstation contains copies of the restricted files (identified via copy indicator), that is MFT evidence of data exfiltration from the restricted share, even if the server-side MFT is ambiguous about who performed the access.

Absence analysis. In access disputes, the absence of evidence can be as important as the presence of evidence. If the MFT shows no copy indicators for restricted files on the employee's workstation, no files from the restricted share in the employee's directories, and no deleted entries with restricted share parent paths, the MFT evidence is consistent with the employee's claim of no access. Document this absence explicitly: "MFT analysis of DESKTOP-NGE-HR03 found no files with parent paths matching the restricted share, no copy indicators for files from that share, and no deleted entries referencing that location. This absence is consistent with the employee's claim but does not conclusively prove it, because read-only server access without downloading would not create MFT evidence on the workstation."

Parent directory metadata. The restricted folder's MFT record has $SI Entry Modified and $SI Accessed timestamps. If the folder's metadata was updated during the employee's session, it is consistent with access. But again, the MFT timestamp does not record which authenticated session triggered the update. Multiple users may access the same folder within the same time window.

The key lesson: MFT analysis is necessary but not sufficient for the access dispute. It establishes the temporal framework (when files and directories were last accessed or modified) that other artifact sources corroborate with user-specific evidence. The ShellBag analysis (WF4) on the employee's workstation provides the user-specific folder navigation evidence that the MFT cannot.

INC-NE-2026-0915 (Insider): Copy indicator filter (Created0x10 > LastModified0x10), staging directory $I30 analysis, USB-related paths, deleted MFT entries in user directories
INC-NE-2026-1022 (Ransomware): Mass $SI Modified in short window, executable $FN Created during intrusion, timestomping on attacker tools, $I30 slack in ProgramData directories
INC-NE-2026-1130 (Access Dispute): $SI Accessed on restricted files (if NtfsDisableLastAccessUpdate=0), $FN timestamps on disputed files, absence analysis (no MFT evidence of access supports defense)

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

Compressed: Flag 0x0800 in $SI + allocated size < real size + sparse data runs. Decompress before interpreting content.
EFS Encrypted: Flag 0x4000 in $SI + $DATA contains encrypted content. Requires user's certificate/key for decryption.
Hard Links: Link count > 1 in header + multiple $FN attributes with different parent refs. Same data, different names.
Junction/Symlink: Reparse point flag + $REPARSE_POINT attribute. Target path may be different from apparent path.
Extension Records: $ATTRIBUTE_LIST present + base record ref != 0 on extension records. Walk the list for complete attributes.
ReFS: Different filesystem entirely. No MFT, different metadata, limited tool support. Boot volume is always NTFS.