Skip to content

LogFileParser Hands on Labs

Investigate a suspected rename, then explain what the evidence supports. Complete either route first.

Interactive Lab

Browser based

LogFileParser Interactive Lab

No installation

The interactive parser requires JavaScript. You can still follow the complete real tool Full Lab below.

Full Lab

Self hosted

LogFileParser Full Lab

Windows VM and authorised evidence required

Hands on Proof of Concept

Rename it. Trace it. Test it.

Can you support a rename from draft-budget.txt to approved-budget.txt using NTFS evidence? Build a harmless scenario, preserve the source, and compare your finding with an independent activity log.

Start the Full Lab

Before you begin

Use a disposable Windows VM with a snapshot, a dedicated NTFS test volume, a separate evidence destination, LogFileParser, and an acquisition tool such as FTK Imager. Use harmless files on a volume you control. Do not experiment on your system volume.

What success looks like

A preserved source, reproducible settings, traceable candidate records, and a conclusion separating observation from inference. Missing records are a valid finding; never manufacture the browser lab's example rows.

Recommended first

Core investigation

Create one file, rename it once, and correlate $LogFile, $MFT and the USN journal when available.

Optional extension

Test a competing explanation

Create another file with the old name after the rename. Compare file references and sequence numbers: a matching name alone does not establish identity.

  1. Stage 1Preserve
  2. Stage 2Parse
  3. Stage 3Correlate

01

Activity 1: Create and preserve

  1. Record the snapshot, Windows version, volume identity, bytes per sector, sectors per cluster and MFT record size. Use the source geometry rather than copying defaults.
  2. On the dedicated test volume, create folder SUSA-LF-091 and harmless file draft-budget.txt. Record its contents and full path.
  3. Record UTC wall clock times in a separate activity log, then rename it to approved-budget.txt. Avoid unrelated volume activity.
  4. Promptly acquire the volume to the separate evidence destination using your acquisition tool's documented workflow. Preserve the image and verification record. Transaction history is circular and may be overwritten.
  5. Export $LogFile, $MFT, and $Extend\$UsnJrnl:$J if present from the image. Record original paths and extraction method. Keep preserved exports and hashed working copies separate. Do not enable or change a journal on an evidential source to make the lab work.

Checkpoint: every export has a recorded source and verified working copy. If metadata is inaccessible, resolve acquisition first; copying the renamed document is not a substitute.

02

Activity 2: Parse and find candidates

  1. Open LogFileParser and select the working $LogFile. Record the executable version and hash.
  2. Follow Parse and review: verify geometry, select UTC, record delimiter/encoding and precision, and leave recovery options off for the first complete file run.
  3. For optional name enrichment, parse the matching $MFT with Mft2Csv first. Get MFT csv accepts that CSV, not raw $MFT. Record whether enrichment was used.
  4. Click Start. Preserve the dated output directory beside the executable, including debug.log and produced exports. Review errors and hash retained outputs.
  5. Import exports with the configured separator. Keep identifiers and large LSN values as text. Search for both names; inspect file reference/sequence, operations, offsets, LSNs and slack/incomplete indicators. Use filename exports and main records together; not every row contains every field.
  6. Save candidate rows with their source export and row/offset references. Separate complete observations from recovered fragments.

Checkpoint: the search is reproducible. An LSN is not a wall clock time or proof of a user's action. If neither name survives, document that result and examine other artefacts; absence does not establish that no rename occurred.

03

Activity 3: Correlate and hand off

  1. Independently parse the USN export, for example with UsnJrnl2Csv. Look for RENAME_OLD_NAME and RENAME_NEW_NAME records with the same file reference and sequence. Record UTC timestamps and parent references when available.
  2. Compare the current $MFT record and acquisition context. A reused record number with a different sequence identifies a different file instance; names alone are insufficient.
  3. Compare with the separate activity log after forming your hypothesis. Explain missing records or clock uncertainty. Redo/undo operations do not directly establish user intent.
  4. Write a case note: source hashes; version/settings; exports and candidate references; observations; interpretation; limitations; next evidence needed. A rename does not establish who performed it or whether data left the system.
  5. Have a peer reproduce the search, or repeat it from your notes. Preserve the evidence package before reverting the VM snapshot.

Checkpoint: your case finding supports a bounded conclusion, including an inconclusive result where appropriate.

Evidence to keep

  • Source identity, acquisition record and verified hashes
  • Tool version, settings and geometry
  • Output directory and parser diagnostics
  • Candidate rows and independent corroboration
  • Case note with limitations and reproducible search