A $LogFile Investigation Walkthrough (Fictional Case)

TL;DR. This case is fictional. It uses the synthetic $LogFile and $MFT shipped with the in-browser $LogFile parser (Try a sample). In 57 minutes of log, a rogue account svc_backup gets a profile, downloads tools.zip, unpacks m64.exe, moves it to \ProgramData\Intel and backdates it to 2019, drops rc.tmp and renames it rclone.exe, writes and deletes creds.txt, and leaves a .lnk to Payroll_2026.xlsx. The log proves the moves, the rewrite and the deletion with before/after values. It does not prove execution or exfiltration; those need other artifacts.

The story continues the one told across this family of parser sites: a finance workstation, a service-looking account that should not exist, and a payroll file that ended up on a USB drive. Every name, time and byte below is invented, and the log was generated from the published format, not captured from Windows.

The (fictional) situation

• Host: FIN-WKS-07, Windows 11, finance department.
• Trigger: a DLP alert about payroll data on removable media; an account named svc_backup that no one created on purpose.
• Question from the incident lead: "What did svc_backup do on this machine this morning, and what did it touch?"
• Collected (live, with KAPE, to an external drive): C:\$LogFile, C:\$MFT, C:\$Extend\$UsnJrnl:$J, Prefetch, registry hives, event logs. Collection method as in how to acquire the NTFS $LogFile.

First look at the log

The header line of the parser:

• LFS 2.0, not cleanly dismounted → captured live on Windows 8 or later (1.1 vs 2.0).
• 1 page taken from the fast-page area → the newest records existed only there.
• 100 records, LSN 115720 → 117880, no warnings.

A real system-volume log would be around 64 MiB with hundreds of thousands of records; the synthetic one is 256 KiB so that the story stays readable.

Timeline rebuilt from the log

Times are UTC, from the data in the records (column Time from). "≈" means borrowed from the nearest dated event.

Background noise was left out: SRUM database timestamp updates at 10:15 and 10:45, a temp file created and deleted in \Windows\Temp at 10:20.

Reading it phase by phase

First logon (09:58). Profile folders for svc_backup appear. The Recent folder under AppData is not in the surviving log — its records were overwritten — but the $MFT names it, which is why the .lnk later resolves to a full path. Without the $MFT, several paths would start with [MFT #n].

Toolkit (10:04–10:07). tools.zip lands in Downloads; a tools folder with m64.exe and readme.txt follows. The readme's text is resident, so its first bytes are visible in the log: it describes m64.exe as a "memory utility" to run as admin — a lead for a memory-dumping tool. A Prefetch file for 7ZFM.EXE is created at 10:07:03, consistent with 7-Zip's file manager being run around the extraction.

Hiding the binary (10:09). A new folder \ProgramData\Intel is created, m64.exe is moved into it, and then its $STANDARD_INFORMATION times are rewritten: before, created 10:06:52.3551871; after, all four times 2019-03-19 07:14:22.0000000. The parser lists four reasons — creation rewritten, values moved backwards, whole seconds, $SI created earlier than $FN created. The method and its false positives are in detecting timestomping. Here there is no extraction or restore at that moment, the target is an executable in a vendor-looking folder, and the change follows a deliberate move: a strong finding, to corroborate with the USN journal's BASIC_INFO_CHANGE for the true time.

Execution hint (10:12). M64.EXE-1C9E54B7.pf is created. Prefetch file creation is a strong hint that m64.exe ran; confirm by parsing the Prefetch file itself (Prefetch parser) for run count and times.

Staging exfiltration tooling (10:31). rc.tmp is dropped in \Users\Public and renamed rclone.exe fourteen seconds later. The rename is in the log with both names. Whether rclone ran and where it sent data are questions for Prefetch, Amcache (Amcache parser), SRUM network usage (SRUM parser) and proxy logs.

Credentials note (10:38). creds.txt is created on the Desktop, its content is written (resident, visible in the log: a share path and the account name, marked SYNTHETIC), modified at 10:38:27, then deleted. The deletion has no time of its own: "at or after 10:38:27". See recovering deleted-file evidence.

Payroll (10:47). A shortcut Payroll_2026.xlsx.lnk appears in Recent, i.e. the user opened a file of that name. Its target path and volume serial number are in the .lnk itself (LNK parser); in this story, it points to the USB drive E:.

What goes in the report

Write observations, not flags:

In the NTFS transaction log of volume C: (records LSN 116846 and 116951), the file \ProgramData\Intel\m64.exe (MFT entry 322) was moved from \Users\svc_backup\Downloads\tools\ and its $STANDARD_INFORMATION timestamps were changed from 2026-09-14 10:06:52 UTC (creation) to 2019-03-19 07:14:22 UTC for all four values. The log does not record the time of the change; it occurred after 10:09:40 UTC (move) and before the next dated event.

Cite LSNs, keep raw exports (CSV/JSON of the filtered events and their records), and state the tool and its limits: the parser used here is validated on synthetic data, so the same records should be confirmed with a second tool (parser comparison).

What the log could not answer

• Did rclone.exe run? Was data sent? Not a file-system metadata question.
• When exactly was m64.exe backdated or creds.txt deleted? USN journal.
• What happened before 09:58? Outside the log's window; USN journal and shadow copies go further back (limits of the $LogFile).
• Who was at the keyboard? Logon events, RDP artifacts (EVTX parser).

The $LogFile's contribution is narrow and strong: a precise, ordered account of metadata changes in the last hour, including values the other artifacts overwrite.

Related articles

• How to analyze an NTFS $LogFile, step by step
• Detecting timestomping with the NTFS $LogFile
• NTFS $LogFile forensics: the complete guide