Check My Knowledge

NTFS does not use different signatures for different versions. All valid MFT records use the "FILE" signature regardless of NTFS version. "BAAD" is not a version indicator.

Correct. NTFS replaces the "FILE" signature with "BAAD" when the fixup values at the sector boundaries (offsets 0x1FE and 0x3FE) do not match the signature value stored in the fixup array. This is a corruption detection mechanism covered in Section 1.1. The record's data cannot be trusted without manual verification of each attribute.

If the extraction started from the wrong offset, you would see random data, not the specific "BAAD" string. "BAAD" is deliberately written by NTFS, not random corruption.

Anti-forensic tools that target MFT records typically zero the record or overwrite with random data. "BAAD" is written by the NTFS driver itself during normal corruption detection, not by external tools.

TRIM operates on data clusters, not MFT records. The MFT is stored in a fixed allocated region that is not subject to TRIM. Resident data inside MFT records is unaffected by TRIM regardless of the drive type. Section 1.4 covers this distinction.

A high sequence number means the entry has been reused many times, but the current attributes (with flags 0x00) belong to the most recent file that occupied the entry. The sequence number tells you how many times the slot was recycled, not that the current data is unreliable. Section 1.6 covers sequence number interpretation.

Correct. The non-resident flag of 0 confirms the data is resident inside the MFT record. The MFT region is not subject to TRIM. The flags value 0x00 confirms the entry is free but not reallocated. The content persists until a new file is allocated to this entry. Extract the content by navigating to the $DATA attribute and reading the content bytes. Section 1.4 and Section 1.10 cover resident data recovery.

Small files are often the most forensically valuable: batch scripts, configuration files, C2 implant configs, text notes listing targets. A 345-byte file could contain a complete batch script with a C2 URL, as shown in the Section 1.4 hex dump example. File size does not determine forensic relevance.

Same-volume moves do not change $SI Created because the MFT entry does not change. Only the parent directory reference in $FN is updated. The copy indicator ($SI Modified before $SI Created) does not appear on same-volume moves. Section 1.8 covers this distinction.

Correct. The copy indicator pattern: $SI Modified (November) is earlier than $SI Created (March). The $FN Created timestamps matching $SI Created confirms the files were created on this volume in March, not timestomped. The 30-second window for all 23 files indicates a batch operation (drag-and-drop, xcopy, or script). Section 1.8 covers the copy indicator in detail.

Timestomping typically targets $SI Created, not $SI Modified. Also, the $FN timestamps match the $SI Created values, confirming the files were genuinely created in March. If timestomping had occurred, $SI and $FN would show a discrepancy. Section 1.9 covers the three detection methods.

Archive extraction does produce this pattern, making it a legitimate false positive for the copy indicator. However, the question states these are in a "staging directory," and you would verify by checking whether an archive file exists with a matching creation timestamp. The question tests whether you recognize the copy indicator pattern. Both copy and archive extraction use the same API mechanism.

Correct. This is the strongest possible timestomping finding: Method 1 (temporal inversion, $SI 9 months before $FN), Method 2 (zero fractional seconds on $SI while $FN has full nanosecond precision), and Method 3 (USN BASIC_INFO_CHANGE at 02:15:01 documents the exact time of the manipulation). The 28-second gap between creation (02:14:33) and timestomping (02:15:01) reconstructs the attacker's actions. Section 1.9 covers the systematic detection workflow and classification system.

BASIC_INFO_CHANGE does cover both permission and timestamp modifications. However, when combined with the temporal inversion ($SI Created 9 months before $FN Created) and the zero fractional seconds, the conclusion is unambiguous. The USN entry provides the real time of the modification; the $SI/$FN comparison confirms what was modified.

Three independent detection methods all pointing to the same conclusion is not ambiguous. Temporal inversion alone is near-definitive (the only false positive is the tunnel cache, which produces seconds of difference, not months). Combined with zero-precision $SI and USN confirmation, this is the strongest classification available. Section 1.9 defines CONFIRMED as temporal inversion plus one or more corroborating methods.

$FN Modified and $FN Entry Modified can update on rename and move, but $FN Created is set once at file creation and is never updated by rename or move operations. A $FN Created of March 2026 means the file was created on this volume in March 2026. Section 1.3 covers $FN Created stability.

