Windows Artifacts II: ShellBags, ADS, LNK, Hibernation, Slack

ShellBags record folder interactions in the registry, independent of the underlying storage medium. Whenever a user opens a folder in Explorer, Windows writes a record of that folder's view state (icon position, column widths, sort order) into the registry. The records persist in NTUSER.DAT under Software\Microsoft\Windows\Shell\BagMRU and \Bags, and in UsrClass.dat under the same path. The records are per-user, written even for folders on removable media, and survive long after the media is detached or the folder is deleted.

ShellBags can prove that a specific folder existed on a specific drive at a specific time, even when no MFT entry survives because the drive was unplugged before imaging. In an internal data theft investigation at an Indian PSU bank in 2023, the absence of the alleged exfiltration drive at imaging was overcome by ShellBag records that named the drive's volume label, the folder structure on it, and the last-accessed timestamps for each folder.

Eric Zimmerman's ShellBagsExplorer is the GUI; SBECmd.exe is the headless command-line equivalent for batch work. Both parse BagMRU and Bags, reconstruct the folder hierarchy, and resolve the MRU (most recently used) ordering into a timeline.

SBECmd.exe -d "E:\Triage\Users\suspect\NTUSER.DAT" --csv .\out
SBECmd.exe -d "E:\Triage\Users\suspect\AppData\Local\Microsoft\Windows\UsrClass.dat" --csv .\out

The output CSV carries one row per folder, with the parent path reconstructed, the absolute path, the first-interacted and last-interacted timestamps, and the MRU position. The last-interacted timestamp is the field defence counsel will press: it shifts when the user re-opens the folder, so a single timestamp does not prove a single visit, but it does prove the folder was viewed at or after that time.

NTFS supports multiple named data streams per file. The default stream is what everyone sees as the file's content. A named stream is accessed with the syntax filename.txt:streamname, and from a normal directory listing it does not exist. The space it occupies counts against the volume but not against the visible file size.

The legitimate use most examiners meet first is Zone.Identifier. Every file Windows downloads from the internet gets a :Zone.Identifier stream attached with a small INI-format payload describing the source URL and the security zone. This is the Mark-of-the-Web (MOTW) mechanism. When a downloaded Office document throws a "Protected View" banner, MOTW is the reason.

The malicious uses are older than MOTW. A 2003 SANS paper documented iexplore.exe being hidden as c:\windows\system32\calc.exe:iexplore.exe. The technique has resurfaced in modern campaigns, including a wave of Indian banking-sector intrusions in 2022 where a credential stealer wrote its second-stage payload to a Zone.Identifier-shaped ADS on a benign-looking PDF in the Downloads folder. CERT-In's advisory CIAD-2022-0089 named the technique without naming the family.

The investigator's heuristic is to compare the visible file size against the on-disk size reported by streams.exe or fsutil. A 12 KB image whose primary stream is 12 KB and whose total on-disk allocation is 3.2 MB is hiding 3.2 MB behind a named stream. The stream content is then extracted with more < filename.txt:streamname > extracted.bin from cmd.exe, or with Get-Content -Stream streamname filename.txt from PowerShell.

LNK files are the Windows shortcut format. Windows creates them automatically in two folders the examiner cares about:

• C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\ for files opened in Explorer or via the Recent menu.
• C:\Users\<user>\AppData\Roaming\Microsoft\Office\Recent\ for documents opened in Word, Excel and PowerPoint.

Each LNK file carries far more than the visible "shortcut to..." metadata. The on-disk format includes the absolute target path, the working directory, the target's MAC times at the moment the LNK was written, the target volume serial number, the volume label, the target file size, and a "tracking" block that records the source NetBIOS host name and, critically, the MAC address of the network interface the host was using when the LNK was created.

The MAC address in the tracking block is the most evidentially significant field. A LNK file recovered from a suspect machine carries that machine's own MAC address, linking the hardware to the target file or network share at the time of access. Conversely, a LNK file recovered from a victim share names the host that opened the file. The Indian appellate record contains at least one cyber-stalking case (Karnataka, 2021) in which the trial court relied on LNK file MAC-address evidence to place the accused's laptop on the victim's shared drive.

LNK files survive after the target is deleted, because they are separate files in Recent\. They are also written when files are opened from removable media, which means a USB stick that was plugged in three months ago and never imaged still has an audit trail in Recent\ on the host.

When Windows hibernates, it compresses the contents of RAM and writes the result to C:\hiberfil.sys. The compression is Xpress-Huffman and is documented; the format is parseable. Volatility (versions 2.6 and 3.x) handles hiberfil natively with the hibernation address space; Hibr2Bin from Comae converts a hiberfil.sys into a raw memory dump that any memory analysis tool can consume.

The key distinction between hiberfil.sys and a live RAM capture is temporal. A live winpmem or magnet RAM capture gives you the current state of memory. A hiberfil from three days ago gives you the state at the moment of the last hibernation, which may include processes that have since exited, decrypted credentials that were swapped back out, and clipboard contents that were never re-touched. In an Indian state-police cybercrime investigation against an insurance-fraud ring in 2024, a hiberfil from a seized laptop yielded a Telegram session token that had been rotated out of live memory by the time the device was imaged.

