NTFS Artifact Analysis practice questions

$DATA and $BITMAP

Why it fails: The $DATA attribute contains the actual file content, while the $BITMAP tracks cluster allocation. Neither of these attributes stores timestamps used for forensic timeline analysis, so relying on them for detecting timestomping would be ineffective as they do not provide the metadata fields necessary for verifying file system time history.

$ATTRIBUTE_LIST and $EA

Why it fails: $ATTRIBUTE_LIST is used when a file has too many attributes for a single MFT record, and $EA stores extended attributes. These are structural components of the MFT and do not serve as the primary source for the standard MACE (Modified, Accessed, Created, Entry Modified) timestamps used in forensic investigations.

$STANDARD_INFORMATION and $DATA

Why it fails: While $STANDARD_INFORMATION contains timestamps, the $DATA attribute is reserved for the file's primary stream content. Since $DATA lacks timestamps, this combination fails to provide the necessary metadata comparison required to detect timestomping, as you would have no reference point to validate the accuracy of the $STANDARD_INFORMATION timestamp values.

$FILE_NAME and $VOLUME_INFORMATION

Why it fails: $FILE_NAME contains timestamps, but $VOLUME_INFORMATION is a metadata file describing the volume itself, not individual files. This pair does not provide the required contrast between user-accessible metadata and system-level metadata, making it impossible to effectively identify malicious timestamp tampering or unauthorized modifications to file metadata values.

Cluster Bitmap

Why it fails: The Cluster Bitmap is a system-wide file ($Bitmap) that tracks the allocation of clusters across the entire partition. It is not part of an individual MFT record, as it serves as a global management structure rather than a localized field within the entry of a specific file.

Volume Boot Record

Why it fails: The Volume Boot Record (VBR) is located at the very beginning of the partition and contains boot code and BIOS parameters. It is an entirely separate structure from the MFT records, and including it as a component of an MFT entry is a fundamental error in understanding NTFS structure.

$DATA

Why it fails: The $DATA attribute contains the actual content of the file. It does not store the file name or directory structure. While it is necessary for file recovery, it provides zero information regarding the file's naming conventions or its position within the folder hierarchy on the volume.

$INDEX_ROOT

Why it fails: $INDEX_ROOT is used for directory entries to facilitate fast searching of file names within a folder. While it maps names, it does not store the file name metadata for an individual file record itself, making it an ineffective tool for recovering the specific metadata of a deleted file.

$VOLUME_NAME

Why it fails: The $VOLUME_NAME attribute is a metadata field located in the $Volume file that stores the label of the disk partition. It has absolutely no relationship to individual file names or directory structures, and it cannot assist in the forensic recovery of deleted file metadata.

Data Run Offsets

Why it fails: Data run offsets are stored in the $DATA attribute, which manages the physical cluster locations on the disk. Including them in the $STANDARD_INFORMATION attribute is incorrect, as this attribute is strictly for metadata describing file properties, not for mapping the physical storage locations of file content.

Directory Index Key

Why it fails: The Directory Index Key is associated with the $INDEX_ROOT and $INDEX_ALLOCATION attributes, which manage directory organization. The $STANDARD_INFORMATION attribute does not play a role in indexing, as its focus is on individual file metadata rather than the hierarchical structure of the NTFS volume.

The file is encrypted using BitLocker.

Why it fails: BitLocker encryption operates at the volume level rather than the attribute level. Encrypted files still maintain valid $DATA attributes, though the content is ciphertext. A missing $DATA attribute is a functional indicator of file deletion or metadata corruption, not a standard characteristic of disk-level volume encryption mechanisms.

The file is a compressed sparse file.

Why it fails: Sparse files utilize the $DATA attribute to store data runs, even if large portions are allocated as zero-length. While compression changes how data is stored on disk, the $DATA attribute structure remains intact. The absence of the attribute signifies a metadata-level deletion event, not a storage optimization.

The file is a hard link to another file.

