In this section
MFT Analysis for the Three NE Scenarios
Scenario
The insider threat investigation has 7 forensic questions (Module 0, Section 0.10). Four of them are answerable from MFT analysis alone: which files were copied (copy indicator), when were they copied ($SI Created timestamps), were files staged in a directory ($I30 + MFT timestamps), and did the subject attempt to delete evidence (deleted MFT entries + anti-forensic indicators).
Figure WF1.11 — MFT evidence targets for each NE investigation scenario. The insider threat investigation uses the copy indicator and staging directory analysis. The ransomware investigation uses mass modification timelines and timestomping detection. The access dispute uses timestamp analysis but requires corroboration from user activity artifacts (ShellBags, LNK, Event Logs) for attribution.
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.
Anti-Pattern
Analyzing only the MFT without corroboration
MFT analysis answers "what happened to files." It does not answer "who did it" (requires logon events), "how" (requires Prefetch and process execution evidence), or "how much data left the network" (requires SRUM). The MFT is one layer of a multi-artifact investigation. Document which questions the MFT answers and which require corroboration from other artifact sources covered in WF2-WF10.
Investigation Principle
Each NE scenario has a different MFT analysis focus. Insider threat: copy indicators and staging directory analysis. Ransomware: mass file modification timeline and executable deployment. Access dispute: file access evidence and its absence. The MFT technique is the same. The investigative question determines which MFT patterns you search for.