GCFA NTFS Artifact Analysis Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  The $UsnJrnl:$J alternate data stream, which logs USN_RECORD entries including RENAME_OLD_NAME and RENAME_NEW_NAME reasons.

  Why this is correct

  The USN change journal records file system events with reason flags such as RENAME_OLD_NAME and RENAME_NEW_NAME, and each record includes the filename at the time of the event. Querying $UsnJrnl:$J can reveal the prior name and the sequence of renames, which the $STANDARD_INFORMATION timestamps alone cannot show.

• ✗

  The $MFT's $FILE_NAME attribute, which stores a history of all previous names assigned to the file.

  Why it's wrong here

  The $FILE_NAME attribute stores the current name and its parent directory reference, not a historical list of prior names. While multiple $FILE_NAME attributes can exist for hard links, NTFS does not retain a rename history in the MFT, so previous names must be recovered from other sources such as the USN journal.

• ✗

  The $Secure:$SDS stream, which records security descriptor changes that occur during rename operations.

  Why it's wrong here

  The $Secure:$SDS stream stores security descriptors and is referenced by $SECURITY_DESCRIPTOR attributes; it does not track filenames or rename events. Changes to permissions may occur during a rename, but the stream itself contains no filename history, so it cannot answer the question of what the file was previously called.

• ✗

  The $LogFile, which contains redo and undo records for all metadata transactions including filename changes.

  Why it's wrong here

  The $LogFile is a write-ahead journal used for crash recovery; it records metadata transactions but is not designed for forensic querying of historical filenames. Its records are quickly overwritten and do not provide a user-friendly mapping of old to new names, making it unsuitable for determining who renamed a file.