Forensic reconstruction of historical activity on a New Technology File System (NTFS) volume relies on the systematic analysis of specialized metadata structures and transactional journals to achieve high-fidelity timeline reconstruction of file and directory operations. This includes events such as creation, modification, access, attribute changes, renaming, movement, and deletion (including post-deletion artifacts). The cornerstone artifacts enabling this reconstruction are the Master File Table ($MFT), the Update Sequence Number Change Journal ($UsnJrnl), and the NTFS transactional $LogFile. Collectively known in the digital forensics community as the NTFS TriForce, these three components provide complementary layers of visibility. When correlated effectively, this triad enables investigators to construct detailed chronological narratives, detect anti-forensic techniques such as timestomping, recover evidence of deleted or relocated files, and reconstruct complex operational sequences that would otherwise remain obscured.
The Update Sequence Number (USN) Change Journal, commonly referred to as $UsnJrnl (or simply the Change Journal), serves as a persistent, high-fidelity audit mechanism within the NTFS file system. It systematically records a broad spectrum of file and directory operations—including creations, deletions, modifications, renames, attribute changes, security descriptor updates, and various reason-coded events—on a per-volume basis. Introduced with NTFS 3.0 in Windows 2000, the journal became enabled by default on system volumes starting with Windows Vista (and remains active in all subsequent Windows client and server editions). Beyond its native role in supporting Windows features such as Search Indexing, File Replication Service (FRS), and File History, the $UsnJrnl has emerged as a cornerstone artifact in modern digital forensics and incident response. It preserves chronological evidence of filesystem activity that often survives deletion, MFT record reuse, or basic timestomping attempts.
When analyzed in tandem with the NTFS $LogFile—which captures low-level transactional metadata operations (e.g., MFT record updates, index modifications, and atomic filesystem consistency changes)—the USN Journal provides a more comprehensive reconstruction of file-level events, including nuanced details about the sequence and nature of operations that might otherwise remain opaque.
Furthermore, the $UsnJrnl forms a foundational element of the well-established NTFS TriForce (sometimes extended to a “QuadLink” correlation incorporating the $MFT Mirror for integrity validation). This analytical triad—comprising the Master File Table (MFT) for current and residual metadata, the $LogFile for transactional depth, and the $UsnJrnl ($J alternate data stream) for high-level change logging—enables examiners to achieve granular reconstruction of system activity. Applications include:
- Timeline assembly across deleted or renamed files.
- Detection of anti-forensic techniques (e.g., timestomping via sequence number or timestamp discrepancies).
- Path reconstruction through parent MFT references
- Identification of ransomware staging, data exfiltration patterns, or lateral movement artifacts.
In advanced investigations, this TriForce approach significantly enhances the ability to uncover subtle filesystem behaviors and counter anti-forensic efforts, offering investigators a deeper, multi-layered understanding of what transpired on a Windows system.
$MFT
In the NTFS file system, every file and directory is represented by one or more entries (commonly called file records) in the Master File Table (MFT). These records encapsulate comprehensive metadata, including filenames, timestamps, security descriptors, and—depending on size—resident data or pointers to non-resident content. Each MFT entry begins with a fixed-size file record header (typically 42 bytes on modern Windows systems), which starts with a signature ("FILE" for valid records or "BAAD" for corrupted ones). The header contains critical forensic fields, notably:
- The $LogFile Sequence Number (LSN) — an 8-byte value referencing the most recent transaction in the NTFS $LogFile that affected this MFT entry. This field supports filesystem recovery and enables correlation with low-level metadata changes.
- The sequence number (2 bytes) — a counter that increments each time the MFT record is (re)allocated. When a file is deleted, and its record is later reused for a new file, the sequence number is incremented. This mechanism allows differentiation between successive "generations" of the same MFT slot and helps validate file references during path reconstruction or deletion analysis.
Following the header is a sequence of attributes, each with its own header (containing type ID, length, resident/non-resident flag, etc.) and content. The two most ubiquitous attributes are:
- $STANDARD_INFORMATION (0x10): Contains core metadata such as creation, modification, access, and MFT entry modification timestamps (MACE times), file attributes/flags, owner/security identifiers, and—on Windows 2000 and later—an 8-byte Update Sequence Number (USN) field. This USN serves as a direct reference to the most recent record in the $UsnJrnl ($J stream) associated with changes to this file or directory.
- $FILE_NAME (0x30): Stores the filename (in Unicode) along with its set of timestamps and a parent file reference. The parent reference is a 64-bit value comprising the 48-bit MFT entry number of the parent directory and its 16-bit sequence number. This structure is essential for reconstructing full file paths, even for deleted entries, by recursively resolving parent references.
Additional attributes (e.g., $DATA, $ATTRIBUTE_LIST for extension records, $OBJECT_ID, $SECURITY_DESCRIPTOR) may follow, depending on the file's characteristics. Hard-linked files will have multiple $FILE_NAME attributes. Because the MFT maintains an entry for virtually every file and directory that has existed on the volume, extracting and parsing the entire $MFT file from a forensic image yields a near-complete inventory of filesystem activity. When combined with the $LogFile (for transactional depth) and the $UsnJrnl (for high-level change logging), analysts can achieve detailed timeline reconstruction, detect anti-forensic techniques (such as timestomping), and recover evidence of deleted or renamed files even after MFT record reuse.
$LogFile
The NTFS $LogFile, located in Master File Table (MFT) record number 2, functions as the file system’s transactional journal. It records low-level metadata operations to guarantee volume consistency in the event of system crashes, power failures, or unexpected interruptions. In digital forensics and incident response, the $LogFile serves as a valuable “time machine,” preserving evidence of prior states of MFT entries, directory indices, and other metadata—even when higher-level artifacts have been altered or overwritten.
Knowledge of the $LogFile’s detailed internal structure derives primarily from reverse engineering, as Microsoft has provided only high-level documentation. Consequently, some fields, operation codes, and data interpretations remain incompletely understood or undocumented, which hinders fully reliable automatic parsing compared to better-documented artifacts such as the $UsnJrnl or MFT.
The $LogFile’s logging area operates as a circular buffer: new records continuously overwrite the oldest entries once the allocated space is exhausted. Administrators can adjust its size (default is often 64 MB or more on modern volumes) using tools such as chkdsk /L. The file begins with two restart areas (each typically 4 KB) containing recovery metadata, followed by the main logging region composed of 4 KB LFS record pages (usually starting with the magic "RCRD").
 |
