The Update Sequence Number (USN) Journal was first introduced with NTFS in Windows 2000. However, it remained largely inactive by default until Windows Vista, when Microsoft began enabling it automatically on most volumes. Since then, it has stayed enabled by default in all newer Windows versions. Unlike the NTFS $LogFile, which is poorly documented, Microsoft has provided reasonably good documentation for the USN Journal and its associated APIs. It resides as a system metafile in the hidden $Extend directory. The actual journal data is stored in the $J alternate data stream, so the full internal path is typically expressed as \$Extend\$UsnJrnl:$J. Another small ADS, $Max, contains metadata about the journal itself, such as its maximum size.
The USN Journal records in the $UsnJrnl:$J data stream are of variable length and are stored consecutively. The $J stream is implemented as a sparse file. It uses two important parameters defined in the USN Journal metadata ($Max stream):
- MaximumSize — the target maximum amount of journal data.
- AllocationDelta — the size (in bytes) by which the journal grows or shrinks.
Record allocation behavior:
- New USN records are appended to the end of the active data area.
- When the amount of data exceeds MaximumSize, the journal is allowed to temporarily grow by up to one AllocationDelta.
- During the next NTFS checkpoint, NTFS deallocates space from the front of the journal in chunks of AllocationDelta. These deallocated areas become sparse (they logically contain zeros when read, but occupy no physical disk space).
As a result, the logical size of the $J attribute can appear very large, while the actual allocated data on disk remains roughly constant — typically bounded near the configured MaximumSize plus one AllocationDelta. On modern Windows client systems, the default MaximumSize is usually 0x2000000 (32 MB). Servers and domain controllers often use significantly larger values (e.g., 512 MB or more).
In digital forensics, the USN Journal is highly valuable because it logs detailed file system changes, including file creations, modifications, renames, and deletions. This makes it possible to reconstruct timelines of file activity, recover evidence of deleted files, and detect signs of anti-forensic techniques (such as timestomping or mass file wiping). Even sophisticated attackers or malware that attempt to cover their tracks often leave detectable footprints in the journal, as entries can persist until the fixed-size journal wraps around and overwrites older records.
The USN Journal consists of a sequence of USN records. Each record provides a high-level description of changes made to a file or directory (such as creation, deletion, rename, or data modification), which is significantly more abstract than the low-level transaction records found in the NTFS $LogFile. Microsoft defines three main record versions: USN_RECORD_V2, USN_RECORD_V3, and USN_RECORD_V4. The differences between V2 and V3 are relatively minor (V3 adds support for 128-bit file identifiers). USN_RECORD_V4 is used specifically for range tracking of modified byte extents in large files and must be explicitly enabled — it is not used for standard change journaling. While older documentation suggested V3 would appear starting with Windows 8 / Server 2012, in practice, many modern Windows 10 and 11 systems still primarily generate V2 or V3 records depending on the volume and configuration.
Unlike a traditional circular log, the USN Journal is not strictly circular in its on-disk allocation. When it needs more space, new clusters are allocated. Old clusters are eventually deallocated during NTFS checkpoints. Because these deallocated blocks may remain intact on disk until they are reused, forensic analysts can often carve older USN records from unallocated space, sometimes recovering significant historical file activity even after the active journal has moved on.
The USN Journal ($UsnJrnl) and the NTFS $LogFile complement each other well. While the USN Journal records high-level file system events (such as creation, deletion, renaming, or modification of files and directories), the $LogFile captures low-level metadata transactions. Combining the two provides a much clearer picture of the operations performed on a file. Furthermore, the USN Journal forms part of what is often called the NTFS Trinity (sometimes referred to as TriForce in forensic literature). This combination consists of three key artifacts: the Master File Table (MFT), the $LogFile, and the USN Journal. When analyzed together, these three NTFS structures enable investigators to reconstruct detailed timelines and gain deep insight into file system activity on a Windows system, including operations that are no longer visible in the active MFT.
The tables below show the data structure for the $UsnJrnl:$J records: USN_RECORD v2 (Windows 7 and below, Windows Server 2008 R2 and below) and USN_RECORD v3 (Windows 8+, Windows Server 2012+).
Offset | Size | Description |
0x00 | DWORD | Size of journal entry |
0x04 | WORD | Major Version |
0x06 | WORD | Minor Version |
0x08 | LONGLONG | MFT Reference of the file that caused this entry |
0x10 | LONGLONG | Parent MFT Reference for the file that caused this entry |
0x18 | LONGLONG | USN for entry |
0x20 | LONGLONG | Timestamp |
0x28 | DWORD | Reason code (flags for type of change) (to be discussed below) |
0x2C | DWORD | Source information |
0x30 | DWORD | Security ID (SID) |
0x34 | DWORD | File Attributes |
0x38 | WORD | Size of file name (in bytes) |
0x3A | WORD | Offset to file name |
0x3C | Variable | File name |
V+0x3C | Padding | Padding (align to 8bytes) |
The USN_RECORD version is determined by the OS that created the journal, not the volume format alone. A disk created on Windows 7 (v2) and later mounted on Windows 10 may retain v2 records until the journal is recreated. Deleting and recreating the journal (fsutil usn deletejournal /d) on a newer OS forces v3 records.
Offset | Size | Description |
0x00 | DWORD | Size of journal entry |
0x04 | WORD | Major Version |
0x06 | WORD | Minor Version |
0x08 | FILE_ID_128 | MFT Reference of the file that caused this entry |
0x18 | FILE_ID_128 | Parent MFT Reference for the file that caused this entry |
0x28 | LONGLONG | USN for entry |
0x30 | LONGLONG | Timestamp |
0x38 | DWORD | Reason code (flags for type of change) (to be discussed below) |
0x3C | DWORD | Source information |
0x40 | DWORD | Security ID (SID) |
0x44 | DWORD | File Attributes |
0x48 | WORD | Size of file name (in bytes) |
0x4A | WORD | Offset to file name |
0x4C | WCHAR | File name |
V+0x4C | Padding | Padding (align to 8 bytes) |
The USN Journal records contain several key fields. The FileReferenceNumber and ParentFileReferenceNumber use the same format as the File Reference Numbers found in the NTFS Master File Table (MFT), allowing investigators to link each USN record to the corresponding MFT entry. The record also includes the base filename (without the full path) and a unique USN value that serves as the identifier for that specific journal entry. Each USN record contains a Reason field — a bitmask of flags that indicates the specific change(s) that triggered the creation of the record (for example, file creation, deletion, data modification, or renaming).
From a forensic perspective, the USN Journal is highly valuable because it provides historical information about NTFS file system activity that may no longer be visible in the active MFT. It can reveal evidence of deleted files, show when files were renamed or moved, and help reconstruct timelines of data modifications, even when anti-forensic techniques have been used.
The USN reason codes (also known as USN_REASON flags) indicate why a particular record was written to the NTFS Change Journal. Each USN record captures modifications made to files or directories and enables forensic investigators to track detailed file system activity over time. These reason codes are implemented as bitwise flags. As a result, a single USN record can contain multiple reasons simultaneously when several changes occur together. In forensic tools such as MFTECmd and other commercial suites, these flags are typically displayed in the Reason (or Update Reasons) column, often shown both as hexadecimal values and as readable descriptions (e.g., File Create, File Delete, Rename Old Name, Data Overwrite, Close, etc.).
Values | Meaning |
USN_REASON_DATA_OVERWRITE 0x00000001 | The file was overwritten. |
USN_REASON_DATA_EXTEND 0x00000002 | The file or directory was extended (added to). |
USN_REASON_DATA_TRUNCATION 0x00000004 | The file or directory was truncated. |
USN_REASON_NAMED_DATA_OVERWRITE 0x00000010 | The named data stream for a file is overwritten. |
USN_REASON_NAMED_DATA_EXTEND 0x00000020 | A named data stream for the file was extended (added to). |
USN_REASON_NAMED_DATA_TRUNCATION 0x00000040 | A named data stream for the file was truncated. |
USN_REASON_FILE_CREATE 0x00000100 | The file or directory was created for the first time. |
USN_REASON_FILE_DELETE 0x00000200 | The file or directory was deleted. |
USN_REASON_EA_CHANGE 0x00000400 | The file's or directory's extended attributes were changed. |
USN_REASON_SECURITY_CHANGE 0x00000800 | The access rights to the file or directory was changed. |
USN_REASON_RENAME_OLD_NAME 0x00001000 | The file or directory was renamed, and the file name in the USN_RECORD structure is the previous name. |
USN_REASON_RENAME_NEW_NAME 0x00002000 | The file or directory was renamed, and the file name in the USN_RECORD structure is the new name. |
USN_REASON_INDEXABLE_CHANGE 0x00004000 | A user changed the FILE_ATTRIBUTE_NOT_CONTENT_INDEXED attribute. That is, the user changes the file or directory from one where content can be indexed to one where content cannot be indexed, or vice versa. Content indexing permits rapid searching of data by building a database of selected content. |
USN_REASON_BASIC_INFO_CHANGE 0x00008000 | A user has either changed one or more file or directory attributes (for example, the read-only, hidden, system, archive, or sparse attribute), or one or more time stamps. |
USN_REASON_HARD_LINK_CHANGE 0x00010000 | A hard link was added to or removed from the file or directory. An NTFS file system hard link, similar to a POSIX hard link, is one of several directory entries that see the same file or directory. |
USN_REASON_COMPRESSION_CHANGE 0x00020000 | The compression state of the file or directory was changed from or to compressed. |
USN_REASON_ENCRYPTION_CHANGE 0x00040000 | The file or directory was encrypted or decrypted. |
USN_REASON_OBJECT_ID_CHANGE 0x00080000 | The object identifier of the file or directory was changed. |
USN_REASON_REPARSE_POINT_CHANGE 0x00100000 | The reparse point contained in the file or directory was changed, or a reparse point was added to or deleted from the file or directory. |
USN_REASON_STREAM_CHANGE 0x00200000 | A named stream has been added to or removed from the file, or a named stream has been renamed. |
USN_REASON_TRANSACTED_CHANGE 0x00400000 | The given stream is modified through a TxF transaction. |
USN_REASON_INTEGRITY_CHANGE 0x00800000 | A user changed the state of the FILE_ATTRIBUTE_INTEGRITY_STREAM attribute for the given stream. On the ReFS file system, integrity streams maintain a checksum of all data for that stream, so that the contents of the file can be validated during read or write operations. |
USN_REASON_CLOSE 0x80000000 | The file or directory is closed. |
Identifying File Modification
The USN Journal records a wide range of file modifications beyond simple creation and deletion events. By analyzing the Reason field in each USN record, investigators can detect when a file’s content was overwritten (USN_REASON_DATA_OVERWRITE), extended (USN_REASON_DATA_EXTEND), or truncated (USN_REASON_DATA_TRUNCATION). Although the USN Journal does not directly log a file being “opened” (such as a user double-clicking it), any modifications that occur while the file is open are captured. For example, opening and editing a document often generates a series of DATA_OVERWRITE or DATA_EXTEND events as the application writes changes to the file. By examining the sequence and timestamps of these events for a specific file, analysts can reasonably infer periods of access and modification.
The USN Journal also complements Prefetch artifacts effectively. While Prefetch files (.pf) only retain the last eight execution times for an application, the USN Journal logs every update to these .pf files. By searching for combinations of Data Extend, Data Truncation, and Close reason flags on Prefetch files, investigators can often reconstruct a much longer history of application executions than Prefetch alone allows.
Identifying File Deletion
One of the most powerful capabilities of the USN Journal is its ability to reveal files and directories that once existed on the system but have since been deleted. When a file or folder is deleted, the journal records the event with the USN_REASON_FILE_DELETE flag. Even when attackers employ secure wiping tools that overwrite both file content and slack space, the USN Journal frequently retains the deletion record. This provides investigators with critical details such as the original filename, the file’s parent directory (via the Parent File Reference Number), the associated MFT record number, and the exact timestamp of deletion. Such information is essential for determining the scope of an intrusion and identifying files an attacker tried to erase. Additionally, the USN Journal often records the MFT entry number of the deleted file. In cases where the MFT record has not yet been reused, this can sometimes allow recovery of residual metadata.
Detecting Secure Deletion Tools (SDelete Example)
A classic illustration involves SDelete.exe (Sysinternals secure delete utility). While SDelete is designed to make file recovery extremely difficult by overwriting data clusters multiple times, it leaves a distinctive footprint in the USN Journal. SDelete renames the target file 26 times in the MFT before overwriting its content and deleting it. Each rename replaces every character in the filename with the same letter, progressing alphabetically: AAAA.AAA, BBBB.BBB, ..., up to ZZZZ.ZZZ.
Forensic analysts can leverage this behavior by searching parsed USN Journal entries for filenames containing strings such as "AAAA". The record immediately preceding these alphabetical renames typically contains the original filename of the file the attacker intended to wipe. Following the "AAAA" entry, a clear sequence of subsequent renames through the rest of the alphabet is usually visible. The presence of this repetitive alphabetical renaming pattern — especially when combined with rapid data overwrite and delete operations — serves as a strong indicator that SDelete (or a similar wiping tool) was used. This technique allows investigators to uncover evidence of deliberate data destruction even when the actual file content has been securely erased.
Tracking Malware Activity: Morphing and Spawning
The USN Journal is particularly useful for uncovering advanced malware techniques designed to evade detection:
- Initial Droppers and Downloaders: Many malware infections begin with a small dropper or downloader that fetches the main payload and then deletes itself to erase the initial infection vector. The USN Journal reliably records both the creation and subsequent deletion of these temporary executables, helping investigators understand the compromise method.
- Fileless Malware and Script Execution: Although pure fileless malware tries to avoid leaving disk artifacts, many implementations still create or modify temporary files and scripts (e.g., PowerShell scripts). The USN Journal can capture these short-lived file creation, modification, or deletion events, providing important clues about malicious script execution.
- Lateral Movement and Spawning of Multiple Files: During lateral movement, attackers often drop tools, utilities, or additional payloads across multiple systems. The USN Journal records the creation of these new files and directories, enabling analysts to identify patterns of rapid file creation in unusual locations and map the attacker’s propagation across the network.
- Timestomping Detection: Attackers commonly manipulate file timestamps (timestomping) to make malicious files blend in with legitimate system files. The USN Journal records the actual time when metadata changes occur (often via the BASIC_INFO_CHANGE reason flag). By comparing these USN timestamps with the creation and modification times stored in the MFT’s $STANDARD_INFORMATION and $FILE_NAME attributes, investigators can detect inconsistencies that indicate timestomping attempts.
- Evidence of File Wipers: Malware or attackers seeking to destroy evidence may employ file-wiping tools or routines. These operations frequently generate clusters of rapid rename, data overwrite, and deletion events. The USN Journal captures these suspicious patterns, serving as a strong indicator of deliberate evidence destruction activity.
To ascertain the Master File Table (MFT) entry associated with the journal, the contents of the $Extend filesystem metadata directory—itself resident at MFT entry 11—are meticulously examined. This inquiry discloses the journal’s entry at MFT record 80976. The contents of its $J attribute are then extracted and displayed using the icat utility.
Consider the USN journal entry corresponding to the file SET9F6C.tmp, a truncated representation of which is presented below. The MFT file reference (byte offsets 0x08–0x0F), highlighted for each relevant record and bearing the value 0xBD3C010000000100, identifies the associated Master File Table entry. Interpreting the first six bytes of this eight-byte reference—0x00000001BD3C (after little-endian reversal)—yields the MFT record number 81085 in decimal. Additionally highlighted are the timestamps (byte offsets 0x20–0x27) at which NTFS recorded each change, consistently showing the FILETIME value 0x590C847A8334D101. When decoded, this corresponds to 2015-12-12 02:19:07.1289433 UTC. The USN reason codes, located at relative offsets 0x28–0x2B, are likewise highlighted.
- First journal entry reason code → 0x00000100 → FileCreate
- Second journal entry reason code → 0x80000100 → FileCreate|Close
- Third journal entry reason code → 0x00008000 → BasicInfoChange
- Fourth journal entry reason code → 0x80008000 → BasicInfoChange|Close
- Fifth journal entry reason code → 0x80000200 → FileDelete|Close
- Continue till all journal entry reason codes are interpreted
An adversary could move the USN journal into unallocated space by executing the command fsutil usn deletejournal /d C:, subsequently recreating a new journal at the same location with fsutil usn createjournal m=1000 a=100 C:. Although purging the $USNJrnl is technically straightforward, these operations invariably prompt Windows to generate an entry in the Application Event Log—specifically Event ID 3079 upon deletion of the $USNJrnl. The presence of this event serves as a salient indicator to the digital forensic examiner that deliberate data manipulation may have taken place on the system.
Post a Comment