$LogFile — NTFS Transaction Log

When an adversary modifies MFT timestamps, deletes files, or attempts to clean up their tracks on an NTFS volume, the filesystem’s own transaction journal silently records every metadata change they make. $LogFile is NTFS’s crash-recovery mechanism repurposed as a forensic artifact — a circular buffer that captures the before-and-after state of every MFT record modification, providing investigators with a recent-history replay of filesystem activity that survives most anti-forensics techniques.

What Is $LogFile?

$LogFile is the NTFS transaction log, a system metafile stored in the root of every NTFS volume at C:\$LogFile (inode 2 in the MFT). Its primary purpose is crash recovery: NTFS uses a write-ahead logging model where all metadata changes are first written to $LogFile before being committed to the MFT and other metadata structures. If the system crashes before the commit completes, the NTFS driver replays the log on the next mount to restore filesystem consistency.

From a forensic perspective, $LogFile contains redo and undo records for recent MFT changes. A redo record describes the change that was made. An undo record describes how to reverse the change. Together, these records provide a timeline of metadata modifications — including file creation, deletion, renaming, attribute changes, and timestomping.

$LogFile operates as a circular buffer, typically 64 MB in size. When the buffer is full, the oldest records are overwritten. On an active system, the effective retention window ranges from a few hours to several days depending on filesystem activity.

Location & Format

Internal Structure

$LogFile consists of two restart areas (at the beginning, for redundancy) and a logging area containing the circular buffer. Each log record contains a Log Sequence Number (LSN) that monotonically increases, providing strict ordering. Records contain operation codes specifying the metadata change type.

Record Types & Operation Codes

What $LogFile Reveals

• File creation events with full MFT records — When a file is created, the entire MFT record is logged, enabling recovery of files whose MFT entries have been overwritten.
• File deletion events — DeallocateFileRecordSegment operations record when MFT entries were freed, providing deletion timestamps.
• Timestamp modifications (timestomping) — UpdateResidentValue operations on $STANDARD_INFORMATION capture both new and original timestamps in the undo data.
• File renaming — Directory index additions and deletions record before and after file names.
• Directory lifecycle — Complete creation and deletion of directory structures is logged.
• Attribute changes — Changes to hidden, system, readonly attributes are recorded.

Forensic Use Cases

1. Timestomping Detection

An attacker sets their malware’s timestamps to match legitimate system files. The $MFT $STANDARD_INFORMATION shows the forged times. However, $LogFile contains an UpdateResidentValue record with the undo data showing the original timestamps and the redo data showing the forged timestamps. The LSN ordering proves the modification occurred after file creation.

2. Deleted Tool Recovery

An attacker drops a tool into C:\Windows\Temp\, executes it, then deletes it. The MFT entry may be reallocated. $LogFile’s InitializeFileRecordSegment record from creation contains the complete MFT record including file name, size, and timestamps — recoverable even after the MFT entry is overwritten.

3. Anti-Forensics Timeline Reconstruction

After a breach, the attacker ran a cleanup script deleting tools, logs, and Prefetch files. $LogFile contains DeallocateFileRecordSegment records for each deleted file and DeleteIndexEntryAllocation for directory removals. The LSN ordering reconstructs the exact cleanup sequence.

4. Ransomware Encryption Timeline

During ransomware encryption, $LogFile records MFT modifications for each encrypted file. If the 64 MB buffer encompasses the encryption start, LSN-ordered records reveal the sequence and timing, identifying the first encrypted file and encryption rate.

5. File Rename Tracking

When an attacker renames mimikatz.exe to svchost.exe, $LogFile records the directory index deletion for the original name and addition of the new name within the same transaction. The undo data preserves the original file name.

Acquisition Methods

:: Using KAPE (recommended for live systems)
kape.exe --tsource C: --tdest C:\Evidence --target NTFSFilesAndUSNJrnl

:: Using RawCopy (bypasses NTFS locks)
RawCopy.exe /FileNamePath:C:\$LogFile /OutputPath:C:\Evidence\

:: Using icat from The Sleuth Kit (from forensic image)
icat /dev/sdb1 2 > /analysis/ntfs/LogFile

:: Using FTK Imager (GUI)
:: Navigate to [root] - $LogFile - Right-click - Export

Parsing Tools & Analysis

:: Parse $LogFile with LogFileParser (Joakim Schicht)
LogFileParser.exe /LogFileFile:C:\Evidence\LogFile /OutputPath:C:\Analysis\ /OutputFormat:csv

:: Combined analysis workflow
:: 1. Parse $MFT for current state
MFTECmd.exe -f C:\Evidence\$MFT --csv C:\Analysis\

:: 2. Parse $UsnJrnl for change journal
MFTECmd.exe -f C:\Evidence\$UsnJrnl:$J --csv C:\Analysis\

:: 3. Parse $LogFile for redo/undo records
LogFileParser.exe /LogFileFile:C:\Evidence\$LogFile /OutputPath:C:\Analysis\

Retention & Persistence

Anti-Forensics Resilience

MITRE ATT&CK Detection Mapping

Related Artifacts & Cross-References

References

1. Joakim Schicht, “LogFileParser” — https://github.com/jschicht/LogFileParser
2. Junghoon Oh, “NTFS Log Tracker” — https://sites.google.com/site/aborntechhome/
3. Eric Zimmerman, “MFTECmd” — https://ericzimmerman.github.io/
4. SANS Institute, “NTFS Forensics: $LogFile and $UsnJrnl Analysis” — https://www.sans.org/blog/
5. Brian Carrier, “File System Forensic Analysis” — Addison-Wesley Professional
6. Microsoft, “How NTFS Works: Log File Service” — https://learn.microsoft.com