Why it fails: Hard links share the same MFT record and file ID. They essentially point to the same $DATA attribute. If a file were a hard link, the $DATA attribute would remain present because the underlying data is still referenced by other directory entries pointing to that same MFT record.

$DATA and $ATTRIBUTE_LIST

Why it fails: $DATA contains the actual content of the file, not timestamps. $ATTRIBUTE_LIST is used when an MFT record is too small to contain all attributes, requiring an extension to other MFT records. Neither of these attributes acts as the primary authority for file system temporal metadata or MACB timing.

$STANDARD_INFORMATION and $DATA

Why it fails: $DATA is intended for file payload storage, not temporal attributes. While $SI is correct, the inclusion of $DATA makes this pair incorrect. Forensic analysts rely on the $FN attribute's internal system timestamps, not the file payload, to verify the integrity of the temporal data provided by $SI.

$FILE_NAME and $INDEX_ROOT

Why it fails: $INDEX_ROOT is an attribute associated with directories, not individual files, and does not store file-level MACB timestamps. While $FN is correct, the inclusion of $INDEX_ROOT invalidates the pair. $INDEX_ROOT is primarily used to manage the B-tree structure of files contained within a specific directory folder.

$LOGGED_UTILITY_STREAM and $STANDARD_INFORMATION

Why it fails: $LOGGED_UTILITY_STREAM is used for EFS encryption metadata and is not involved in standard file timestamping. While $SI is relevant, the pairing is incorrect. Analysts must focus on $FN as the secondary, kernel-controlled timestamp source to reliably detect modifications made to the $SI timestamps by malicious software.

The file system is corrupted and requires chkdsk.

Why it fails: Timestamp discrepancies between $SI and $FN attributes are a common result of deliberate manipulation rather than file system corruption. Chkdsk addresses structural inconsistencies like broken B-trees or cross-linked clusters, but it does not evaluate the temporal integrity of MFT metadata attributes for forensic timeline analysis purposes.

The file was recently moved to a new volume.

Why it fails: Moving a file across volumes effectively creates a new file object. While timestamps change, the $SI and $FN attributes typically align shortly after the operation completes. A specific discrepancy where $SI is earlier than $FN is a classic signature of manual metadata alteration, not a standard file movement.

The file was created using a non-Windows utility.

Why it fails: Third-party utilities still interface with the NTFS driver, which enforces standard attribute updates. Regardless of how a file is created, the system kernel ensures that $FN and $SI metadata remain synchronized unless an external tool explicitly bypasses these standard APIs to modify the MFT record attributes.

$UserActivity

Why it fails: $UserActivity is not a valid NTFS system file. While Windows keeps track of user activity through various logs like the USN Journal or Event Logs, there is no system file named $UserActivity within the MFT. This is a distractor designed to test knowledge of reserved NTFS file names.

$Registry

Why it fails: The Windows Registry is stored in files like NTUSER.DAT or the SYSTEM/SOFTWARE hives, which are stored as regular files in the filesystem. While they are critical, they are not reserved NTFS system files with a '$' prefix defined within the first 16 records of the MFT structure.

Data Run Offsets

Why it fails: Data runs are stored in the $DATA attribute, not in $SI. $SI is strictly for metadata describing the file's temporal and security properties. Storing data runs in $SI would violate the modular design of NTFS, which separates metadata from data content to optimize MFT record space.

Parent Directory ID

Why it fails: The parent directory ID is stored in the $FILE_NAME attribute, not the $STANDARD_INFORMATION attribute. This information is needed to build the directory tree path, but it is not part of the standard metadata attributes provided by the $SI stream, which focuses on user-level file properties.

The file is an active, read-only system file.

Why it fails: An active file would have a flag of 0x01. A flag of 0x00 indicates the record is marked as free. Furthermore, active files must have a $DATA attribute to store their content. A deleted file lacks this, as the pointer to the cluster run has been removed.

The file is currently being accessed by a process.