Small directories (under approximately 15-20 files) fit entirely in $INDEX_ROOT without $INDEX_ALLOCATION. NTFS only creates $INDEX_ALLOCATION when the directory grows beyond $INDEX_ROOT capacity. Section 1.5 covers the threshold.

When an MFT entry is reallocated, all attributes are rewritten. $INDEX_ALLOCATION on the current directory belongs to the current directory, not a previous occupant. The presence of $INDEX_ALLOCATION means this directory at some point contained enough files to require B-tree expansion.

While very long filenames do consume more space in $INDEX_ROOT, 3 files would need filenames of approximately 200+ characters each to overflow. This is possible but extremely unlikely. The far more common explanation is that the directory previously contained many more files.

Correct. NTFS only creates $INDEX_ALLOCATION when a directory exceeds approximately 15-20 files. A directory with 3 files and $INDEX_ALLOCATION once held many more. The deleted entries' $FILE_NAME structures persist in $I30 slack until overwritten by new insertions. Use MFTECmd with --de or INDXParse to carve these entries. Section 1.5 covers $I30 slack analysis.

Hard links do share the same MFT entry, but "REPORT~1.DOC" is a DOS 8.3 short name format (uppercase, tilde, 8.3 structure). If these were hard links, both names would be in Win32 format. The naming pattern identifies this as the automatic Win32 + DOS name pairing, not hard links.

Correct. NTFS creates both a Win32 long name and a DOS-compatible 8.3 short name when the long name exceeds 8.3 format requirements. Each name is a separate $FN attribute in the MFT record. MFTECmd outputs one row per $FN attribute. When counting unique files, use distinct EntryNumber values, not total row count. Section 1.3 covers namespace flags and multiple $FN attributes.

Both rows show InUse = True with the same sequence number, meaning they are current attributes of the same active file, not historical versions. A rename would update the $FN attribute in place, not create a second one alongside the old name.

This is correct, expected behavior from MFTECmd. The tool outputs one row per $FILE_NAME attribute by design, because each $FN attribute has its own set of timestamps that may differ. Both rows provide forensically relevant data.

The entry number matches but the sequence number does not. The $FN reference says sequence 3, but entry 500 currently has sequence 5. This means entry 500 has been deallocated and reallocated twice since the file's parent reference was created. The current "Projects" directory is a different directory that happened to reuse the same MFT slot.

Flags 0x03 means the entry is an active directory (0x01 = in use, 0x02 = directory, 0x03 = both). The flags indicate the entry is currently in use as a directory. The issue is the sequence number mismatch, not the allocation status.

Correct. The sequence number mismatch (referenced 3 vs current 5) proves the file's parent directory was deleted and the entry reused. MFTECmd resolves parent paths by looking up the entry number without always validating the sequence, so it resolved to "Projects" (the current occupant) instead of the original directory that occupied entry 500 at sequence 3. Section 1.6 covers stale reference detection through sequence number verification.

You can determine the path is wrong from the sequence number mismatch alone. The USN Journal would help you find the original directory name, but the mismatch itself is sufficient to identify the error. Always check sequence numbers on parent references for critical evidence files.

Correct. The five-element documentation framework from Section 1.10 establishes the recovery's reliability and preempts challenges. Source identifies the record. Method explains the extraction. Integrity proves the data is authentic. Confidence rates the reliability. Limitations acknowledge what the evidence does not prove. This level of documentation withstands cross-examination.

This is insufficient. It does not specify which MFT entry, how the content was extracted (MFTECmd does not export resident content in standard CSV output), how integrity was verified, or what the recovery's limitations are. Opposing counsel would challenge every undocumented aspect.

This describes what was done but not why the result should be trusted. It lacks hash verification, integrity assessment, and confidence rating. A court requires methodology documentation that establishes the reliability of the evidence, not just a description of the extraction.

Deleted file recovery is routinely accepted in court proceedings. The chain of custody applies to the evidence media (the disk image or MFT extraction), not to individual files. The forensic methodology documentation establishes that the recovered data is authentic and unmodified. Deleted file recovery is a standard forensic technique with decades of legal precedent.