GUI Artefact Viewers

The focused viewers complement the command-line parsers. Each presents a different Windows artefact, so begin with the investigation question rather than opening every tool. Use verified working copies, record the viewer version and export results to separate controlled storage.

1 Ask›2 Select source›3 Inspect›4 Record context›5 Corroborate

Match the viewer to the question

Choose the viewer by the evidence relationship you need to examine. The three tools are alternatives for different questions, not three compulsory stages of one workflow.

FOLDER AND NAMESPACE CONTEXT

Which locations are represented for this user?

Use: ShellBags Explorer

Open: verified NTUSER.DAT and UsrClass.dat copies.

Useful for folder hierarchies, removable-media paths, network locations and locations no longer present.Go to ShellBags Explorer

APPLICATION-LINKED RECENT ITEMS

Which destinations are associated with an application?

Use: JumpList Explorer

Open: verified automatic or custom destination files.

Useful for AppID, DestList and embedded LNK context. A reference is not proof of document contents or intent.Go to JumpList Explorer

COMPATIBILITY CONFIGURATION

Which matching rules, layers or shims are defined?

Use: SDB Explorer

Open: an identified Windows or custom .sdb working copy.

Useful for compatibility configuration and suspicious custom-database leads; registration and execution need corroboration.Go to SDB Explorer

What the GUI changes and what it does not

A viewer resolves binary structures and makes relationships easier to inspect. It does not turn a record into proof of a human action. Preserve the source artefact, tool version, filters and exported result so another analyst can reproduce the observation.

ShellBags Explorer

Folder and namespace context

What ShellBags can contribute

Windows stores folder-view preferences and shell namespace information in per-user registry hives. These ShellBag records can help an analyst identify folders, removable-media paths, network locations, archives or shell namespaces represented for a profile, even when the location is not currently available.

Useful DFIR questions include:

• Was a folder path represented in this user's shell history?
• Does the hierarchy reference a removable drive or network location?
• Is a deleted or unavailable directory still represented?
• Which user hive contains the record, and how does it align with other activity around the relevant time?

Source files

Work from identified copies of the relevant user's hives:

C:\Users\<user>\NTUSER.DAT
C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat

ShellBag data can be distributed across these hives depending on the Windows version and namespace. Record the profile path, hive path, acquisition source, byte size and hash rather than treating an exported CSV as the original evidence.

Open ShellBags Explorer

Launch ShellBagsExplorer.exe from the recorded EZ Tools directory.

Examine a user hive

1. Open or drag the verified hive copy into ShellBags Explorer. If the interface offers live-hive access, use it only on an explicitly authorised training system and record that the source was live.
2. Confirm that the displayed source corresponds to the intended user and hive.
3. Expand the hierarchy from the desktop or shell namespace towards the path relevant to the case question.
4. Select the node and inspect the summary, values and details panes.
5. Search or filter for a distinctive folder name, drive label, UNC path or shell item when the interface version supports it.
6. Export the selected result or capture a review screenshot, retaining enough parent and child context to explain the resolved path.

• Resolved path
  Record the complete path or namespace, not only the selected leaf.
• Bag path and slots
  Retain the backing registry path, node slot, MRU position and parent relationship.
• Shell-item metadata
  Record item type, short and long names, volume or network identifiers and extension-block details.
• Time fields
  Keep the exact field label and source. Distinguish target metadata from registry-key or parent-derived times.

Do not flatten every ShellBag time into folder access

Parent and current-item fields can describe different objects. Parsed “first interacted” or “last interacted” values also depend on record structure and MRU state. Report the field as labelled, retain the backing BagMRU path and corroborate important timing with registry, file-system, LNK, Jump List or event evidence.

Beginner interpretation example

The verified UsrClass.dat for user Avery contains a ShellBag hierarchy resolving to E:\Case Notes. This supports that the folder was represented in Avery's shell data. It does not, by itself, identify which files were opened, prove who was at the keyboard or establish why the location was used.

JumpList Explorer

Application-linked recent items

What Jump Lists can contribute

Jump Lists are per-user records associated with applications and recent or pinned destinations. Automatic-destination files are structured containers that can include a DestList stream and embedded LNK records; custom destinations contain application-defined lists of LNK entries.

They can help answer:

• Which file, folder, host or share is referenced by an application's recent destinations?
• Which application identifier is associated with the record?
• What target, volume, machine, network or LNK metadata remains available?
• Does the entry correlate with another user artefact or event sequence?

Source files

Collect both destination directories for the relevant profile:

C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations
C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations

Retain the complete source filename. The leading value is an AppID that can help associate the Jump List with an application, but document how the mapping was obtained and allow for unknown or changed application associations.

Open JumpList Explorer

Launch JumpListExplorer.exe from the recorded EZ Tools directory.

Review recent destinations