Why it fails: If a file were being accessed, the flags would be 0x01 (In Use), and the $DATA attribute would be populated to allow for reading or writing. A free record (0x00) signifies that the OS considers this space available for new file metadata to be stored.

The file is a directory that is empty.

Why it fails: Directories have specific flags and attributes (like $INDEX_ROOT) that differ from file records. An empty directory would still be marked as 'in use' (0x01) and contain an $INDEX_ROOT attribute. The 0x00 flag and missing $DATA attribute specifically describe a deleted file, not an empty directory.

The $FILE_NAME attribute contains a namespace value of 2 (Win32 & DOS).

Why it fails: The namespace value in $FILE_NAME indicates the type of name (POSIX, Win32, DOS, or Win32 & DOS) and is not related to allocation status. A namespace of 2 simply means the file has both a Win32 and a DOS name. This field remains in the record after deletion but does not indicate that the entry is free.

The record's $DATA attribute is non-resident and its allocated size is zero.

Why it fails: A non-resident $DATA attribute with zero allocated size could occur for sparse files or when data runs are not yet allocated, but it does not by itself indicate deletion. Deleted files may still have data runs until clusters are reallocated. This condition is not a reliable deletion indicator and could describe a valid, in-use file.

The $STANDARD_INFORMATION attribute's MFT change time ($MFT Modified) is later than the $FILE_NAME attribute's creation timestamp.

Why it fails: A discrepancy between $STANDARD_INFORMATION and $FILE_NAME timestamps can indicate timestomping or normal system activity, but it does not indicate deletion. Deletion is reflected in the MFT record header, not in timestamp inconsistencies. Relying on this would mislead the investigation because many legitimate operations (e.g., file renaming) can cause such differences.

The file was created on 2023-08-10, and the $FILE_NAME timestamps were not updated due to a file system bug.

Why it fails: NTFS updates $FILE_NAME timestamps during file creation, so a bug that leaves them a month behind is highly unlikely. The $FILE_NAME attribute is maintained by the file system kernel and is not subject to the same user-mode modification as $STANDARD_INFORMATION. This explanation fails to account for the systematic difference.

The file was copied from an external drive on 2023-08-10, preserving the original $FILE_NAME timestamps from the source.

Why it fails: When a file is copied within NTFS, a new MFT entry is created, and both $STANDARD_INFORMATION and $FILE_NAME timestamps are set to the copy time. The source timestamps are not preserved in $FILE_NAME. This scenario would result in both attribute sets reflecting the copy time, not a month apart.

The file was created on 2023-07-01, and the $STANDARD_INFORMATION timestamps were updated on 2023-08-10 by a legitimate application that modifies file metadata.

Why it fails: Legitimate applications rarely modify all four $STANDARD_INFORMATION timestamps simultaneously to a uniform value. Normal file access updates only the access time, and modifications update the modification time. A complete reset of all timestamps is a hallmark of timestomping, not typical application behavior.

The file was moved from a different volume, and NTFS preserved the original $FILE_NAME timestamps while updating $STANDARD_INFORMATION on the new volume.

Why it fails: When a file is moved within the same volume, timestamps are preserved. When moved across volumes, the file is copied and deleted, so timestamps are updated. The creation later than modification is not typical for cross-volume moves; it suggests timestomping or system clock changes.

The file was created on a POSIX-compliant system, which does not update the $STANDARD_INFORMATION timestamps correctly.

Why it fails: NTFS timestamps are updated by the Windows kernel regardless of the originating file system. POSIX namespace only affects filename display and case sensitivity; it does not prevent timestamp updates. The discrepancy is not caused by POSIX compliance, but by deliberate manipulation or system behavior.

The file's timestamps were modified using a tool that only updates the $FILE_NAME timestamps, leaving the $STANDARD_INFORMATION timestamps inconsistent.

Why it fails: Timestomping tools typically target $STANDARD_INFORMATION because it is easily accessible via API. However, the scenario states that $STANDARD_INFORMATION shows creation later than modification, which is a classic sign of timestomping on $STANDARD_INFORMATION itself, not $FILE_NAME. The $FILE_NAME timestamps are usually not updated by such tools.

