Skip to content

LogFileParser

NTFS transaction analysis

Follow a filesystem change back to its evidence

A filename is a starting point. Use LogFileParser to examine the transaction records behind a change, then test the explanation against other artefacts.

Try the browser investigationFollow the tool workflow

What you will learn

Prepare

Identify the source volume, protect the original and record the parser settings.

Examine

Follow file references and log sequence numbers across the exported records.

Explain

Separate a supported change from a claim about a person, intent or missing activity.

Understand the evidence first

NTFS uses $LogFile to support filesystem recovery after interrupted operations. It is a circular transaction log: retained records depend on subsequent volume activity and log reuse. It is not a complete audit of everything a user did.

Preserved $LogFileDecoded transactionsCorroborated finding

The moving highlight illustrates the examination workflow, not a live acquisition. Motion stops when reduced motion is enabled.

Evidence What it contributes What to check
$LogFile Low level operations, redo/undo data and retained metadata Coverage, incomplete records, slack and decoding warnings
$MFT / Mft2Csv output File references, sequence numbers and name context Same volume and acquisition context; references can be reused
$UsnJrnl:$J Change journal reasons and timestamps for corroboration Matching reference and sequence, coverage and time basis

An LSN (log sequence number) helps follow records in the log. It is not a clock time. Redo and undo describe recovery data; an undo field does not prove that a user reversed an action. Metadata timestamps decoded from an attribute are not automatically the time of its transaction.

Accessing LogFileParser in SUSA

LogFileParser (by Joakim Schicht) is a tool that parses the NTFS $LogFile and converts it into a readable format (usually CSV) so you can analyse low level file system activity.

Analyse a preserved copy from the same volume as the related $MFT and $UsnJrnl. Record the parser version and output location, and use transaction records to support a timeline rather than treating an individual row as a complete account of user intent.

Download LogFileParser and extract to C:\Tools\JoakimSchichtTools\LogFileParser.

Double click LogFileParser64 to launch the application.

Before the first run

  1. Keep the extracted package together, including its supplied libraries. Use a writable tool directory without spaces, such as the path above. The 2.0.0.53 release warns about spaces in its program path.
  2. Record the downloaded package, release, architecture, source URL and executable SHA-256. Use Get-FileHash -Algorithm SHA256 in PowerShell and retain the result in your case notes.
  3. Work on an extracted copy of $LogFile, not the original exhibit. Obtain the file with an appropriate forensic acquisition or filesystem extraction tool; selecting a disk image in this parser is not equivalent to extracting $LogFile.
  4. Record the source volume's geometry and operating system context. The screenshot's 8 sectors per cluster and 1024-byte MFT records are settings to verify, not values to assume for every volume.
  5. Plan output storage. In the GUI workflow, the parser creates a LogFile_YYYY-MM-DD_HH-MM-SS folder beneath its executable directory. Preserve the whole run directory, including debug.log, before another analysis or cleanup.

A first run with a clear boundary

Use a complete, verified training $LogFile. Leave fragment, broken file and reconstruction options off until there is a reason to use them. Start with one question, such as whether two names refer to the same file record instance.

Choose your next step

01Parse and review

Configure the GUI, locate the output, and follow a file reference through the records.

Finish with an observation linked to its source and limitations.02Hands on labs

Practise a rename investigation in the browser, then repeat the method with authorised evidence.

Choose the route that suits your resources.

Sources and version notes

This guide uses the supplied 2.0.0.53 screenshot and the author's source code, README and release notes. Older README limitations should be checked against the release used: later releases expanded resident data decoding and output schemas. Record your actual version and headers instead of assuming identical output.