pagefile.sys is virtual memory that Windows has paged out of RAM to disk. Anything that was in memory long enough to be paged is fair game: decrypted database keys, cleartext credentials a browser had open, fragments of network packets, parsed JSON tokens. bulk_extractor from Simson Garfinkel parses pagefile and swapfile alongside hiberfil and extracts the universe of structured strings: URLs, RFC822 headers, credit card numbers, AES key candidates, base64 blobs. The CFSL Hyderabad cyber wing standard triage is to run bulk_extractor on all three files before any deeper carving.

swapfile.sys is newer. Introduced in Windows 8.1, it backs the suspension of Universal Windows Platform (UWP) and modern Store apps. It is smaller than pagefile.sys and structured differently, but the same string-extraction approach works.

Slack space arises because disk clusters are larger than the files they hold. A file of 100 bytes allocated to a 4 KB cluster leaves 4,096 minus 100 equals 3,996 bytes of slack at the end of the cluster. That slack carries whatever was there before. File slack is the formal term for the bytes between end-of-file and end-of-cluster. RAM slack is the narrower band between end-of-file and end-of-sector inside the last sector of the file, historically padded with zeroed bytes from RAM at write time. Drive slack is unallocated clusters within the volume that have not been zeroed.

1. Image the volume
   Acquire a forensic image with FTK Imager, dc3dd or X-Ways. Slack space only exists on a live volume or a sector-level image, not on a logical copy.
2. Carve file slack
   Use TSK's blkls or X-Ways' template-based slack extraction to pull the slack at end-of-file for every cluster in the MFT.
3. Carve drive slack
   Use TSK's blkls in unallocated mode (blkls -A) to dump every unallocated cluster. Run scalpel or foremost over the dump for files reborn from previous deletions.
4. Cross-reference against the MFT
   A string match inside a slack region is only useful if you can name the file the slack came from. The MFT $LogFile and $UsnJrnl tell you what was at that cluster before.

Volume Shadow Copies sit one layer up. The Volume Shadow Copy Service maintains block-level snapshots of NTFS volumes under C:\System Volume Information\. Each snapshot is a point-in-time view of the volume that lets the user roll back via System Restore. For an examiner, each snapshot is a recoverable copy of files that the current volume no longer has, or that have been overwritten with malicious content.

The standard toolchain is vshadowmount from the libvshadow project to mount each snapshot at a path on the analysis host, then any standard tool to analyse the mounted view. ShadowExplorer is the GUI for the same job. KAPE has a built-in VSS module that enumerates and exports snapshots in one run.

Recycle Bin under modern Windows lives at C:\$Recycle.Bin\<SID>\, where <SID> is the user's security identifier. Each deleted file becomes a pair: an $I file with metadata (original path, size, deletion timestamp) and an $R file with the content. Eric Zimmerman's RBCmd.exe parses the pair and outputs a CSV with original path, deletion time and recovered content reference.

In casework, these artifacts are examined together rather than in isolation. A typical SFSL Mumbai cyber wing triage of a seized Windows laptop runs like this.

1. Imaging
   Acquire a full disk image with FTK Imager or dc3dd over a write-blocker. Hash with SHA-256 in the same step. The hash and the acquisition log are entered into the FSL chain-of-custody register the same hour.
2. KAPE triage
   Run KAPE with the !SANS_Triage compound target to a separate output drive. KAPE pulls registry hives, event logs, prefetch, LNK files, ShellBag-carrying hives, $MFT, $UsnJrnl, browser artifacts and VSS in roughly 12 to 20 minutes for a typical 256 GB SSD.
3. Eric Zimmerman parsing
   Run RECmd, EvtxECmd, PECmd, LECmd, SBECmd, RBCmd against the KAPE output. Each writes CSV that lands in a per-case folder. The CSV layer is what gets queried during the rest of the case.
4. ADS and slack carving
   Run streams.exe across the mounted image's NTFS partitions for ADS enumeration. Run bulk_extractor against pagefile, swapfile, hiberfil and unallocated dumps for the structured-strings layer.
5. VSS expansion
   Mount each snapshot with vshadowmount and re-run the same parsers against the mounted snapshot views. Snapshots from before the suspected incident date are usually where pre-tampering state lives.
6. Reporting
   Cross-reference the artifact CSVs against the IT Act 2000 charge sheet, the BNS 2023 sections invoked, and the BSA 2023 Section 63 certificate annexure. The Section 63 certificate names the source media, the hashes, and the tools used.

The CFSL Hyderabad cyber wing has documented a similar workflow internally, with an additional step for malware triage using YARA scans across the artifact dump. For NFSU digital forensic examiners, the syllabus expects familiarity with KAPE, Magnet AXIOM, X-Ways, EnCase and FTK by name. KAPE is free and is what most state SFSLs are standardising on for triage; AXIOM and X-Ways are the paid analysis suites; EnCase and FTK are the legacy big two that older labs still own licences for.