$LogFile Forensics Cheat Sheet

What it is

$LogFile is the NTFS transaction journal. Before NTFS changes its own metadata (MFT records, directory indexes, the cluster bitmap), it writes a log record describing the change so that the volume can be brought back to a consistent state after a crash. Each record carries a redo operation (how to re-apply the change) and an undo operation (how to roll it back), often with the raw bytes before and after. That makes $LogFile a microscope on the last minutes or hours of file-system activity, including values that have since been overwritten in the $MFT.

Location

Windows version	Path	Notes
XP to 11 (every NTFS volume)	`<volume root>\$LogFile`	MFT record 2; hidden system file, locked while mounted
Windows 8 and later	Same	Log File Service (LFS) version 2.0 while the volume is in use; by default downgraded to 1.1 at clean shutdown. Some older parsers only understand 1.1

Size: typically 64 MB (chkdsk reports 65,536 KB) on modern Windows volumes. It can be changed with chkdsk <volume> /L:<size in KB>, and chkdsk C: /L shows the current size.

What it proves

Recent metadata operations: file and folder creation, deletion, rename and move, attribute creation and removal, resident data writes, index entry additions and removals.
Before and after values: undo data can hold the previous $STANDARD_INFORMATION timestamps of a file whose times were changed, which can expose timestomping and give the original values.
Resident content: small files and alternate data streams written into MFT records can appear in redo data.
It does not log user file content for non-resident files, who performed an action, or anything older than the circular buffer covers.

Key fields

Field	Meaning
`RSTR` pages	Two restart pages at the start of the file (4 KB each, the second is a copy): current LSN, client list, where to start recovery
`RCRD` pages	4 KB log record pages in the circular logging area
LSN	Log Sequence Number of the record; also stored in the header of each MFT record
Previous LSN / Undo-next LSN	Chain records of one transaction together
Redo operation	Action applied, for example `InitializeFileRecordSegment`, `AddIndexEntryAllocation`, `UpdateResidentValue`, `DeallocateFileRecordSegment`, `DeleteIndexEntryAllocation`, `SetBitsInNonresidentBitMap`
Undo operation	The inverse action
Target	MFT record number / VCN and attribute offset the operation applies to
Redo / undo data	Raw bytes: a full new FILE record, a `$FILE_NAME` index entry, or the changed part of `$STANDARD_INFORMATION`

A file rename, for instance, appears as a sequence of operations on the parent index (delete the old entry, add the new one) and on the file record (remove and recreate the $FILE_NAME attribute).

Timestamps

Timestamp	Set when	Format	Pitfalls
None per log record	-	-	Log records have no time field of their own; timing is inferred
`$SI` / `$FN` values inside redo or undo data	Copied from the attribute being changed	FILETIME, UTC	These are file timestamps, not the time the record was logged; for timestomping they may be the attacker's chosen value
Ordering by LSN	LSNs increase with every record	64-bit number	Gives a reliable sequence; anchor it to clock time via USN journal records for the same files

Retention and clearing

The logging area is circular: once full, new records overwrite the oldest. On a busy system drive this may be minutes to a few hours; researcher tests on Windows 10 measured anywhere from 16 minutes to over 5 hours before old data was overwritten. A larger log or a quieter secondary volume keeps more.
Collect it as early as possible in the response: every action on a live system, including your own tools, pushes older records out.
Older log pages can survive in volume shadow copies and memory, and RCRD pages can be carved from unallocated space.
Resizing the log with chkdsk /L or reformatting destroys its content; there is no user-facing command to clear it otherwise.

Collection

KAPE target: $LogFile (also part of FileSystem)
Velociraptor (Windows.Triage.Targets): $LogFile
Built-in: the file is locked and not readable through the Windows API; use a raw-NTFS collector or a disk image. Only the size can be checked natively:

chkdsk C: /L
fsutil fsinfo ntfsinfo C:

Always collect $LogFile together with the $MFT and $J of the same volume so records can be resolved to paths and times.

Parsing tools

LogFileParser (Joakim Schicht, open source): decodes redo/undo operations and attribute changes into CSV and an SQLite database, rebuilds data runs, recovers transactions from slack and can import mft2csv output for path resolution. Very detailed and low level.
NTFS Log Tracker (Junghoon Oh, free): parses $LogFile (including LFS 2.0 on Windows 10), $UsnJrnl:$J and $MFT into SQLite and summarises file create, delete and rename events.
dfir_ntfs (Maxim Suhanov, open source): ntfs_parser --log <$MFT> <$LogFile> out.txt dumps decoded log records.
MFTECmd does not parse $LogFile at the time of writing; use it for the $MFT and $J you correlate with.

Investigation tips

Use $LogFile to validate a suspected timestomp: an UpdateResidentValue on $STANDARD_INFORMATION whose undo data holds recent times and whose redo data holds old times shows the change and the original values. Pair it with the BasicInfoChange record in the USN journal.
For mass deletions (wipers, ransomware cleanup), DeallocateFileRecordSegment and index-entry deletions list files even if their $MFT records were reused minutes later.
Look for resident data in redo records to recover small scripts or notes that were created and deleted quickly.
Compare the LSN in each MFT record header with the log range present: files touched most recently have LSNs inside the log.
If the log covers only a few minutes, say so in the report; absence of an operation in $LogFile says nothing about older activity.
See $I30 index and the $STANDARD_INFORMATION vs $FILE_NAME entry for the other timestamp copies you can compare against.

$LogFile (NTFS transaction log)

Tools