ShellBags and ZIP Files: Proving Archive Browsing

TL;DR. When a user opens a ZIP file in Explorer, Windows treats it as a folder, and the ShellBags tree gets an entry for the ZIP (a file entry item) with child entries for every directory browsed inside it. That proves the user looked inside the archive and which internal folders they opened. It does not prove extraction or execution. Per libfwsi, the items inside a ZIP are "compressed folder" items identified by their ancestor, and on Windows 10 they carry the entry's sizes, compression method, CRC-32 and modification time as text.

Archives turn up in almost every intrusion and insider case: toolkits delivered as ZIPs, data staged into archives before exfiltration, a user claiming they "never opened" an attachment. ShellBags are one of the few artifacts that can show what a user looked at inside an archive without extracting it.

How Explorer handles archives

Since Windows XP, the built-in Compressed (zipped) Folders handler lets Explorer display a ZIP as if it were a folder. Double-clicking tools.zip opens a folder view; double-clicking a directory inside it navigates further. Each of those navigations goes through the shell namespace, so each gets a BagMRU entry, like any other folder.

On Windows 11, Microsoft's KB5031455 (October 2023) added native reading of .rar, .7z, .tar, .tar.gz, .tgz and related formats through the libarchive project. Browsing those in Explorer plausibly leaves comparable traces, but I have not seen a public, tested description of their shell items. If your case depends on it, test on the same build.

Archives opened in third-party tools (7-Zip File Manager, WinRAR) do not go through Explorer's archive handler, so they do not create entries below the archive. Those tools have their own history, often in NTUSER.DAT under their vendor keys.

What the tree looks like

From the ShellBags Parser sample (fictional data):

My Computer\C:\Users\svc_backup\Downloads              directory   MFT 88530/1
My Computer\C:\Users\svc_backup\Downloads\tools.zip    file        MFT 91004/2   [archive]
My Computer\C:\Users\svc_backup\Downloads\tools.zip\x64            [archive]

tools.zip is a file entry item with the "file" flag (class type 0x32), not a directory. It has normal embedded times and an MFT reference, because the ZIP itself is an NTFS file.
x64 is inside the archive. Its parent in the tree is the ZIP's key. That relationship is the proof of in-archive browsing.
The tools.zip key's LastWrite, with x64 first in its MRUListEx, gives the "last interacted" time for x64. See ShellBags timestamps explained.

The parser flags any path that runs through .zip, .7z, .rar, .cab, .iso, .tar, .gz, .tgz or .vhd(x) as Inside an archive, so these entries surface with the Flagged only filter. ISO and VHD files are listed because Windows mounts them as drives; in that case the contents usually appear under a new drive letter rather than below the file.

What the in-archive items contain

libfwsi's Windows Shell Item format documents the compressed folder shell item as identified by its ancestry (its parent is the archive) rather than by a class type value. Its layout differs by version:

Version	Notable fields
Windows XP	Modification time as a UTF-16 text string (`mm/dd/yy HH:MM`), name strings
Windows 10	Uncompressed and compressed size, compression method (`0x00` stored, `0x08` DEFLATE), CRC-32, modification time as text (`mm/dd/yyyy HH:MM:SS`, or an "N/A" string), name strings

That is useful evidence:

The CRC-32 and sizes of the entry as it was inside the archive can help match an archive seen on this host with one recovered elsewhere.
The modification time is the time stored for that entry in the ZIP, in text form, not a file system time on this host. Treat its time zone as unknown unless you can test it.
No MFT reference: the content does not exist as an NTFS file until extracted.

Parser support

Decoding varies. The ShellBags Parser decodes the archive's own file entry and keeps the full path, but its README lists ZIP-content (0x52) items as not yet fully decoded: expect a best-effort name, or an "unknown shell item" label with the raw hex in the details panel. SBECmd and ShellBags Explorer handle more of these items. For archive-heavy cases, cross-check with them (tool comparison).

Interpreting archive entries

You see	You can say	You cannot say
Entry for `x.zip` with no children	The ZIP's parent folder was browsed and the ZIP was listed/selected there	That the ZIP was opened
Children below `x.zip`	The user opened the ZIP in Explorer and browsed those internal folders	That files were extracted, opened or executed
`x.zip` in `Downloads` with created time minutes before browsing	Consistent with download then immediate inspection	Where it came from (check `Zone.Identifier`, browser history)
Deleted ZIP (no longer on disk) with children in ShellBags	The archive existed and was browsed; its MFT record can be checked for reuse	What else it contained beyond the browsed folders

Proving the next step

Extraction: look for the extracted files in the $MFT and in the USN journal (file creation bursts under a new folder right after the browse time).
Opening a file from inside the ZIP: Windows usually opens it from a temporary copy; LNK files and Jump Lists point at the temp path.
Execution: Prefetch, Amcache, ShimCache.
Source: browser downloads (browser forensics), mail attachments (messaging forensics).

Staging archives for exfiltration

The reverse pattern is common too: data compressed into an archive, then moved. ShellBags help when the user browsed into the archive to check its contents, or browsed the folder that held it. Archive creation by 7z.exe or PowerShell Compress-Archive from a console leaves no ShellBags; look at execution artifacts and the USN journal instead.

FAQ

Do ShellBags show that a ZIP file was extracted?

No. They show that the user browsed inside the archive in Explorer. Extraction creates files on disk, which you prove with the MFT, the USN journal or LNK files, not with ShellBags.

Do ShellBags record 7z and RAR archives?

Only when Explorer itself browsed them. Windows 11 can open RAR, 7z and tar variants natively since the October 2023 update KB5031455, but how those traces look is not yet well documented; archives opened in 7-Zip or WinRAR do not go through Explorer's archive handler.