1. Open the verified automaticDestinations-ms or customDestinations-ms working copy. For a broad profile review, load the controlled directory if the installed version supports it.
2. Confirm the source filename, resolved AppID and destination type.
3. Review the DestList entries and embedded LNK records rather than relying on the application name alone.
4. Filter for the case filename, extension, target path, hostname, share, volume label or other distinctive value.
5. Select the matching entry and inspect target path, entry number, access count, pin state, timestamps, volume information and machine identifiers that are actually present.
6. Export the selected rows with the source filename and preserve the original destination file separately.

• Application context
  AppID and source filename help relate the list to an application.
• Destination context
  DestList and LNK data can retain target paths, shares, hostnames and volume details.
• Sequence and use fields
  Entry number, access count and pin state can add context when present.
• Time context
  Keep each timestamp's exact label and distinguish DestList fields from embedded LNK metadata.

A reference is not a complete user-action history

A Jump List entry supports an application-linked destination or recent-item relationship. It does not alone prove that the document contents were viewed, modified or exfiltrated, nor does it identify the person at the keyboard. Entries can persist after targets disappear and can be affected by application and Windows behaviour.

Beginner interpretation example

The verified automatic-destination file associated with Microsoft Excel contains an entry referencing C:\Users\Avery\Documents\finance.xlsx. This supports an Excel-linked recent destination for Avery's profile. Authorship, document contents and the exact user action require corroboration.

SDB Explorer

Compatibility configuration

What application-compatibility databases can contribute

Windows shim databases (.sdb) describe application-compatibility matching rules, layers, shims and related metadata. Windows includes system databases, and administrators or software installers can register custom databases. Attackers have also abused custom shims, so an unfamiliar database can be a useful lead, but the mere presence of an SDB is not proof of malicious use.

Use SDB Explorer to ask:

• Which executables or matching attributes are defined in this database?
• Which compatibility layers, shims or flags are assigned?
• Is the database a standard Windows file or a custom installed database?
• Do its name, GUID, file path and referenced programs align with authorised software or require further investigation?

Source files

Identify .sdb files from the acquired Windows installation, including the system AppPatch area and any custom database locations discovered during the case. Common starting points include:

C:\Windows\AppPatch\
C:\Windows\AppPatch\Custom\
C:\Windows\AppPatch\Custom\Custom64\

Also preserve supporting registry records, file-system metadata, installation logs or event records that show how and when a custom database was registered.

Open SDB Explorer

Launch SDBExplorer.exe from the recorded EZ Tools directory.

Inspect a database

1. Open the identified .sdb working copy and confirm its source path and hash.
2. Record the database name, description, GUID or other identifiers presented by the tool.
3. Expand the database tree and locate application or executable matching entries relevant to the case.
4. Review the executable name, path or matching attributes and any referenced compatibility mode, layer, shim, flag or patch data.
5. Compare unfamiliar entries with the host's installed software, file-system timestamps and authorised change records.
6. Preserve the selected node, surrounding tree, source identifiers and a bounded explanation. Do not edit or save changes into the evidential SDB.

Observation	What it can support	What still needs corroboration
Custom database name and GUID	Identity of the parsed SDB structure	Who installed or registered it
Matching entry for an executable	The database defines a rule for that target	Whether the target executed under the rule
Layer or shim assignment	Compatibility behaviour configured in the database	Whether the behaviour was applied and with what effect
Unusual custom SDB path or time	A lead for persistence or defence-evasion review	Intent, installer and execution history

Examine; do not install

SDB Explorer is being used here to inspect an acquired database. Do not register an unknown SDB, apply a shim or open a suspect executable on the analyst workstation. Escalate suspicious entries for controlled malware or persistence analysis.

Beginner interpretation example

The custom SDB defines a matching entry for legacy-client.exe and assigns a compatibility layer. This supports configuration represented inside the parsed database. It does not establish that the database was registered or that the executable ran under that layer; registry, event, Prefetch and file-system evidence should be reviewed.

Build a defensible review record

Reproducible examination

For every GUI examination, preserve:

• Question and tool choice
  Record what you needed to establish and why this viewer matched that question.
• Source provenance
  Keep user or host context, original path, byte size, source hash and working-copy hash.
• Viewer state
  Record executable path, version, filters, sorting and time-zone display.
• Selected context
  Retain rows or nodes with enough parent, child and source context for independent review.
• Review output
  Hash screenshots or exports and record their controlled destination paths.
• Bounded conclusion
  Separate observation from interpretation, limitations and the next corroborating source.

Use the CLI counterpart when repeatability matters

ShellBags Explorer and JumpList Explorer are useful for learning and focused review. For repeatable processing across many sources, consider their command-line counterparts (SBECmd and JLECmd) and retain the exact command and complete output directory.

Further reference: the official EZ Tools catalogue and the project's Jump List format documentation.

PreviousCommand-line parsersNextHands-on Labs