Windows Forensic Artifacts: User Activity Evidence (LNK, Shellbags, Jump Lists, MRUs, SRUM, Registry)

Windows User Activity Artifacts Registry • LNK • Shellbags • Jump Lists • MRUs • SRUM • Profiles • EVTX

Windows Forensic Artifacts for User Activity (Where Evidence Lives, How It’s Parsed, and What It Can Support)

Windows generates a dense trail of artifacts that can support user activity timelines: what programs ran, what files were opened, what folders were browsed, what removable devices were attached, and when certain actions likely occurred. This page focuses on the most common “user activity” artifacts and the practical interpretation rules examiners apply. If you are looking for the broader process hub, start here: computer forensic experts.

What this guide covers

This is a technical, educational reference meant to help attorneys, IT leaders, and private clients understand artifact mechanics and limitations. It does not claim that any single artifact “proves” a user’s intent. Strong conclusions come from corroboration across multiple sources. For a high-level Windows overview first, see: Windows forensic analysis explained. For end-to-end services context, see: computer forensic companies.

Registry hives and high-value keys for activity reconstruction
Link (LNK) files: structure, fields, and common locations
Shellbags: how folder browsing can persist in the registry
Jump Lists: application “recent items” and embedded LNK records
MRUs: “most recently used” lists across Windows components
SRUM: system resource usage database and network/app usage tables
User accounts and profiles: how Windows maps users to artifacts

Internal navigation

Preservation fundamentals: evidence preservation and chain of custody. Imaging fundamentals: forensic imaging and acquisition. Reporting format context: computer forensic reporting explained.

Core principle: artifacts show observable traces. They do not automatically establish who physically touched the keyboard without additional corroboration.

Where Windows “user activity” evidence typically lives

For most examinations, user activity artifacts cluster into a few predictable areas: per-user profile directories, system registry hives, and system log databases.

User profiles: C:\Users\<username>\ (per-user artifacts, caches, “recent” data).
System hives: C:\Windows\System32\config\ (SYSTEM/SOFTWARE/SAM/SECURITY/DEFAULT).
Event logs: C:\Windows\System32\winevt\Logs\ (EVTX channels; auditing-dependent).
SRUM database: C:\Windows\System32\sru\SRUDB.dat (ESE database).
Recent/Jump Lists: %AppData%\Microsoft\Windows\Recent\ (per-user “recent” artifacts).

Path note: %AppData% typically expands to C:\Users\<username>\AppData\Roaming.

1) Registry hives (Windows’ configuration + activity substrate)

The Windows Registry stores configuration, per-user state, and many activity-linked records. A “hive” is a structured binary file containing keys and values. Keys have “last write” timestamps, and values store typed data (strings, integers, binary blobs).

System hives (machine-wide)

System hives live under C:\Windows\System32\config\ and can support hardware, services, and account mapping context.

SYSTEM: services, devices, network profiles, shutdown/startup context, control sets
SOFTWARE: installed software registrations, application settings, OS components
SAM: local account database and identifiers (limited without proper access)
SECURITY: security policy context; can contain highly sensitive structures
DEFAULT: default profile template behavior

Per-user hives (user state + activity)

Most “user activity” artifacts are tied to user hives, which live inside the profile folder.

NTUSER.DAT: C:\Users\<user>\NTUSER.DAT (per-user settings, MRUs)
UsrClass.dat: C:\Users\<user>\AppData\Local\Microsoft\Windows\UsrClass.dat
Key timestamps (“last write”) can support folder view updates, MRU changes, and other state updates

Interpretation note: a key’s timestamp is not a “user typed this at this second” event; it’s a registry structure update time.

2) Link (LNK) files (file-open evidence and target metadata snapshots)

Windows shortcut files (.lnk) can be created when a user opens a file via Explorer, recent items, Office, or application integrations. A single LNK can contain both link creation time and a snapshot of target information such as the target path and volume identifiers.

Common locations

Recent items: %AppData%\Microsoft\Windows\Recent\
Office recent (varies): often within user profile “Recent” subpaths or application-specific locations
Embedded inside Jump Lists (AutomaticDestinations contain LNK structures)

What a parser typically extracts

Target path context: local path, network share path, or device volume context (when present)
Volume identifiers: volume serial number and drive type metadata (useful for removable media correlation)
Target file timestamps: target MAC times captured at link creation (contextual; should be cross-validated)
Link timestamps: LNK file’s own timestamps plus internal link header timestamps (depending on parser)
Extra blocks: distributed link tracking and other extra data blocks (presence varies)

Forensic caution: LNK evidence is strong when corroborated (e.g., Jump Lists + registry MRUs + event log context), not when used alone.

3) Shellbags (evidence of folder browsing and view persistence)

“Shellbags” are registry-based records created by Windows Explorer to remember folder view settings (icons, column layout, last view). Because these records can persist even after a folder is deleted, they can support claims about historical folder interaction.

Where shellbags live

Common root areas in user hives include BagMRU and Bags keys.
Shellbag keys may exist in NTUSER.DAT and/or UsrClass.dat depending on Windows behavior and context.

What examiners parse from shellbags

Folder paths and identifiers: including special folders and sometimes external folder references
Hierarchy: BagMRU structure can reflect nested folder navigation patterns
Timestamps: key “last write” times can approximate when Explorer view state updated
View evidence: evidence of folder existence/interaction even if content later removed

Interpretation note: shellbags generally support “folder was browsed / view state persisted,” not “specific file inside the folder was opened.”

4) Jump Lists (application recent items, pinned items, and embedded LNK records)

Jump Lists are per-user records that support “recent items” menus for applications (taskbar/right-click lists). They are often one of the highest-value user activity artifacts because they link application usage to specific files.