The $DATA attribute's allocated size, because timestomping changes the file's logical size

Why it fails: Timestomping modifies timestamps, not the file's logical or allocated size. The $DATA attribute's allocated size reflects how much disk space the file content occupies, and it remains unchanged when timestamps are altered. Therefore, it cannot provide evidence of timestamp manipulation.

The $SECURITY_DESCRIPTOR attribute, because timestomping requires privilege escalation

Why it fails: The $SECURITY_DESCRIPTOR attribute stores the security descriptor for the file, including owner and access control entries. While privilege escalation may be involved in some attacks, timestomping itself does not modify the security descriptor, so this attribute does not record evidence of timestamp changes.

The $LOGGED_UTILITY_STREAM attribute, because it records all timestamp modifications

Why it fails: The $LOGGED_UTILITY_STREAM attribute stores data for EFS encryption and is not used to log timestamp changes. NTFS does not maintain a dedicated log of timestamp modifications in this attribute, so it cannot be used to detect timestomping in this scenario.

The file was copied from another NTFS volume, and the $FILE_NAME timestamps reflect the original creation time.

Why it fails: Copying a file typically updates the $STANDARD_INFORMATION timestamps to the time of the copy operation, while $FILE_NAME timestamps may retain the original creation time from the source volume. However, the scenario shows a difference in Modified times, not Creation times, and the file is not described as copied. This explanation does not account for the specific timestamps shown.

The file was renamed, causing the $FILE_NAME timestamps to be updated while $STANDARD_INFORMATION remained unchanged.

Why it fails: Renaming a file updates the $FILE_NAME timestamps to the time of the rename operation, but it also typically updates the $STANDARD_INFORMATION timestamps. The scenario shows $STANDARD_INFORMATION Modified time is later than $FILE_NAME Modified time, which could occur if the file was renamed after its last modification, but the question asks for the most likely explanation given the specific discrepancy. This is plausible but not the most direct explanation.

The $FILE_NAME timestamps were updated by a timestomping tool that only modified $STANDARD_INFORMATION.

Why it fails: Timestomping tools often modify $STANDARD_INFORMATION timestamps but may leave $FILE_NAME timestamps untouched. However, the scenario shows $STANDARD_INFORMATION Modified time is later than $FILE_NAME Modified time, which is the opposite of typical timestomping where an attacker sets earlier timestamps in $STANDARD_INFORMATION. This explanation is inconsistent with the observed data.

The $MFT metadata file, which contains the security ID directly mapped to a username.

Why it fails: The $MFT contains the security ID in $STANDARD_INFORMATION, but it does not map that ID to a username. The mapping is stored in $Secure. The $MFT alone cannot resolve the security ID to a user account; additional metadata is required.

The $UsnJrnl metadata file, which records security ID changes for each file.

Why it fails: $UsnJrnl records change journal entries for files, including reasons for changes, but it does not store security IDs or map them to user accounts. Security ID mapping is handled by $Secure. This option confuses the roles of $UsnJrnl and $Secure.

The $LogFile metadata file, which logs security descriptor changes and can be replayed to find the user.

Why it fails: $LogFile records metadata transactions for recovery purposes, but it does not provide a direct mapping of security IDs to user accounts. While it may contain security descriptor changes, resolving the ID requires $Secure. This option overstates the role of $LogFile.

The MFT entry is a base record for a directory, and the $BITMAP attribute tracks which index entries are in use within the directory's $INDEX_ALLOCATION.

Why it fails: A directory's MFT record would contain $INDEX_ROOT and typically $INDEX_ALLOCATION, and its $BITMAP attribute would indeed track index allocation usage. However, the presence of a non-resident $DATA attribute is not typical for a directory, since directories store index data rather than file content in $DATA. The combination described points away from a simple directory record.

