USN Journal
The USN Journal, or Update Sequence Number Journal, is a core feature of the NTFS and ReFS file systems in Microsoft Windows operating systems that maintains a persistent, append-only log of all changes made to files, directories, and other objects on a formatted volume.[1][2] This journal enables efficient monitoring and recovery of file system modifications without requiring full volume scans, supporting services such as Windows Search for indexing, DFS Replication for directory synchronization, and backup applications.[2][3] Each logged change is represented as a record in the journal, uniquely identified by a monotonically increasing 64-bit unsigned integer known as the Update Sequence Number (USN).[2] These records detail the type of operation—such as file creation, deletion, renaming, size changes, or attribute modifications—along with references to the affected file or directory, including its name and parent directory information.[2] The journal is implemented as hidden streams within the volume's Master File Table (MFT), specifically in the$Extend\$UsnJrnl files, and it dynamically grows as needed while being periodically trimmed during NTFS checkpoints to manage size.[1][2]
Management of the USN Journal is handled through the fsutil usn command-line utility, which allows administrators to create, delete, query, or read the journal on a specified volume.[1] For programmatic access, Windows provides APIs like DeviceIoControl with the FSCTL_QUERY_USN_JOURNAL, FSCTL_READ_USN_JOURNAL, and FSCTL_CREATE_USN_JOURNAL controls to integrate journal functionality into applications for tasks such as incremental backups or real-time file monitoring.[2] By default, the journal is enabled on volumes used by certain Windows features, but it can be explicitly configured with parameters like maximum size and allocation delta to balance performance and storage overhead.[1]
Overview
Definition and Purpose
The Update Sequence Number (USN) Journal is a feature of the NTFS file system in Microsoft Windows that maintains a persistent, ordered log of all changes to files, directories, and other objects on a volume.[2] It records these modifications using sequential 64-bit unsigned integer identifiers, known as USNs, which provide a unique, monotonically increasing sequence number for each event in the journal stream.[4] This mechanism ensures that changes are captured in the order they occur, providing a reliable audit trail without altering the core file system operations.[2] The primary purpose of the USN Journal is to enable applications and services to efficiently track and respond to file system modifications without requiring resource-intensive scans of the entire volume.[2] By logging events such as file creation, deletion, renaming, and attribute changes, it supports use cases like incremental backups, data replication across systems, and real-time monitoring for security or compliance.[2] This targeted approach allows developers to query only relevant updates, minimizing processing time and system load.[2] Key benefits of the USN Journal include significant reductions in overhead for ongoing file system operations and faster recovery after interruptions, such as enabling search indexes to resume without full re-scans.[2] It differs from the broader NTFS journaling system, particularly the $LogFile transaction log, which focuses on low-level metadata recovery to maintain file system integrity during crashes rather than exposing change details to applications.[5][2]Compatibility with File Systems
The Update Sequence Number (USN) Journal is primarily supported on the NTFS file system version 3.0 and later, which was introduced with Windows 2000.[6] This feature serves as an optional mechanism for tracking file and directory changes within the volume, requiring explicit enablement via administrative tools to activate it on an NTFS volume.[1] Prior to NTFS 3.0, such as in Windows NT 4.0 with earlier NTFS versions, no USN Journal functionality exists, limiting change-tracking capabilities to basic file system auditing without persistent journaling.[7] Extended compatibility extends to the Resilient File System (ReFS), where USN Journal support is available across all ReFS versions starting from its introduction in Windows Server 2012.[8] The USN journal is active by default on ReFS volumes in client editions of Windows Vista and later, but requires explicit enablement on server editions.[7] This aligns with NTFS behavior, where the feature is active by default on client installations but inactive on most server installations, ensuring it does not consume resources unnecessarily on volumes not requiring detailed auditing.[2] Full USN Journal functionality is available in Windows 2000 and all later client and server editions, including Windows XP, Windows Vista, Windows 7, Windows 10, Windows 11, Windows Server 2003 through Windows Server 2025.[9] In older systems predating Windows 2000, API access to the journal is unavailable, restricting applications to alternative change-detection methods like polling.[4] The journal's scope is confined to the specific enabled volume, capturing only local file system modifications such as creations, deletions, and attribute changes, while excluding events from network shares, remote storage, or other disconnected file systems.[1]Technical Details
Storage and Location
The USN Journal is stored as a hidden system metafile named UsnJrnl within the Extend directory of an NTFS volume, accessible via the full path Extend\UsnJrnl; this file is not visible through standard Windows file explorers due to its system-level status.[10][11] The sequential log of change records resides in an alternate data stream named J attached to the UsnJrnl file, forming the core persistent structure for tracking file system modifications.[10][12] Records are appended in chronological order to the $J stream, ensuring a linear history of changes; upon reaching full capacity, the journal wraps around by overwriting the oldest entries, while retaining newer ones until further activity or resizing occurs.[2][13] By default, the journal is allocated 32 MB of space on the system volume, though this can be adjusted to larger sizes—up to practical volume constraints—via administrative tools, allowing dynamic growth in response to sustained file system activity.[14][1] USN numbers, which uniquely identify each record's position within the journal, are assigned as monotonically increasing 64-bit values derived from the NTFS update sequence mechanism tied to changes in the Master File Table (MFT).[15]Record Structure and Fields
The USN journal consists of binary records that capture metadata changes to files and directories on an NTFS volume, enabling efficient tracking without storing file contents. These records are appended sequentially to the journal stream within the $UsnJrnl metafile, with each record's structure defined by a version-specific format to ensure compatibility across Windows releases. The version is indicated by the MajorVersion and MinorVersion fields, allowing applications to parse records dynamically based on size and offsets. Applications should avoid legacy formats prior to version 2.0, as they lack robustness for modern use.[4][15] The legacy USN_RECORD (version 1) served as the initial format in early NTFS implementations but is deprecated and not recommended for new development due to limited field support and potential alignment issues. It predates standardized structures and was superseded to accommodate growing volume sizes and detailed logging needs.[4] The standard USN_RECORD_V2, introduced in Windows XP, with a fixed size of 60 bytes plus the variable-length FileName field, aligned on 8-byte boundaries, forms the core format for most journal operations and is backward-compatible with earlier systems. This structure includes fixed-size fields for essential metadata followed by a variable-length file name, with records aligned on 64-bit boundaries in buffers for efficient parsing. Key fields are outlined below:| Field | Type | Size (bytes) | Purpose |
|---|---|---|---|
| RecordLength | DWORD | 4 | Total length of the record in bytes, used to traverse to the next record. |
| MajorVersion | WORD | 2 | Major version number (2 for V2). |
| MinorVersion | WORD | 2 | Minor version number (0 for V2). |
| FileReferenceNumber | DWORDLONG | 8 | Unique 64-bit ordinal identifier for the affected file or directory. |
| ParentFileReferenceNumber | DWORDLONG | 8 | 64-bit ordinal identifier for the parent directory. |
| Usn | USN (DWORDLONG) | 8 | Monotonically increasing 64-bit sequence number assigning order to the change. |
| TimeStamp | LARGE_INTEGER (FILETIME) | 8 | UTC timestamp of the change event. |
| Reason | DWORD | 4 | 32-bit bitmask of flags indicating the type of change (e.g., creation, modification). |
| SourceInfo | DWORD | 4 | Flags specifying the source of the change, such as user or system operations. |
| SecurityId | DWORD | 4 | Unique identifier for the file's security descriptor. |
| FileAttributes | DWORD | 4 | Standard file attributes (e.g., read-only, hidden). |
| FileNameLength | WORD | 2 | Length of the file name in bytes. |
| FileNameOffset | WORD | 2 | Byte offset from the start of the structure to the file name field. |
| FileName | WCHAR[16] | Variable | Null-terminated Unicode string of the file or directory name. |
Change Reason Flags
The Change Reason Flags in the USN Journal, also known as USN_REASON flags, are bit flags stored in the Reason field of each USN record to categorize the specific types of file system changes that occurred on an NTFS volume. These flags provide a mechanism for identifying the nature of modifications, such as data alterations, structural operations, or attribute updates, without logging every possible event like file reads. Only changes that modify the file or directory trigger a new record, and the flags are defined in the USN_RECORD_V4 structure as a 32-bit unsigned integer where multiple flags can be set simultaneously via bitwise OR to represent compound operations.[18] The flags are grouped into conceptual categories for clarity: data management flags track alterations to file content or streams; structural flags indicate creation, deletion, or renaming of files and directories; and attribute flags cover changes to metadata, security, or extended properties. The following table enumerates the major USN_REASON flags, their hexadecimal values, and descriptions.| Flag | Hex Value | Category | Description |
|---|---|---|---|
| USN_REASON_DATA_OVERWRITE | 0x00000001 | Data Management | Data in the primary stream was overwritten. |
| USN_REASON_DATA_EXTEND | 0x00000002 | Data Management | The primary data stream was extended. |
| USN_REASON_DATA_TRUNCATION | 0x00000004 | Data Management | The primary data stream was truncated. |
| USN_REASON_NAMED_DATA_OVERWRITE | 0x00000010 | Data Management | Data in a named stream was overwritten. |
| USN_REASON_NAMED_DATA_EXTEND | 0x00000020 | Data Management | A named data stream was extended. |
| USN_REASON_NAMED_DATA_TRUNCATION | 0x00000040 | Data Management | A named data stream was truncated. |
| USN_REASON_FILE_CREATE | 0x00000100 | Structural | A file or directory was created. |
| USN_REASON_FILE_DELETE | 0x00000200 | Structural | A file or directory was hard-deleted. |
| USN_REASON_RENAME_OLD_NAME | 0x00001000 | Structural | The old name of a renamed file or directory. |
| USN_REASON_RENAME_NEW_NAME | 0x00002000 | Structural | The new name of a renamed file or directory. |
| USN_REASON_BASIC_INFO_CHANGE | 0x00008000 | Attribute | Changes to basic file attributes or timestamps (e.g., size, creation time). |
| USN_REASON_SECURITY_CHANGE | 0x00000800 | Attribute | Changes to security settings or access control lists. |
| USN_REASON_EA_CHANGE | 0x00000400 | Attribute | Modifications to extended attributes. |
| USN_REASON_HARD_LINK_CHANGE | 0x00010000 | Attribute | An NTFS hard link was added or removed. |
| USN_REASON_COMPRESSION_CHANGE | 0x00020000 | Attribute | The compression state of a file or directory changed. |
| USN_REASON_OBJECT_ID_CHANGE | 0x00080000 | Attribute | The object ID attribute was modified. |
| USN_REASON_REPARSE_POINT_CHANGE | 0x00100000 | Attribute | A reparse point was added, changed, or deleted. |
| USN_REASON_STREAM_CHANGE | 0x00200000 | Attribute | A named stream was added, deleted, or renamed. |
| USN_REASON_TRANSACTED_CHANGE | 0x00400000 | Attribute | A change occurred within a Transactional NTFS (TxF) transaction. |
| USN_REASON_INDEXABLE_CHANGE | 0x00004000 | Attribute | The content indexing attribute was modified. |
| USN_REASON_ENCRYPTION_CHANGE | 0x00040000 | Attribute | The file or directory was encrypted or decrypted. |
| USN_REASON_INTEGRITY_CHANGE | 0x00800000 | Attribute | The integrity stream attribute was changed. |
| USN_REASON_CLOSE | 0x80000000 | General | The file or directory handle was closed; always set in the final record summarizing changes since the last open. |
Management and Operations
Enabling and Creating the Journal
The USN Journal is enabled by default on system volumes in Windows client editions starting from Windows Vista on NTFS volumes version 3.0 or greater, but server editions and non-system volumes typically require explicit creation.[7] The journal is also supported on all versions of the ReFS file system, where it follows similar activation behavior.[7] Enabling the USN Journal involves using thefsutil usn createjournal command from an elevated Command Prompt, which requires administrator privileges and targets an online NTFS or ReFS volume.[1] The command syntax is fsutil usn createjournal m=<max[size](/page/Size)> a=<allocation[delta](/page/Delta)> <volumepath>, where <volumepath> specifies the drive letter (e.g., C:).[1] The m=<maxsize> parameter sets the maximum journal size in bytes allocated by NTFS for storing change records, while a=<allocationdelta> defines the incremental size in bytes by which the journal grows as needed, allowing efficient expansion without immediate full allocation.[1] For example, fsutil usn createjournal m=33554432 a=1048576 C: configures a 32 MB maximum size with a 1 MB allocation delta on the C: drive.[1]
Upon creation, the system generates a unique journal ID, which identifies the journal instance and is used in subsequent operations.[1] If a journal already exists on the volume, the command updates the maximum size and allocation delta without recreating it.[1] The journal file is stored in the $Extend\$UsnJrnl hidden system file within the volume's root.[1]
To verify the journal's creation and state, execute fsutil usn queryjournal <volumepath>, which displays details including the journal ID, maximum size, allocation delta, and current usage.[1] This confirms the journal is active and provides metrics on its capacity and record count.[1]
Reading and Querying Records
Accessing USN Journal records programmatically is primarily achieved through the Windows Native API using the DeviceIoControl function with the FSCTL_READ_USN_JOURNAL control code, which retrieves a set of update sequence number (USN) change journal records between two specified USN values from an NTFS volume.[20] This operation requires an open handle to the volume obtained via CreateFile with the FILE_FLAG_BACKUP_SEMANTICS flag, and it returns a buffer containing one or more variable-sized USN_RECORD_V2 or USN_RECORD_V3 structures, depending on the journal version.[4] Applications must allocate a sufficiently large buffer, typically starting with 64 KB, to receive the records, and parse the buffer sequentially by following offsets in each record's header.[21] The input structure for FSCTL_READ_USN_JOURNAL is READ_USN_JOURNAL_DATA_V1 (for version 2 journals) or READ_USN_JOURNAL_DATA_V2 (for version 3), which includes parameters such as StartingUsn (the USN from which to begin reading), ReasonMask (a bitmask to filter records by change reason flags, e.g., USN_REASON_FILE_CREATE or USN_REASON_RENAME_NEW_NAME), and BytesToWaitFor (the minimum number of bytes to retrieve before returning).[22] Additional fields like Timeout and ReturnOnlyOnClose allow for asynchronous waiting or restricting output to close events, while UsnJournalID ensures the journal has not been recreated since the last query. Upon success, the operation populates an output buffer with records and returns the next USN in the MajorVersion field of a USN structure, enabling sequential pagination by using this value as the StartingUsn for subsequent calls.[21] For command-line access, the fsutil utility provides the readjournal subcommand to enumerate and display USN records from a volume's journal, outputting details such as USN, file reference number (FRN), parent FRN, timestamp, reason flags, and filename in a tabular format.[1] The syntax is fsutil usn readjournal [c=Deleting and Recreating
The deletion of a USN Journal is accomplished via the commandfsutil usn deletejournal /d <volume>, which disables the journal, removes its records, and releases the allocated disk space back to the volume.[1] This operation requires administrative privileges and is irreversible without explicit recreation, as it effectively wipes the entire change log.[1]
Administrators perform deletion during routine volume maintenance or to resolve issues such as journal corruption.[1] The process involves scanning and updating all relevant master file table entries to mark them as processed, making it potentially lengthy depending on volume size and activity.[1]
Before proceeding with deletion, it is advisable to query the journal's metadata—such as the current USN range, journal ID, and allocation details—using fsutil usn queryjournal <volume> to preserve a snapshot of the state for recovery or auditing purposes.[1]
To restore functionality, a new USN Journal is created after deletion using fsutil usn createjournal m=<maximum_size> a=<allocation_delta> <volume>, where <maximum_size> specifies the journal's cap in bytes (defaulting to 32 MB if omitted) and <allocation_delta> sets the growth increment.[1] This initializes a fresh journal with the USN counter reset to 1, effectively erasing all historical change records and starting a clean log.[23]
Recreation introduces a new journal identifier distinct from the previous one, requiring applications that rely on the USN Journal for change tracking—such as backup software or file synchronizers—to detect this shift via the identifier and reinitialize their monitoring from the journal's start.[24] Consequently, all unprocessed records from the prior journal are lost, potentially breaking continuity in systems dependent on unbroken change histories unless they implement robust handling for journal resets.[24] This contrasts with initial enabling, where no prior history exists to lose.[1]
Applications
Backup and Synchronization
The USN Journal plays a crucial role in facilitating efficient file backups by enabling tools to identify only modified, created, or deleted files since the last operation, thereby avoiding exhaustive full-volume scans. Windows File History, introduced in Windows 8, leverages the USN Journal to track these changes and back up revised versions incrementally to designated storage, such as external drives or network locations. This approach ensures that backups capture precise deltas without rescanning unchanged data, optimizing both time and resource usage.[25] In data synchronization scenarios, the USN Journal supports applications that replicate files across systems by providing a log of alterations for delta-based transfers. For instance, Microsoft DFS Replication consumes the USN Journal to monitor file and folder updates on NTFS volumes, initiating replication only for affected items and maintaining consistency in distributed environments like Active Directory SYSVOL shares. Similarly, Azure File Sync employs USN journaling to detect changes automatically and trigger sync sessions between on-premises servers and Azure storage, enabling seamless hybrid cloud synchronization.[26][27] The typical workflow for using the USN Journal in backups and synchronization involves querying the journal for records within a specific USN range—starting from the last processed USN number—and filtering by reason flags such as those indicating file creation, modification, or deletion. Applications process these records to apply corresponding actions (e.g., copying new files or updating existing ones), then update their internal tracking to the highest USN encountered, ensuring subsequent operations handle only new changes. This method relies on the journal's sequential numbering and file reference details to maintain accuracy across sessions.[2] Compared to traditional timestamp checks, the USN Journal offers significant advantages in speed and reliability, as it provides a centralized, persistent log of all filesystem events without requiring per-file attribute reads, which can be resource-intensive on large volumes. It also effectively handles complex operations like file renames and moves by including parent file reference numbers in records, allowing tools to preserve directory structures and linkages during incremental transfers—capabilities that timestamp-based methods often overlook.[1][15] An example of integration is with the Volume Shadow Copy Service (VSS), which captures the current USN state during snapshot creation to enable consistent, point-in-time views of the filesystem for backup tools; post-snapshot, the journal can be queried on the shadow copy volume to identify changes relative to that baseline, supporting reliable recovery operations.[28]Digital Forensics
The USN Journal provides critical evidence in digital forensics by logging file system changes on NTFS volumes, including deletions that may no longer appear in the Master File Table (MFT) after entries are reused or overwritten. When a file is deleted, the journal records the event with the USN_REASON_FILE_DELETE reason flag (0x0200), capturing details such as the file reference number (FRN), timestamps, and the affected file name, thereby enabling investigators to confirm the existence and removal of files even post-deletion. This persistence of deletion records in the UsnJrnl:J stream allows for the recovery of artifacts that would otherwise be lost, supporting the reconstruction of file histories in investigations involving data exfiltration, malware persistence, or unauthorized access.[29][10][4] Forensic timeline analysis leverages the sequential nature of USN Journal records, which are ordered by their Update Sequence Number (USN) and TimeStamp fields, to trace comprehensive sequences of file operations such as creation (USN_REASON_FILE_CREATE), modification (USN_REASON_DATA_EXTEND or USN_REASON_DATA_OVERWRITE), renaming (USN_REASON_RENAME_OLD_NAME and USN_REASON_RENAME_NEW_NAME), and deletion. Sorting these records chronologically reveals the full lifecycle of files or directories, including intermediate states like hard link creation (USN_REASON_HARD_LINK_CHANGE) or alternate data stream modifications (USN_REASON_STREAM_CHANGE), which are invaluable for attributing actions to specific users or processes in incident response. This approach surpasses MFT timestamp analysis by providing a more granular, operation-level audit trail.[29][30] Specialized tools parse the binary $UsnJrnl stream to extract and visualize these artifacts for investigative use. Open-source options like MFTECmd process the journal to output CSV-formatted records, while Autopsy's ingest modules integrate USN data into broader case timelines; commercial suites such as EnCase offer similar parsing capabilities with advanced querying for flags and FRNs. Additionally, utilities like mftrcrd can correlate journal entries with MFT remnants to detect anomalies, such as sudden USN gaps or missing journal files indicative of anti-forensic efforts to erase traces. Key artifacts uncovered include rename histories for tracking file movements and stream changes for identifying hidden data manipulations. In ransomware investigations, clusters of FILE_DELETE records signal mass file operations, helping to delineate the scope and timing of encryption events.[29] Despite its utility, the USN Journal's fixed allocation size imposes limitations on historical depth, as records wrap around and overwrite older entries during high-activity periods, typically retaining only days to weeks of data depending on volume size and usage patterns. This truncation occurs at NTFS checkpoints when the journal exceeds its maximum size, potentially obscuring long-term timelines unless supplemented by other logs. Cross-volume forensics requires separate parsing of each journal, complicating analysis in multi-disk environments.[31][32][33]Search and Indexing
The USN Journal facilitates efficient desktop search and file indexing by providing a persistent log of filesystem changes on NTFS volumes, allowing applications to detect and respond to modifications without performing full rescans. Search tools monitor the journal for relevant events, such as file creations, deletions, renames, and attribute updates, to maintain up-to-date indexes. This mechanism enables real-time synchronization of search databases, reducing the need for resource-intensive directory traversals.[2] Integration with third-party search applications exemplifies this capability; for instance, Everything by voidtools leverages the USN Journal to track file creations and deletions, updating its index incrementally without rescanning entire volumes. By querying the journal, Everything ensures that changes are captured even when the application is not actively running, provided it operates as a service. This approach supports near-instant searches across large datasets, such as indexes containing over 100,000 files, by maintaining a change log that filters for name and attribute modifications.[34] Windows Search and similar indexers utilize the USN Journal for recovery and maintenance, particularly after system crashes or service interruptions, by querying records to identify only altered items for reindexing. The USN_REASON_INDEXABLE_CHANGE flag specifically signals changes to a file's content-indexing eligibility, such as toggling the FILE_ATTRIBUTE_NOT_CONTENT_INDEXED attribute, allowing indexers to efficiently update or remove entries as needed. This targeted filtering minimizes processing overhead compared to alternatives like directory watching APIs, which struggle with high-volume or deep directory structures due to buffer limitations and event coalescence.[4][6][35] The benefits of USN-based monitoring include lower latency for search updates and superior scalability for volumes with millions of files, as the journal handles global changes atomically without per-directory handles. This contrasts with polling or watching methods, enabling productivity tools to provide responsive results while conserving system resources.[2][14]Limitations and Security
Performance Overhead
The USN Journal introduces minimal runtime overhead to the NTFS file system, as each recorded change involves a small append operation to the journal stream, which is designed to be efficient and asynchronous with normal file I/O activities. This append process typically consumes negligible CPU resources, though high-write workloads on volumes with frequent modifications—such as those involving large numbers of small files—can result in cumulative I/O amplification if the journal size approaches its maximum limit.[2][1] Storage impact arises primarily from the journal's growth in response to file system activity, with the UsnJrnl file stored as a sparse stream in the Extend system directory to optimize space usage. On active volumes, the journal can expand beyond its initial allocation, but NTFS automatically trims it during checkpoints if it exceeds the configured maximum size plus allocation delta, potentially causing brief I/O delays during wrap-around events when old records are discarded to make room for new ones. The default maximum size is 32 MB (33,554,432 bytes) for standard volumes, though this is often insufficient for high-activity environments like servers, where larger configurations (e.g., 128 MB increments per 100,000 files in replicated scenarios) are recommended to prevent frequent overflows. In practice, the actual allocated size remains modest—often 30–40 MB on sparse files—due to NTFS's management of the log to retain only recent changes.[1][10][36] Querying or reading the journal, particularly over large USN ranges, can impose memory overhead, as applications must buffer and process variable-length records (typically 60 bytes plus filename data), which becomes intensive for volumes with millions of changes. On solid-state drives (SSDs), the overall impact remains negligible due to fast random writes and low latency, whereas traditional hard disk drives (HDDs) may experience minor write amplification from journal appends and trims, though this is generally outweighed by the benefits of avoiding full volume scans. To mitigate these costs, administrators can configure an appropriate maximum size and allocation delta during journal creation with thefsutil usn createjournal command, tailoring it to the volume's expected change volume—for instance, increasing it for backup or replication scenarios to reduce wrap frequency. Applications should read and process journal records in a timely manner to enable effective truncation, ensuring the log does not bloat unnecessarily. For low-activity volumes where change tracking is not required, the journal can be disabled entirely via fsutil usn deletejournal to eliminate all associated overhead without affecting core NTFS functionality.[1][1]
Monitoring journal health is straightforward using the fsutil usn queryjournal command, which reports key metrics such as current size, maximum size, highest USN, and allocation delta, allowing proactive adjustments to prevent performance degradation from unchecked growth.[1]
Tampering and Evasion Techniques
Malware and unauthorized intruders commonly exploit the USN Journal by executing thefsutil usn deletejournal command to erase its contents, thereby eliminating records of file creations, modifications, and deletions that could reveal malicious activities.[37][38][1] This technique disrupts the chronological audit trail maintained by the journal, making it difficult to reconstruct timelines of system changes.[39]
Detection of such tampering often relies on indicators like the sudden absence of an active USN Journal on a volume, a reset of the USN counter to low values (such as starting from 1 upon recreation), or noticeable gaps in the sequence of update sequence numbers that deviate from expected incremental patterns.[23][24] When the journal is deleted, the file system assigns a new journal identifier, rendering prior records unusable and creating discontinuities in the log that forensic analysis can identify.[40]
To evade detection, attackers frequently recreate the USN Journal immediately after deletion using fsutil usn createjournal, restoring apparent normalcy while obscuring the intervening malicious operations.[41] Ransomware variants, such as those employing mass file encryption, often disable the journal prior to execution to prevent logging of their destructive actions.[42]
Mitigation strategies include real-time monitoring of fsutil command executions through tools like Sysmon for process creation events (Event ID 1) and Windows Audit Policy for object access logging, which can alert on unauthorized journal manipulations.[38][43] Additionally, specialized forensic tools can carve and recover remnants of deleted USN records from the slack space within the [UsnJrnl](/page/UsnJrnl) file, preserving evidence even after apparent erasure.[44][33]
The implications of USN Journal tampering extend to severe disruptions in audit trails, potentially affecting regulatory compliance requirements that mandate verifiable records of data processing activities. In the ReFS file system, similar vulnerabilities exist for journal deletion if enabled, though its Change Journal is disabled by default—unlike in NTFS—and its enhanced integrity checks provide marginally better resilience against undetected corruptions compared to NTFS.[45][46]