| Figure 2: Transaction overview |
Each page contains one or more Log File Service (LFS) records (also referred to as update records or LSN records, where LSN denotes the 64-bit Log Sequence Number uniquely identifying the record). A single high-level file system operation—such as creating, modifying, or deleting a file—typically generates multiple LSN records that together form one transaction. These records frequently reference and modify several MFT entries or attributes. Key fields within an LSN record include:
- This LSN and Previous LSN — which chain records belonging to the same transaction, establish ordering, and support recovery logic.
- Redo operation and Undo operation codes, along with their associated variable-length data. The redo information describes how to reapply a committed sub-operation, while the undo information enables rollback of an incomplete one. Both must be idempotent (safe to replay multiple times).
 |
| Figure 3: LSN record |
Depending on the specific redo/undo operation pair, the record may embed additional forensic payload, such as partial or complete MFT file records, index buffer modifications, bitmap changes, or other metadata. Notably, in the case of the "Update Nonresident Value / No Operation" pair, the redo data field can contain an embedded Update Sequence Number (USN) record directly from the $UsnJrnl ($J stream). This creates a powerful correlation point between the low-level transactional log and the higher-level change journal.
When analyzed alongside the MFT (for current/residual metadata) and the $UsnJrnl (for summarized file-level changes), the $LogFile forms part of the NTFS TriForce, enabling detailed reconstruction of operations, detection of timestomping or anti-forensic activity, and recovery of historical file states that might otherwise be lost.
$USNJRNL
The Update Sequence Number (USN) Change Journal ($UsnJrnl), often described in the digital forensics community as a higher-level, more "user-readable" counterpart to the low-level NTFS $LogFile, provides a concise audit trail of file and directory operations on an NTFS volume. Introduced with NTFS 3.0 in Windows 2000, it remained optional until Windows Vista, from which point it has been enabled by default on client editions (facilitating features such as Search Indexing and File History).
Unlike the sparsely documented $LogFile, Microsoft provides relatively comprehensive documentation for the USN Journal via the Windows API. The journal is implemented as a hidden system metafile located at \$Extend\$UsnJrnl, with the primary change records stored in its $J alternate data stream (full path: \$Extend\$UsnJrnl:$J). A secondary $Max stream contains configuration data, including the target MaximumSize and AllocationDelta.
 |