Where Jump Lists are stored

Automatic destinations: %AppData%\Microsoft\Windows\Recent\AutomaticDestinations\
Custom destinations: %AppData%\Microsoft\Windows\Recent\CustomDestinations\

What the files contain

Application identity: Jump List files are tied to an application identifier (AppID) and reflect app-specific recent activity.
DestList records: a structured list that can include entry numbers, access counts, pinned flags, and timestamps (field names vary by parser).
Embedded shortcuts: automatic destinations commonly contain embedded LNK structures pointing to target items.

Practical use: Jump Lists are often used to demonstrate that a specific user profile accessed a specific file through a specific application context.

5) MRUs (Most Recently Used lists across Windows)

MRUs are “recent activity” lists stored throughout the registry and application data. They can show recent file paths, typed commands, or recently accessed folders. MRUs are highly useful but should be interpreted carefully: a record can reflect a dialog box browsing event, not necessarily a successful open.

Common MRU categories

RecentDocs: tracks recently accessed document names by extension categories (user hive)
Open/Save dialog MRUs: paths and PIDLs (pointer structures) reflecting where users browsed in file dialogs
Run dialog MRU: commands typed into the Run dialog (when present)
Typed URLs / browser adjacent MRUs: some URL/history artifacts live outside the registry (browser-dependent)

How MRUs are structured

Ordered lists: an “MRUList” or similar ordering field points to value entries in most-recent order
Value data: can be strings, binary blobs (PIDLs), or structured data (parser-dependent)
Key timestamps: key “last write” time can support when the MRU list was updated

Best practice: MRUs are most persuasive when they align with LNKs, Jump Lists, and file system metadata for the same targets.

6) SRUM (System Resource Usage Monitor: app and network usage evidence)

SRUM stores system resource usage telemetry in an ESE database. It can support questions such as: “Which applications were active?” “Was there network usage tied to specific app identities?” and “Which user context is associated with usage records?”

Where SRUM lives

SRUM database: C:\Windows\System32\sru\SRUDB.dat
SRUM is an ESE (Extensible Storage Engine) database with multiple tables and ID mappings.

What parsers commonly pull

App identity mappings: internal IDs mapped to executable/app identifiers (parser dependent)
User context: records tied to user IDs/SIDs where available
Network usage: bytes sent/received and usage windows (table/field names vary by Windows builds)
Time fields: stored in Windows timestamp formats; examiners normalize timezone and interpret with caution

Retention and availability vary by system configuration and usage. SRUM is not a replacement for firewall logs or proxy/VPN logs.

7) User accounts and profiles (mapping artifacts to people and logon context)

Many cases hinge on “which user did what.” Windows artifacts are usually tied to a user profile and a security identifier (SID). A defensible analysis begins by mapping accounts, profiles, and their artifact locations.

Profiles on disk

User profiles typically exist under C:\Users\. Each profile contains user-specific artifacts such as NTUSER.DAT, Jump Lists, browser profiles, and application caches.

Profile folder: C:\Users\<user>\
User hive: NTUSER.DAT in the profile root
UsrClass hive: ...\AppData\Local\Microsoft\Windows\UsrClass.dat

SIDs and account mapping

Windows uses SIDs to represent security principals. Many logs and artifacts reference SIDs; examiners map them to user names and profile paths.

ProfileList mapping: registry mapping of SID → profile path (commonly used for attribution)
Local vs domain context: local accounts differ from domain accounts in identifiers and management
Logon evidence: EVTX logs can show logon types and sessions when auditing exists

Attribution caution: even with a SID, shared credentials and remote sessions can complicate “who physically used the device.”

Other high-value Windows artifacts (often used for corroboration)

The artifacts above are core “user activity” sources. In many investigations, examiners also look for corroborating artifacts that add execution evidence, installation context, and file system change history.

Event logs (EVTX): C:\Windows\System32\winevt\Logs\ (availability depends on auditing and retention).
Prefetch: execution and run-count context for some systems (feature/configuration dependent).
Amcache / Shimcache context: installation/execution-adjacent traces used for corroboration (interpret conservatively).
USN Journal and file system metadata: can support change history narratives depending on file system and availability.
Browser profiles: Chrome/Edge/Firefox profiles often contain the clearest web activity evidence (app-dependent).

Artifact availability varies by Windows build, configuration, user behavior, and time elapsed. A defensible timeline is built from multiple independent sources.

Interpretation rules (how examiners avoid over-claiming)

Windows artifacts are powerful, but easy to misinterpret if treated as “single-source proof.” Common defensible interpretation rules include:

Corroborate: align LNK + Jump List + MRU + file system metadata where possible.
Time discipline: document timezone assumptions and consider clock drift or dual-boot/time sync anomalies when relevant.
Explain what the artifact represents: “folder view persisted” is different from “file opened.”
Document gaps: missing logs and overwritten artifacts are common; absence is not always meaningful.
Account for modern storage realities: SSD behavior can reduce deleted-data recoverability and shorten artifact lifetimes.

If the output will be used in litigation or HR action, reporting clarity matters. See: computer forensic reporting explained.

Continue learning (how artifacts tie back to the full workflow)

Artifact interpretation depends on upstream steps: preservation and acquisition quality shape what can be concluded. For the full hub overview, return to: computer forensics. For OS-level context and broader Windows structure, see: Windows forensic analysis explained.

Learn About Computer Forensic Services Windows Forensics Guide Imaging & Acquisition Explained Reporting Explained

Educational positioning: This page explains common Windows artifacts, typical storage locations, and cautious interpretation principles. It does not guarantee what will be present on any specific system.