6.2 NTFS Artifacts: Alternate Data Streams (ADS), Volume Shadow Copies (VSS) & $LogFile

6.2 NTFS Artifacts: Alternate Data Streams (ADS), Volume Shadow Copies (VSS) & $LogFile

Quick Answer: Alternate Data Streams (ADS) allow an NTFS file to host multiple distinct data streams using the format filename.ext:streamname:$DATA. While originally designed for compatibility with Apple Macintosh HFS resource forks, ADS is frequently abused by attackers to conceal executables and scripts because standard directory listings only reflect the size of the primary unnamed stream. Forensically, ADS is detected using dir /r or PowerShell Get-Item -Stream *. A critical legitimate stream is Zone.Identifier (Mark of the Web, where ZoneId=3 indicates Internet origin). For historical evidence recovery, Volume Shadow Copies (VSS) capture block-level Copy-on-Write snapshots of the volume, accessible via vssadmin or libvshadow. Meanwhile, the $UsnJrnl (stream $J) provides an unalterable log of file system modifications with kernel timestamps, defeating user-mode timestomping.

---

Alternate Data Streams (ADS) Mechanics

NTFS was designed with a stream-based architecture. A standard file on an NTFS volume is not merely a single block of bytes; it is a collection of attributes. The actual file content is stored inside an attribute named $DATA (0x80).

• Default (Primary) Stream: An unnamed $DATA stream referenced as document.pdf::$DATA (or simply document.pdf).
• Alternate Data Stream: A named $DATA stream attached to the same MFT record, referenced as document.pdf:hidden_payload.exe:$DATA (or document.pdf:hidden_payload.exe).
• Directory Streams: ADS can also be attached to directory records (e.g., C:\\Windows\\Temp:malware.ps1).

+-------------------------------------------------------------------------+
|                   MFT RECORD FOR "document.docx"                        |
+-------------------------------------------------------------------------+
| Header | $STD_INFO | $FILE_NAME | $DATA (Unnamed)  | $DATA:payload.exe  |
|        |           |            | Primary Content  | Alternate Stream   |
|        |           |            | Size: 24,576 B   | Size: 1,548,288 B  |
+-------------------------------------------------------------------------+

Why Standard Windows Tools Miss ADS

When a user or script executes a standard directory listing (dir without flags) or views a folder in Windows Explorer, the operating system queries only the unnamed $DATA stream. If document.docx has a primary size of 24 KB and an attacker injects a 1.5 MB executable into document.docx:payload.exe, Windows Explorer continues to report the file size as 24 KB.

Furthermore, copying an ADS-bearing file to a file system that does not support NTFS streams (such as FAT32, exFAT, or an ext4 Linux share) silently strips and discards all alternate data streams, often destroying forensic evidence during improper triage copying.

---

The Zone.Identifier Stream & Mark of the Web (MoTW)

The most prevalent and forensically valuable legitimate ADS in Windows is the Zone.Identifier stream. When a user downloads a file using a modern web browser (Edge, Chrome, Firefox), receives an email attachment in Microsoft Outlook, or downloads a file via Microsoft Teams, the application invokes the Attachment Execution Service (AES) and Windows URL Moniker APIs to append a Zone.Identifier stream to the file.

Mark of the Web Architecture & Zone IDs

The stream is formatted as a simple INI configuration block:

