File Replacement (Replace Method)

• Description: A common bypass technique involving replacing a malicious file (the cheat) with a legitimate file that has the exact same filename. The goal is to deceive the ScreenSharer who might find execution traces pointing to a filename, but upon inspecting the file currently at that location, finds only a benign application.

• Mechanism: Typically involves these steps:

  1. The cheater has a cheat executable, e.g., MyClient.exe, in a specific location (e.g., Desktop).

  2. The cheater runs MyClient.exe. Execution artifacts (Prefetch, BAM, process memory strings) are created pointing to this file and path.

  3. Just before the screenshare freeze, the cheater deletes the actual cheat file MyClient.exe.

  4. Immediately afterwards, they move or copy a legitimate file (e.g., a renamed notepad.exe, calc.exe, or another harmless program) into the exact same location and rename it to the exact same name as the deleted cheat: MyClient.exe.

• Why Cheaters Use It: To create plausible deniability. When the ScreenSharer finds execution evidence for MyClient.exe (e.g., in Prefetch or BAM), they navigate to the path and find what appears to be MyClient.exe, but it's actually the benign replacement file. If the SSer only checks the current file's properties or content without cross-referencing timestamps or using deeper analysis, they might miss the switch.

• Detection: Detecting file replacement relies heavily on correlating evidence across multiple artifacts, particularly the USN Journal:

  • USN Journal ($UsnJrnl): This is the most definitive detection method. The Journal logs the entire sequence:

    1. A FILE_DELETE event for the original cheat file (MyClient.exe) at its location.

    2. Followed closely by FILE_CREATE and potentially RENAME_NEW_NAME events for the legitimate file being moved/copied/renamed into the same location with the same name (MyClient.exe). Specific reason codes might vary depending on whether it was a copy, move, or direct rename, but the sequence of delete followed by create/rename of the same filename at the same path within a short timeframe is the key pattern.

  • Timestamp Discrepancies (Prefetch/BAM vs. Current File): Compare the execution timestamp found in Prefetch or BAM for MyClient.exe with the file creation/modification timestamps of the MyClient.exe file currently present on disk. If the execution timestamp is significantly newer than the creation/modification time of the current file, it implies the file that was executed is not the file currently residing at that path.

  • Hash/Signature Mismatch: If the original cheat was unsigned or had a specific hash, and the replacement file is legitimate (e.g., signed notepad.exe), comparing the hash/signature of the current file against expectations based on execution logs can reveal the replacement.

  • DPS Compilation Timestamp: The Diagnostic Policy Service (DPS) sometimes logs the compilation timestamp embedded within an executable. If DPS logs show an execution trace for MyClient.exe with compilation timestamp A, but the MyClient.exe currently on disk has compilation timestamp B (verifiable via VirusTotal details or PE analysis tools), it proves a replacement occurred.

  • (Advanced) fsutil file queryFileNameById: If the USN Journal provides the File Reference Number (FRN) for the deleted cheat file, this fsutil command (if run quickly before the MFT record is reused) might potentially still resolve the original filename associated with that FRN, further confirming the deletion. (Reliability varies).

Successful detection of file replacement requires meticulous comparison of timestamps and filesystem event logs against execution artifacts.