| Figure 4: USN record |
The $J stream consists exclusively of variable-length USN records. Each record captures a high-level summary of a change to a file or directory—including the USN (a unique 64-bit identifier for the record), FileReferenceNumber, ParentFileReferenceNumber (formatted identically to MFT $FILE_NAME attribute references), filename (without full path), timestamp, and a Reason bitmask indicating the type of change (e.g., USN_REASON_FILE_CREATE, USN_REASON_RENAME, USN_REASON_DELETE, USN_REASON_CLOSE). Microsoft defines three main record versions:
- USN_RECORD_V2 — the most common baseline structure.
- USN_RECORD_V3 — introduced in Windows 8 / Server 2012; primarily expands file reference numbers to 128-bit FILE_ID_128 for support of extremely large volumes.
- USN_RECORD_V4 — supports range tracking (modified byte extents in large files) and is used only when explicitly enabled via
fsutil usn enablerangetracking. Standard change logging typically produces V2 or V3 records.
The journal is managed with a target maximum size. Although it can temporarily exceed this limit through incremental allocation, NTFS periodically trims the oldest records (effectively operating as a circular buffer during checkpoints). When space is deallocated, remnants of older USN records may persist in unallocated disk space or slack and can be recovered through carving techniques, extending the effective historical depth beyond the active journal.
Forensically, the $UsnJrnl is highly valuable because it preserves evidence of historical filesystem activity—including creation, deletion, renaming, and movement of files—even after MFT record reuse or basic anti-forensic attempts. When correlated with the MFT (for metadata and path reconstruction) and the $LogFile (for transactional depth), it forms a core component of the NTFS TriForce, enabling detailed timelines, detection of timestomping, identification of staging directories, and reconstruction of attacker actions that might otherwise be obscured.
Linkage Between $LogFile and $USNJRNL
Each USN record incorporates the MFT entry number (extracted from the file reference number field, comprising the low-order 48 bits). This identifier facilitates correlation between a USN record and specific Log Sequence Number (LSN) records in the $LogFile. For applicable LSN records—typically those involving operations on non-resident attributes or MFT structures—the target MFT entry number can be derived computationally. The derivation relies on the target Virtual Cluster Number (VCN) and the MFT cluster index fields present in the LSN record. The precise mathematical relationship is given below:
MFT Entry Number ≈ (VCN × Cluster size) + (MFT cluster index × block size / MFT entry size) ---------(equation 1)Under standard volume parameters, such as 4 KB clusters, 1 KB MFT entry size, and 512-byte block size, the above equation simplifies to:
MFT Entry Number ≈ (VCN × 4) + (MFT cluster index / 2) ---------------(equation 2)Furthermore, each USN record is distinguished by its unique Update Sequence Number (USN). Certain LSN records embed a complete or partial USN_RECORD structure directly within their redo (or occasionally undo) payload. In such cases, the embedded USN value establishes an explicit, bidirectional linkage between the low-level transactional logging in the $LogFile and the higher-level change journal in $UsnJrnl, enabling precise cross-referencing of file system operations across these interdependent artifacts.
The formulas above perform reliably only for operations that directly modify structures within the $MFT file itself (e.g., resident attribute updates or certain index and bitmap operations). It frequently fails for operations targeting non-resident attributes of user files or when an Open Attribute Table index is used instead of a direct MFT reference. A notable example occurs when an LSN record contains an embedded USN record in its redo data field—commonly seen with the “Update Nonresident Value / No Operation” redo/undo pair. In such cases, the standard VCN-based calculation is inapplicable because the operation involves non-MFT data. The embedded USN record then serves as a more useful identifier, linking directly to the affected file via its FileReferenceNumber. Developing a comprehensive mapping—or decision tree—of redo/undo operation pairs for which Equation 1 (or its variant) reliably produces a valid MFT entry number would significantly improve automated $LogFile parsing and correlation with the MFT and $UsnJrnl.
Transaction Grouping in the $LogFile
In the NTFS $LogFile, individual Log Sequence Number (LSN) records belonging to the same atomic transaction can be grouped by traversing the backward chain formed by the PreviousLsn (or ClientPreviousLsn) fields. Each such transaction is assigned a unique identifier. This transaction number corresponds to the ThisLsn value of the second-to-last LSN record within the transaction chain (typically preceding a final "Forget Transaction" or compensation record).
This identifier is frequently referenced directly in the $LogFile Sequence Number field of the associated MFT entry header, providing an efficient linkage between the low-level transactional journal and the metadata structures in the Master File Table. The choice of using a near-terminal LSN as the transaction anchor appears to be a pragmatic and effective design decision for both recovery and forensic correlation purposes.
Linkage Between $LogFile and MFT
Each record in the $LogFile is identified by a unique Log Sequence Number (LSN). Correspondingly, every MFT entry contains a $LogFile Sequence Number field (offset 0x08 in the file record header) that references the most recent LSN record describing a modification to that metadata structure. Because the $LogFile employs a circular logging area, older records are periodically overwritten. Consequently, an LSN value stored in an MFT entry may no longer resolve to an extant record. The inverse linkage—from an LSN record back to the current MFT—encounters analogous difficulties.
An alternative correlation method relies on the MFT entry number. For applicable LSN records, this number can be derived from the target Virtual Cluster Number (VCN) and MFT cluster index fields (as detailed in the preceding discussion on USN→LSN linkages). However, successful resolution of an MFT entry number does not guarantee a semantically valid historical link: the $LogFile may legitimately contain records pertaining to prior occupations of the same MFT slot. Since MFT records are reused (with the sequence number incremented upon reallocation), there is no straightforward mechanism within the log record alone to distinguish between successive uses of the same MFT entry index. Analysts must therefore exercise caution and corroborate such linkages using additional context, such as MFT sequence numbers, embedded USN values, or temporal consistency checks.
Linkage Between $MFT and $USNJRNL
The $STANDARD_INFORMATION attribute (type 0x10), which is resident in nearly every MFT entry, includes an 8-byte Update Sequence Number (USN) field. This value directly references the most recent corresponding record in the $UsnJrnl:$J change journal. Traversing from the MFT to the journal via this field is typically productive, as the journal often retains a substantial historical window of records.
Conversely, linking in the opposite direction—from a USN record back to the current MFT state—is less reliable. The $STANDARD_INFORMATION USN is always updated to the latest value, so newer operations overwrite it. Moreover, when an MFT record is deallocated (upon file deletion) and later reused, the field is reset for the new occupant.
Each USN record embeds a file reference number consisting of an MFT entry number (low 48 bits) and an MFT sequence number (high 16 bits). The former identifies the target MFT slot, while the latter acts as a generation counter indicating how many times that slot has been allocated. Because the sequence number in a historical USN record may be lower than the current value in the active MFT header, it can legitimately reference a prior occupation of the same MFT entry. This mechanism preserves forensic evidence of previous file instances that would otherwise be irrecoverable after MFT reuse.
Forensic Implications
These cross-references enable robust timeline construction, deleted file recovery, and path reconstruction, but demand careful validation to account for the circular nature of both journals and MFT record reuse. When properly correlated, the combination of transaction-level detail from the $LogFile, high-level change events from $UsnJrnl, and current metadata from the MFT provides a powerful and multi-layered view of file system history.
Post a Comment