[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://secure-portal.example.com/invoices/
HostUrl=https://attacker-cdn.example.com/payloads/invoice_october.iso

The ZoneId integer maps directly to Internet Explorer / Windows Security Zones:

Investigative Value of MoTW

1. Proof of Ingestion: Finding ZoneId=3 on an executable in a user's Downloads folder proves the file was introduced externally via the Internet, defeating claims that the file was generated locally or part of the base OS image.
2. HostUrl and ReferrerUrl Attribution: Modern browsers write the exact download source URL (HostUrl) and the referring webpage (ReferrerUrl), providing immediate Indicators of Compromise (IoCs) and threat infrastructure domains without needing full proxy log decryption.
3. MoTW Evasion Forensics: Adversaries actively bypass MoTW by delivering malware inside container formats that do not preserve NTFS streams upon extraction when mounted natively, such as .iso, .vhd, or .img files, or inside encrypted archive containers (.zip, .7z, .rar).

---

Malicious ADS Concealment & Execution Vectors

Attackers utilize ADS to achieve stealthy local persistence, stage secondary payloads, and bypass naive file integrity monitoring.

Payload Ingestion Techniques

:: Inject an executable payload into an alternate stream of a benign text file
type C:\\tools\\nc.exe > C:\\Users\\Public\\readme.txt:nc.exe

:: Hide a PowerShell script inside an alternate stream attached to a folder
type C:\\scripts\\backdoor.ps1 > "C:\\ProgramData:update.ps1"

Execution Vectors from Alternate Streams

Direct execution of an executable from an ADS via standard cmd.exe (readme.txt:nc.exe) is blocked by modern Windows shells. However, threat actors bypass this restriction using Living-off-the-Land Binaries (LotL):

• WMIC Process Creation:

  wmic process call create "C:\\Users\\Public\\readme.txt:nc.exe"
  

• PowerShell In-Memory Execution:

  Get-Content -Path "C:\\ProgramData:update.ps1" -Stream update.ps1 | Invoke-Expression
  

• Control Panel / Rundll32 Execution:

  rundll32.exe "C:\\Users\\Public\\readme.txt:payload.dll",DllMain
  

• AppX / Bitsadmin Delivery: BITS can stream files directly into an alternate data stream target.

---

Forensic Identification & Extraction of ADS

DFIR practitioners have multiple specialized command-line tools to discover and extract hidden streams:

:: 1. Native Windows Command Prompt: Displays streams and their individual sizes
dir /r C:\\Users\\Public\\

:: Output Example:
:: 10/14/2026  02:15 PM            12,410 readme.txt
::                                 84,992 readme.txt:nc.exe:$DATA

# 2. PowerShell: Enumerate all streams associated with a file
Get-Item -Path "C:\\Users\\Public\\readme.txt" -Stream *

# 3. PowerShell: View the content of a specific alternate stream
Get-Content -Path "C:\\Users\\Public\\readme.txt" -Stream "nc.exe" -AsByteStream

# 4. PowerShell: Inspect Zone.Identifier
Get-Content -Path "C:\\Users\\analyst\\Downloads\\setup.exe" -Stream Zone.Identifier

# 5. Sysinternals Streams utility: Recursively scan a volume for all ADS
streams.exe -s C:\\Users\\Public\\

# 6. The Sleuth Kit (TSK): fls lists the stream with a colon delimiter
fls -o 2048 -r /dev/sdb1 | grep ":"

# 7. Extract the stream payload using TSK icat by referencing its attribute identifier
icat -o 2048 /dev/sdb1 18452-128-3 > extracted_malware.exe

---

Volume Shadow Copies (VSS) Architecture & Forensics

The Volume Snapshot Service (VSS) (or Volume Shadow Copy Service) is a core Windows subsystem that creates consistent, point-in-time snapshots of disk volumes while applications continue writing to them.

+-------------------------------------------------------------------------+
|                        VSS COPY-ON-WRITE ARCHITECTURE                   |
+-------------------------------------------------------------------------+
|  1. Write Request  -->  Original Cluster A  -->  Read old block A       |
|  2. Shadow Copy    -->  Diff Area Storage   <--  Save old block A       |
|  3. Disk Write     -->  Original Cluster A  <--  Overwrite new block A' |
+-------------------------------------------------------------------------+

The Copy-on-Write (CoW) Mechanism

VSS does not duplicate the entire hard drive when a snapshot is taken. Instead, it employs block-level Copy-on-Write (CoW):

1. When a shadow copy is initialized, no data is copied; a virtual point-in-time volume map is generated.
2. When an operating system process attempts to write new data to an existing cluster (e.g., modifying NTUSER.DAT), the VSS kernel driver intercepts the write.
3. The driver reads the original, unmodified cluster data from the active volume and writes it to a designated diff area in the hidden System Volume Information directory.
4. The new modified data is then written to the active volume cluster.
5. When an analyst reads from the Shadow Copy, the VSS driver dynamically synthesizes the point-in-time view: clusters that were never modified are read directly from the live volume, while modified clusters are redirected to the preserved blocks in System Volume Information.

Forensic Utility of Shadow Copies

Volume Shadow Copies represent a forensic goldmine during incident response:

• Recovering Deleted Evidence: Files deleted weeks or days prior may still exist in older shadow copies.
• Pre-Ransomware Restoration: In ransomware incidents, if the adversary failed to purge shadow copies, unencrypted corporate databases and files can be carved from recent snapshots.
• Historical Registry & Event Log Analysis: By extracting C:\\Windows\\System32\\config\\SYSTEM and SECURITY across multiple shadow copies spanning 30 days, examiners can track when new services were created, when user accounts were added, and when remote desktop connections occurred.
• Defeating Event Log Clearing: If an adversary executes wevtutil cl Security (clearing Event ID 1102), older un-cleared security logs persist inside historical shadow copies!

VSS Commands & Offline Mounting

:: Enumerate all active shadow copies on a live Windows endpoint
vssadmin list shadows

:: Check allocated storage space for shadow copies
vssadmin list shadowstorage

:: Create a symbolic link to browse a shadow copy like a standard directory
mklink /d C:\\ShadowCopy1 \\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy1\\

For offline forensic image analysis on a Linux DFIR workstation, the libvshadow suite allows examiners to inspect and mount shadow copies without booting the original operating system:

# 1. Inspect available shadow copy stores inside an E01 or RAW forensic image
vshadowinfo /mnt/evidence/disk_image.raw

# 2. Mount the volume shadow copies to expose each snapshot as a raw device
vshadowmount /mnt/evidence/disk_image.raw /mnt/vss/

# 3. Mount individual snapshot (e.g., vss1) as a read-only filesystem
mount -o ro,loop /mnt/vss/vss1 /mnt/shadow_snapshot_1/

# 4. Now extract historical registry hives, prefetch files, and event logs
cp /mnt/shadow_snapshot_1/Windows/System32/config/SYSTEM /case/evidence/SYSTEM_vss1

Threat Actor Shadow Copy Deletion

Modern ransomware operators routinely attempt to purge shadow copies before encrypting endpoint files. Detecting these commands in PowerShell logs (Event ID 4104) or Process Creation logs (Event ID 4688) signals deliberate ransomware staging:

• vssadmin delete shadows /all /quiet
• wmic shadowcopy delete
• wbadmin delete catalog -quiet
• bcedit /set {default} recoveryenabled No

---

NTFS Transaction Journaling: $LogFile & $UsnJrnl

NTFS maintains two distinct transactional logging mechanisms. Understanding their differences is crucial for CHFI candidates.

+-------------------------------------------------------------------------+
|                   $LogFile vs. $UsnJrnl ($J)                            |
+-------------------------------------------------------------------------+
| $LogFile: Metadata consistency, circular buffer (64 MB), ARIES redo/undo|
| $UsnJrnl ($J): File lifecycle audit, append-only, kernel FILETIME stamps|
+-------------------------------------------------------------------------+

$LogFile: Low-Level Metadata Consistency

• Location: Record 2 of $MFT (\\$LogFile).
• Size & Structure: Typically 64 MB circular FIFO buffer.
• Purpose: Implements write-ahead metadata journaling based on the ARIES (Algorithms for Recovery and Isolation Exploiting Semantics) protocol.
• Forensic Utility: $LogFile does not record file payloads; it records low-level transaction records (redo/undo operations) on MFT records, index buffers, and allocation bitmaps. If a suspect creates and deletes a file within seconds, $LogFile often preserves the raw MFT transaction, proving the file's existence even if the MFT record was wiped.

$UsnJrnl (Stream $J): The High-Level Change Journal

• Location: Resides in the directory $Extend\\$UsnJrnl as a named stream: $J (\\$Extend\\$UsnJrnl:$J). A companion stream, $Max, defines the maximum journal size.
• Size & Structure: Append-only sparse file that can grow to hundreds of megabytes or gigabytes before older entries are truncated.
• Purpose: Tracks high-level file system events for indexing services, backup software, and forensic auditing.

USN Record Structure & Reason Codes

Each entry in $J contains:

• USN (Update Sequence Number): 64-bit integer representing the byte offset of the record within the journal.
• File Reference Number (FRN): 8-byte identifier (6-byte MFT record number + 2-byte sequence number) of the file.
• Parent File Reference Number: FRN of the containing directory.
• Timestamp: 64-bit Windows FILETIME timestamp.
• File Name: UTF-16LE name string.
• Reason Codes: 32-bit bitmask documenting the exact operation performed:

Defeating Anti-Forensics Timestomping with $UsnJrnl

When a threat actor uses a timestomping tool to forge $STANDARD_INFORMATION timestamps, they interact with the file system via user-mode APIs. While this successfully falsifies the MFT $STANDARD_INFORMATION record, the NTFS kernel driver automatically appends a new entry to the $UsnJrnl:$J stream.

The timestamp written to the $UsnJrnl record is generated directly by the operating system kernel clock at the precise physical instant the transaction occurs. Attackers cannot alter $UsnJrnl timestamps using user-mode utilities.

Forensic tools such as Eric Zimmerman's MFTECmd extract and parse both $MFT and $UsnJrnl:$J into correlated CSV timelines:

:: Parse $MFT and $J to reconstruct an unalterable super-timeline of file operations
MFTECmd.exe -f "C:\\evidence\\$MFT" --csv "C:\\analysis" --csvf mft_parsed.csv
MFTECmd.exe -f "C:\\evidence\\$J"   --csv "C:\\analysis" --csvf usn_parsed.csv

Comparing the kernel timestamps in usn_parsed.csv against the forged dates in mft_parsed.csv provides definitive proof of malicious tampering.