MFT Analysis for the Three NE Scenarios

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 (WF1.5).

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.

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 (WF1.9) to every identified executable — attackers routinely timestomp their tools.

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.

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.

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.

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 not proof of who accessed it.

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.