The MFT entry is a base record for a compressed file, and the $BITMAP attribute tracks which compression units have been successfully compressed.

Why it fails: NTFS compression is indicated by the compressed flag in the $STANDARD_INFORMATION attribute and by sparse runs in the $DATA runlist. There is no per-file $BITMAP attribute in the MFT record that tracks compression units. Compression state is managed through the file's attribute flags and runlist encoding, not through an MFT-resident $BITMAP.

The MFT entry is a base record for a sparse file, and the $BITMAP attribute tracks which clusters within the file are allocated versus sparse.

Why it fails: Sparse files use the $DATA attribute's runlist with sparse runs, but NTFS does not store a $BITMAP attribute within the MFT record to track sparse clusters. Sparse allocation is represented in the data runs themselves, not via an MFT $BITMAP attribute. The presence of $BITMAP in an MFT record is associated with index or extension record usage, not sparse file tracking.

The $OBJECT_ID attribute, which stores a unique identifier that can be linked to the file's original path via the $ObjId index.

Why it fails: $OBJECT_ID is an optional attribute that stores a GUID for the file, used by the distributed link tracking service. While it can help track file movements across volumes, it does not directly store the original path. It requires additional correlation with other artifacts.

The $STANDARD_INFORMATION attribute, which records the file's creation, modification, and access timestamps.

Why it fails: $STANDARD_INFORMATION contains timestamps and flags but does not store any path or directory information. It cannot indicate the original location of a file. Timestamps might help infer when a move occurred, but they do not provide the path itself.

The $INDEX_ROOT attribute, which contains the directory index for the file's current parent directory.

Why it fails: $INDEX_ROOT is an attribute of directory MFT entries that stores the B-tree index of files within that directory. It does not belong to the file's own MFT entry and does not record the file's original path. It only reflects the current directory structure.

The file was created on a FAT file system and later converted to NTFS, which preserved the invalid timestamp.

Why it fails: FAT file systems do not support timestamps before 1980, and conversion to NTFS typically sets valid timestamps. An invalid timestamp like year 1601 is not a result of FAT conversion; it is more likely due to corruption or deliberate manipulation.

The file was accessed by a legacy application that does not support modern timestamps, causing NTFS to revert to the epoch.

Why it fails: Legacy applications do not cause NTFS to revert timestamps to the epoch. The file system manages timestamps independently of application support. An epoch timestamp is not a normal outcome of application access; it suggests deliberate alteration or corruption.

The file is a system file, and NTFS uses a special timestamp format for system files that can include year 1601.

Why it fails: NTFS does not use a special timestamp format for system files. All files use the same 64-bit FILETIME structure, which represents the number of 100-nanosecond intervals since January 1, 1601. A timestamp of exactly 1601 is the zero value, which is invalid for a real file and indicates manipulation or corruption.

The $MFT record's $STANDARD_INFORMATION attribute change time

Why it fails: The $STANDARD_INFORMATION change time (MFT entry modified time) can be manipulated by timestomping tools, just like other timestamps in that attribute. It is not a reliable independent source to corroborate the true creation time. While it may show a later time, it is still part of the same attribute that was likely altered, so it cannot be trusted as a corroborating artifact.

The $MFT record's $STANDARD_INFORMATION MFT entry modified time

Why it fails: The MFT entry modified time is part of $STANDARD_INFORMATION and is often targeted by timestomping tools. It is not a separate, protected artifact. While it might show a later time, it can be set arbitrarily. Therefore, it does not provide an independent corroboration of the true creation time. Investigators should look for artifacts outside the MFT that record MFT changes.

The $FILE_NAME attribute's creation timestamp

Why it fails: The $FILE_NAME attribute timestamps are often not modified by timestomping tools, but they reflect the time the filename was created or modified in the directory index, not necessarily the file's true creation. In this scenario, the $FILE_NAME creation date is 2023, which aligns with the content, but it does not directly indicate when the MFT record was last modified. It is a useful comparison but not the artifact that records MFT record modification.