Ten scenario-based questions testing your operational understanding of MFT forensic analysis. Each question presents a realistic situation that requires applying the techniques from this module.
Question 1. You open a raw MFT record in HxD and the first four bytes read 42 41 41 44 instead of 46 49 4C 45. What does this indicate?
The record uses a different MFT version — "BAAD" is the signature for NTFS 3.1 records on Windows 10/11.
The "BAAD" signature indicates the record failed the fixup array integrity check. NTFS writes "BAAD" over the "FILE" signature when the fixup verification fails during a read — meaning the record was corrupted after being written (sector-level corruption, partial overwrite, or write interruption). The record's data cannot be trusted without manual verification of each attribute. Some attributes may be intact while others are corrupted.
The MFT extraction was performed incorrectly — the tool read from the wrong disk offset and captured non-MFT data.
The record has been securely wiped by an anti-forensic tool that overwrites MFT records with the "BAAD" marker.
Question 2. MFTECmd output shows a file with: EntryNumber 8,432 | SequenceNumber 1 | InUse True | Created0x10 2026-03-18T02:14:33.7654321 | Created0x30 2026-03-18T02:14:33.7654321 | ParentPath C:\ProgramData\Updates. Is this file suspicious?
No — the $SI and $FN timestamps match perfectly, so there is no timestomping. The file is legitimate.
The matching timestamps eliminate timestomping as a concern, but the file is in C:\ProgramData\Updates\ and was created at 02:14 — which falls within the ransomware intrusion window. The sequence number of 1 means this MFT entry has never been reused — the file was the first occupant, consistent with a newly created file (not a replacement). The location (ProgramData), the time (02:14 during the intrusion), and the entry being first-use all warrant investigation. Check the filename, file size, hash, and Prefetch entries. Not all attacker files are timestomped — some are created and used without modification.
Yes — a sequence number of 1 is abnormal for an entry number this high (8,432). Normal entries near the beginning of the MFT should have higher sequence numbers from reuse.
No — files in ProgramData are always legitimate system files. The Updates subdirectory is a standard Windows Update staging location.
Question 3. You need to verify MFTECmd's timestamp for a critical evidence file. The entry is at MFT record 15,000. The first attribute offset in the header is 0x38. You navigate to offset 0x38 and read the attribute type as 10 00 00 00 ($SI). The attribute length is 60 00 00 00 (96 bytes). Where do the $SI timestamps begin in the raw MFT?
At absolute offset 15,360,056 — calculated as (15,000 × 1,024) + 0x38 + 0x08 (skipping the attribute type and length fields).
The $SI attribute starts at offset 0x38 within the record (absolute offset: 15,000 × 1,024 + 0x38 = 15,360,056). The attribute header for a resident attribute includes a content offset field (typically at attribute_start + 0x14) that tells you where the content begins relative to the attribute start. For a standard unnamed $SI, the content offset is typically 0x18. So the timestamps begin at 0x38 + 0x18 = 0x50 within the record (absolute offset: 15,360,000 + 0x50 = 15,360,080). The Created timestamp is the first 8 bytes at that offset.
At the beginning of the record — $SI timestamps are always at fixed offsets 0x00 through 0x1F in every MFT record regardless of the attribute layout.
You cannot verify timestamps manually — the fixup array modifies the raw bytes, so the hex values you see are not the real timestamp values.
Question 4. A deleted file has: flags 0x00, sequence number 12, $DATA attribute with non-resident flag = 0, content size = 345 bytes. The file is on an SSD with TRIM enabled. Can you recover the file content?
Yes — the file content is resident (non-resident flag = 0, 345 bytes fits within the MFT record). Resident data is stored in the MFT record itself, not in data clusters. SSD TRIM only affects data clusters, not MFT records. The MFT is stored in a contiguous region of the volume that is not subject to TRIM. As long as the MFT entry has not been reallocated (which the flags 0x00 confirm — it's still free), the 345 bytes of resident content are fully recoverable regardless of the SSD.
No — SSD TRIM destroys all data from deleted files, including resident data in MFT records. The MFT region is subject to TRIM just like data clusters.
Possibly — the sequence number of 12 means the record has been heavily reused, so the resident data may belong to a previous file, not the most recently deleted one.
No — 345 bytes is too small for meaningful forensic analysis. Focus on larger files with recoverable cluster data instead.
Question 5. You find 23 files in a directory with $SI Created timestamps all within a 30-second window. All 23 have $SI Modified timestamps from 2–3 months earlier than $SI Created. What file operation does this pattern indicate?
The files were moved from another directory on the same volume — the move operation preserved $SI Modified but updated $SI Created.
The files were copied — the copy indicator is present on all 23 files ($SI Modified earlier than $SI Created). Windows preserves the source file's $SI Modified timestamp on the destination copy while setting $SI Created to the copy time. The 30-second window for all 23 copies indicates a batch copy operation (drag-and-drop, xcopy, robocopy, or script). The $SI Modified timestamps (2–3 months ago) reflect when the source files were last edited at their original location.
The files were extracted from a ZIP archive — archive extraction sets $SI Created to extraction time and $SI Modified to the timestamp stored in the archive.
The files were timestomped — the attacker set $SI Modified to dates in the past to make the files appear older.
Question 6. A directory contains 3 active files but has $INDEX_ALLOCATION and $BITMAP attributes on its MFT record. What forensic action should you take?
No action needed — $INDEX_ALLOCATION is created for all directories regardless of file count.
Parse the $I30 slack in the $INDEX_ALLOCATION records. NTFS only creates $INDEX_ALLOCATION when a directory exceeds the capacity of $INDEX_ROOT (typically 15-20+ files). A directory with only 3 files but $INDEX_ALLOCATION previously contained many more files. The removed files' index entries may persist in slack space — recoverable filenames, timestamps, and MFT references that prove what the directory previously contained. This is particularly important if the directory is suspected of being a staging location that was cleaned up.
The $INDEX_ALLOCATION was left over from a previous directory that occupied this MFT entry. It belongs to the old directory, not the current one.
The 3 files have extremely long filenames that overflow $INDEX_ROOT. The $INDEX_ALLOCATION is needed for the current 3 files.
Question 7. You are comparing two files in MFTECmd output. File A: EntryNumber 5000, SequenceNumber 3, FileName "report.docx". File B: EntryNumber 5000, SequenceNumber 3, FileName "REPORT~1.DOC". Both are InUse = True. What is the relationship?
They are the same file — two $FILE_NAME attributes on the same MFT record. "report.docx" is the Win32 long filename (namespace 0x01) and "REPORT~1.DOC" is the DOS 8.3 short filename (namespace 0x02). The identical EntryNumber and SequenceNumber confirm they reference the same MFT record. MFTECmd outputs one row per $FN attribute, so a single file with both long and short names produces two rows. This is one file with two names, not two files.
They are hard links — two directory entries pointing to the same MFT record with different filenames.
File B is a previous version of File A — the file was renamed from "REPORT~1.DOC" to "report.docx" and both names persist in the MFT.
This is a parser error — MFTECmd is outputting the same entry twice with different name interpretations.
Question 8. An attacker's executable shows: $SI Created = 2025-06-15T09:00:00.0000000, $FN Created = 2026-03-18T02:14:33.7654321. The USN Journal contains an entry for this file with reason code BASIC_INFO_CHANGE at 2026-03-18T02:15:01.2345678. What is the complete forensic interpretation?
Confirmed timestomping with complete real-time reconstruction. The file was created at 02:14:33 on March 18, 2026 ($FN Created — the kernel timestamp). At 02:15:01, the attacker ran a timestomping tool that modified the $SI Created timestamp to June 15, 2025 — the USN Journal entry with BASIC_INFO_CHANGE at 02:15:01 records this modification. The attacker waited 28 seconds after file creation before timestomping. All three detection methods are positive: Method 1 (temporal inversion — 9 months), Method 2 (zero fractional seconds on $SI), Method 3 (USN BASIC_INFO_CHANGE at 02:15:01). Classification: CONFIRMED. Real timeline: created 02:14:33, timestomped 02:15:01.
The BASIC_INFO_CHANGE entry indicates the file's permissions were changed at 02:15:01, not its timestamps. Permission changes also trigger this reason code.
The file was legitimately created in June 2025 and modified in March 2026. The USN entry records the March modification, and the $FN timestamp was updated during the modification.
The evidence is ambiguous — BASIC_INFO_CHANGE could be timestomping or a legitimate metadata update. Without additional evidence, you cannot classify this as confirmed.
Question 9. You are writing a forensic report for court. You recovered a deleted batch script from a freed MFT entry (resident data, 487 bytes). How do you document the recovery methodology in your report?
"The file was recovered using MFTECmd from the Master File Table." This is sufficient for a forensic report.
Document five elements: (1) Source: "MFT entry [number], sequence [number], flags 0x00 (not in use — deleted file)." (2) Method: "Resident file content (487 bytes) extracted from the $DATA attribute at offset [hex offset] within the MFT record. The $DATA attribute non-resident flag is 0x00 (resident), content size 487 bytes." (3) Integrity: "The MFT was collected with KAPE v[version] at [time], SHA256 hash [hash]. The MFT record's 'FILE' signature is intact, the fixup array validates correctly, and the attribute chain parses without error." (4) Confidence: "HIGH — intact resident data in a free MFT entry with valid structural integrity." (5) Limitations: "This recovery provides the file content and metadata at the time of deletion. It does not establish which user created or executed the file."
"I used a hex editor to extract 487 bytes from the MFT. The content is a batch script." No further documentation is needed because the raw extraction speaks for itself.
Deleted file recovery cannot be documented for court because the chain of custody was broken when the file was deleted — you cannot prove the content wasn't modified between deletion and recovery.
Question 10. Your MFTECmd output shows 262,144 MFT entries but 267,891 CSV rows. The raw MFT file is exactly 268,435,456 bytes (262,144 × 1,024). Is this output correct?
Yes — the output is correct. MFTECmd produces one row per $FILE_NAME attribute, not one row per MFT entry. Files with both a Win32 long name and a DOS 8.3 short name produce two rows (one per $FN attribute). The 5,747 additional rows (267,891 - 262,144) represent files with two $FN attributes. When counting unique files for your report, use distinct EntryNumber values, not total row count. The MFT size verification (262,144 × 1,024 = 268,435,456) confirms the raw MFT file is complete — every entry is accounted for.
No — the output has too many rows. MFTECmd should produce exactly one row per MFT entry. The extra rows indicate parser duplication errors.
No — the output has too few rows. A 262,144-entry MFT should produce more than 267,891 rows because each entry has multiple attributes (SI, FN, DATA) that each get their own row.
The discrepancy is caused by Alternate Data Streams — each ADS adds an extra row to the output, and 5,747 files have ADS entries.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
You've built the foundations of artifact-level forensic analysis.
WF0 gave you the taxonomy, NTFS architecture, and the five-step methodology. WF1 took you inside the MFT at the binary level — every attribute, every timestamp, every edge case. From here, every artifact category gets the same raw-first treatment.
WF2–WF10: every major Windows artifact decoded at binary level — USN Journal, Prefetch, Amcache, Shimcache, ShellBags, LNK, Jump Lists, SRUM, Event Logs, and the Registry hives
INC-NE-2026-0915 (WF13) — Insider data exfiltration capstone. Work the complete investigation from USB history to OneDrive exfiltration evidence
INC-NE-2026-1022 (WF14) — Ransomware capstone. Three-host triage (FIN01 → IT03 → FS01) across the 72-hour attack chain
The lab pack — 25+ realistic evidence files in 10 formats, simulated KAPE triage pre-populated, both capstones deployable to your own VM
Anti-forensic detection methodology — defeat timestomping, log clearing, and Prefetch deletion with cross-artifact correlation
