Application in ScreenSharing

Analyzing the USN Journal is essential for uncovering hidden activities and confirming file operations:

• Tracking File Lifecycles: See the exact sequence of events for a file: when it was created, potentially renamed (logging both old and new names), modified (content changes via DATA_OVERWRITE/EXTEND, attribute changes via BASIC_INFO_CHANGE), and finally deleted (FILE_DELETE). This is critical for reconstructing the history of suspicious files.

• Detecting Deletions: Provides definitive proof of file deletion, including the exact time. Essential for confirming the removal of cheats, logs (.log), Prefetch files (.pf), macros (.xml, .json, specific extensions), or any other suspicious item shortly before or during the screenshare.

• Finding Renamed Files: Identifies if a suspicious file (e.g., cheat.exe) was renamed to something innocuous (e.g., notes.txt). Look for pairs of RENAME_OLD_NAME and RENAME_NEW_NAME events with matching timestamps and FRNs but different filenames.

• Identifying Attribute Manipulation: The BASIC_INFO_CHANGE reason code is crucial for detecting:

  • Timestomping Attempts: Altering file timestamps generates this event.

  • Read-Only Attribute Bypass: Applying the Read-Only attribute to artifacts like Prefetch files (.pf) to prevent timestamp updates also triggers this event. Finding BASIC_INFO_CHANGE on .pf files is highly suspicious.

• Tracking Data Modification: Events like DATA_OVERWRITE or DATA_EXTEND indicate changes to file content, potentially correlating with hex editing or saving configuration changes within cheats.

• Detecting JnativeHook Usage: Seeing JnativeHook*.dll files being created (FILE_CREATE) and subsequently deleted (FILE_DELETE) in the %temp% directory via Journal analysis is a strong indicator of certain Java-based autoclickers being executed.

• Verifying Claims/Corroborating Evidence: Use the Journal to confirm or refute findings from other tools. If LastActivityView shows a recent file access but the file is now gone, the Journal should ideally show the corresponding FILE_DELETE event.