ShellBags and User Navigation: What Windows Remembers About Exploration

ShellBags are often treated as proof of access to a directory, proof of awareness of a file, or proof of intent. None of those claims are defensible on ShellBags alone.

ShellBags are better understood as Windows remembering where the shell has been asked to render a folder view for a user. That can be strong evidence of navigation and exploration. It can also be weak evidence of anything beyond that, depending on how the interaction occurred, what the environment looks like, and what else you can line up around it.

This post applies the reasoning model introduced in the broader Windows Artefacts as Evidence series. The point isn’t to be cautious for its own sake. The point is to be accurate, to draw conclusions you can support, and to recognise where an artefact’s ambiguity is a feature of the operating system, not a failure of your analysis.

In this article, we’ll cover:

• What ShellBags record on Windows 10 and 11
• How ShellBag entries are created through shell-mediated interaction
• Why navigation isn’t the same as access or execution
• How to use ShellBags as a guide for corroboration
• What ShellBag absence can and can’t support

Remember the Mindset: Evidence, Not Indicators

When analysts treat artefacts as indicators, they tend to compress meaning. An entry exists, so the user did the thing. A timestamp exists, so the event happened at that time. A folder appears, so the user must have opened files within it.

That compression is tempting because it makes narratives tidy. It’s also where a lot of investigative error starts.

Treating artefacts as evidence forces two habits that matter here.

First, you describe what you can actually support from the artefact itself. Then you describe what you can infer, and under what conditions. That separates observations from interpretations.

Second, you deliberately look for corroboration and negative space. If ShellBags suggest navigation into a sensitive directory, you look for supporting traces of what might have happened next. If ShellBags suggest the user never navigated there, you look for alternative pathways that would bypass ShellBags entirely.

ShellBags are a good case study because the artefact is common, it persists, and it sits at a behavioural boundary that analysts often overstate. It’s about navigation, not access. It’s about exploration, not execution. And it’s about shell-mediated interaction, not all interaction.

Those distinctions sound academic until you try to defend a conclusion in a report or in a dispute. Then they become operational.

What ShellBags Represent in Practical Terms

ShellBags exist because Windows tries to make folder browsing feel consistent. When a user opens a folder in File Explorer or interacts with a folder through common shell dialogs, Windows stores view preferences so it can restore them later. That includes choices like layout and sorting. The mechanism that stores those preferences is what forensic tooling calls ShellBags.

From a DFIR perspective, this gives you a by-product: a durable record of which folders the shell has been asked to present to that user.

This is the first key constraint. ShellBags are a record of a particular interface path. They reflect the shell’s view of the filesystem and shell namespace. They don’t reflect every way a user or process could interact with a directory.

That makes ShellBags powerful when your investigative question is about GUI navigation. They’re less useful when your question is about file access more broadly. They can still contribute, but only if you keep the interface boundary clear in your reasoning.

A second constraint follows from the first. ShellBags are folder-centric. They don’t tell you which files were opened, which files were executed, and they don’t tell you whether anything was copied, modified, or deleted. If you want those answers, ShellBags can guide where to look and help you reason about plausibility, but they won’t provide proof.

A third constraint is that ShellBags aren’t a linear event log. They are state. State changes can contain temporal clues, but the artefact isn’t designed to preserve a complete timeline of every interaction. It remembers seen folders and recently navigated structures. That distinction matters when people try to extract precise times.

These constraints don’t make ShellBags unreliable; they make them specific. Used for what they actually represent, ShellBags can be some of the strongest evidence you have for exploration of folders that no longer exist, were later deleted, or live on removable or network media.

Where ShellBags Live, at a High Level

ShellBags are stored per-user, primarily in the user’s registry hives. Practically, that means you’re usually dealing with NTUSER.DAT and UsrClass.dat for a given profile. ShellBag data in the registry looks like this:

In modern Windows, ShellBag-related data is split across locations that broadly correspond to different classes of shell interaction. The details vary across Windows versions and can be influenced by application context, but the main point is this: if you only check one hive, you’re likely to miss part of the picture. The most common locations in modern operating systems are:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam

The right way to think about location isn’t which key, but which user and which context.

If your question is did this user browse this folder on this endpoint through the shell, you need that user’s hives from that endpoint. If your question is does the user’s profile carry evidence of shell navigation across systems, you need to consider roaming and synchronisation behaviours and whether you’re looking at a profile copy or the live endpoint.

That distinction becomes important in enterprise environments where profiles roam, are cached, or are partially virtualised. ShellBag evidence is often interpreted as inherently local, but elements can persist across sessions and sometimes across devices depending on configuration. When the environment supports that, your analysis should explicitly acknowledge it.

How Entries Are Created: Behavioural Triggers, Not Registry Mechanics

ShellBag entries appear when the shell enumerates a folder in a way that causes Windows to remember view state.

The simplest trigger is the obvious one: a user opens File Explorer and navigates into a folder. Windows remembers that folder so it can restore view settings later. That act of browsing is what you’re looking for in an investigation.

The next most common trigger is the file dialog path. Most applications use the standard Open and Save dialogs, which are shell components. When a user navigates through those dialogs, Windows might still remember folder view state and therefore create or update ShellBag entries. The user might never have opened File Explorer at all.

That’s a recurring source of misunderstanding. Analysts sometimes assume ShellBags imply File Explorer usage. What ShellBags imply is shell-mediated folder rendering. File Explorer is one common consumer of that mechanism, but not the only one.

There are also behaviours that create entries for intermediate folders in a path. A user can arrive at a deep folder, and the shell will materialise a hierarchy that includes parent folders. Depending on how the navigation occurred, Windows might store information for the intermediate folders even if the user didn’t intentionally “open” them in a way that involved browsing their contents.

This is where “navigation versus access” becomes practical. ShellBags can show you that the shell dealt with a folder as part of a path. That’s evidence of navigation context, which is weaker evidence of user interest in that folder’s contents.

One more nuance matters in real investigations. A ShellBag entry can exist even where the user did not successfully browse the folder contents, such as when access was attempted but blocked. In those cases, you might see traces of the folder’s existence in the navigation record without the stronger signals you’d expect from a normal folder view.

You don’t need to memorise the internal structures to use this well. You need to adopt the habit of asking: what kind of shell interaction would produce the state I’m looking at, and what other observations would distinguish between competing explanations?

What Information is Recorded, Conceptually

ShellBags record two kinds of information that matter to an analyst.

The first is identity. The artefact contains enough information to represent the folder within the shell namespace. That includes names and, for filesystem-backed folders, identifiers that allow tooling to reconstruct paths and sometimes preserve links to filesystem metadata. This is why ShellBags can remain useful after folders are deleted; they’re not a live directory listing, they’re a remembered navigation structure.

The second is view state. Windows remembers folder preferences so the next time the folder is shown, it looks the same. This is where analysts tend to find the most defensible “depth” indicators. If the record shows that view settings were customised, that implies the folder wasn’t just brushed past. It implies that the folder’s contents were rendered to a level where preferences could be applied.

This isn’t proof of intent, but it is often a more meaningful signal of interaction than the mere presence of a folder entry.

It also supports a more careful way of writing conclusions. Rather than asserting the user accessed the folder, you can sometimes say something like:

The shell rendered this folder for the user, and view state indicates the folder was displayed in a context where customisation could occur.

That’s still cautious, but it’s far more defensible, and it points the reader to the basis for the assessment.

Timing: Why it’s Tempting, and Why it’s Tricky

Most modern tooling presents first interacted and last interacted style fields for ShellBags. Those outputs are useful, but they can encourage overconfidence if you treat them as native timestamps describing discrete events.

ShellBags aren’t an event log. They’re a set of keys and values that Windows updates when state changes. What you often have access to are registry last-write times for those keys, MRU ordering information, and timestamps embedded in the remembered folder metadata.

Those sources can support temporal reasoning, but you need to be explicit about what they represent.

A key last-write time can reflect when an entry was created, or when MRU order changed, or when a child relationship changed, or when view state was updated. Those are different user behaviours. They have different investigative weight. They shouldn’t all be treated as the folder was opened at this exact time.

Similarly, if tooling derives a last interacted time from a last-write of a parent structure that moved a folder to MRU position zero, then what you have is evidence the folder was most recently navigated within that parent context at or before that time. It’s not a guarantee the user opened it at that precise minute. It’s also not necessarily comparable across unrelated parts of the tree.

This is where timeline alignment comes in. The more defensible approach is to treat ShellBag time data as bounding information and then align it with independent timeline sources.

If a ShellBag suggests navigation into a directory around a particular time, you check whether the user was logged on, whether there’s interactive session activity, and whether other artefacts in the same timeframe support the idea of exploration. If ShellBag timing conflicts with a user’s logon history, you don’t discard the artefact. You revisit your assumptions about what the timestamp means and whether the environment could produce delayed writes, profile sync effects, or activity under a different account.

In practice, the timing value of ShellBags often comes from consistency rather than precision. If multiple folder entries in a relevant subtree show state changes clustered in a window that also contains other interactive artefacts, you can describe that as a navigation episode. That’s often more useful than chasing a single timestamp as if it were a discrete event marker.

Navigation is Not Access, and Exploration is Not Execution

This is the central analytical boundary ShellBags force you to respect.

Navigation, in this context, is the shell presenting a folder. It’s the user arriving at a location in the UI. It may be deliberate or incidental, deep or shallow, but it’s about where the user went.

Access is what happened to files and data. Access includes reading, copying, modifying, and deleting. Many forms of access don’t require shell navigation. Many forms of shell navigation don’t result in meaningful file access.

ShellBags sit on the navigation side. They’re not access artefacts.

Exploration is a subset of navigation. It involves curiosity, searching, browsing across directories, or moving through a tree to understand what’s present. ShellBags can be strong evidence of exploration when you see breadth and structure consistent with “looking around,” especially when paired with other signs of user-driven activity.

Execution is different again. Execution is a program or script running. Execution can follow exploration, but it can also occur without it. A user can execute a file directly from a known path. An adversary can execute remotely without any GUI interaction. A scheduled task can run without user presence.

When analysts conflate these concepts, they tend to overreach. A ShellBag entry in a malware staging directory doesn’t mean malware was executed. It might mean the user browsed into that directory. It might mean an application opened a dialog pointed there. It might mean an investigator later browsed it under another account. None of those are execution. If you need to speak to execution, you should look to execution-related artefacts and then use ShellBags only as supporting context.

If you keep these boundaries explicit in your narrative, your conclusions become clearer and harder to dispute. You also stop asking ShellBags to answer questions they were never capable of answering.

Corroboration: Using ShellBags as a Guide, Not a Verdict

ShellBags are most valuable when they help you choose where to look next and how to interpret what you find.

A common investigative situation is a sensitive folder that no longer exists. Perhaps a user claims they never knew it existed, or an attacker is suspected to have staged files in a directory that was later removed.

If ShellBags show that the folder was rendered for that user, you now have evidence that the folder existed at a point in time and was navigated to via the shell. That narrows your hypothesis space. It can support claims of awareness. It can also suggest that the user was in a position to see what was inside, though it still doesn’t prove what they did with the contents.

At that point, corroboration should be targeted. You’re not looking for “more artefacts in general.” You’re looking for artefacts that speak to the next question in your reasoning chain.

If your next question is file opening, look for file-open artefacts. Link files in the Recent folder, Jump Lists, application-specific recents, and similar traces can support file selection and opening events. If your next question is copying to removable media, you look for device connection records, copy-related timestamp changes, and other traces that link the navigation window to data movement.

If your next question is execution, you look for artefacts that speak to execution, like Prefetch, Shimcache, Amcache, and other relevant traces depending on the case. ShellBags can help you contextualise why a user might have arrived at an executable, but they should not be used to imply execution.

Corroboration also includes checking the account context. ShellBags are per-user. If you see suspicious navigation under an administrator profile, that’s evidence about the administrator’s session, not the standard user’s. In many investigations, this is where the story changes. The apparent “user activity” becomes “IT activity” or “attacker activity under an elevated account.” That distinction can matter more than any single artefact.

Negative Space: What it Means When ShellBags Are Absent

Analysts are often uncomfortable with absence because it feels like a lack of evidence. In reality, negative space is one of the most useful analytical tools you have, as long as you treat it appropriately.

If a directory is central to a hypothesis and there are no ShellBag traces of navigation into it for the relevant user, that might support the idea that the user didn’t interact with it via the shell. That’s not the same as the user didn’t access it. It’s narrower.

The value comes from what it forces you to consider next.

If the user didn’t use File Explorer, what else might they have used? Command line navigation doesn’t generally produce ShellBags. Scripting doesn’t. Many remote access methods don’t. A browser can be used to view local paths without involving Explorer’s folder view mechanisms. Third-party file managers can bypass ShellBag creation. Even within Windows-native tools, there are mechanisms that don’t involve the same view-state persistence.

So negative space should prompt alternative hypotheses. It should also prompt you to check whether ShellBags are likely to be complete in this environment. If you’re missing one hive, or you only have a roaming profile copy, or profile artefacts were cleaned, absence is less meaningful.

A careful way to write this up is to tie your conclusion to what you actually tested. For example:

No ShellBag entries for this path were present in the user’s available hives on this endpoint. This reduces support for the hypothesis that the user navigated to the directory via Explorer or standard shell dialogs on this system. It doesn’t exclude access via command line, scripts, or other non-shell mechanisms.

That language is restrained, but it’s also operational; it tells the reader what the evidence does and does not constrain.

Common Reasoning Errors, Embedded in Practice

Most ShellBag mistakes aren’t about misunderstanding the registry. They’re reasoning mistakes.

One is treating a folder entry as proof of file activity. This often appears in reports as “the user accessed the folder containing X, therefore they accessed X.” The reasoning gap is that folder navigation doesn’t specify file selection. In many directories, the default view shows only a subset of files, and many users navigate without opening anything. If you want to speak to file activity, you need file-level corroboration.

Another is reading intent directly from presence. A user may have navigated into a folder because it was suggested by an application dialog, because it was a default location, because they followed a shortcut, or because they mis-clicked. ShellBags can support awareness of a folder’s existence in some contexts, but inferring motive requires more. If intent matters, you need context and pattern.

A third is treating timing outputs as event times. A derived last interacted field can be valuable, but it’s not a transaction log. If you want to tie folder navigation to a particular moment, you should align ShellBag-derived timing with other independent sources that anchor user activity in time.

A fourth is assuming uniform behaviour across Windows versions and configurations. ShellBag creation triggers have varied over time, and enterprise environments introduce their own wrinkles through profile management, virtualisation, and policy. If your case depends on a subtle interpretation, it’s worth validating behaviour in a lab that matches the OS build and configuration as closely as possible. That’s not busywork, it’s how you avoid turning a community assumption into a case conclusion.

A final, quieter error is treating ShellBags as purely user-driven. They’re stored per-user, but that doesn’t mean the user had meaningful agency over every interaction. A program can open a dialog pointed at a location. The shell can render default views. The boundary you should care about is not “user versus process” in the abstract. It’s “what kind of interaction does this artefact actually record.”

If you consistently ask that question, most ShellBag interpretation problems resolve themselves.

Environmental Realities That Change the Meaning

ShellBags are shaped by environment. The same artefact pattern can mean different things depending on how the endpoint is configured and how the user works.

On shared machines, multiple people might operate under the same account. ShellBags then represent the account’s navigation history, not a unique person’s. You might still be able to reason about likely ownership by aligning with logon sessions and other user-specific behaviour, but you shouldn’t assume identity.

In environments with roaming profiles or profile containers, you need to understand where you obtained the hives and what they represent. If a hive is synchronised across devices, an entry could have originated elsewhere. If a hive is local-only, absence might reflect that you’re looking at the wrong endpoint. This is why which system did this occur on is sometimes a separate question from did the user do this at all.

Removable and network media add further complications. ShellBags can preserve navigation evidence after the media is removed. That’s often exactly what you want. But identification of the resource might require more care, especially if labels were reused or drive letters changed. In those cases, you treat ShellBags as a pointer and then corroborate with device history and other related artefacts to avoid conflating two similar devices.

Finally, don’t ignore the possibility of deliberate avoidance. It’s not uncommon for adversaries and some insiders to avoid Explorer specifically because it leaves familiar traces. If your case includes other indicators of activity but ShellBags are unusually sparse or clean, it might be worth considering whether non-shell mechanisms were used intentionally.

That doesn’t mean you treat absence as proof of anti-forensics. It means you keep the hypothesis available and test it against the rest of your evidence.

A Defensible Way to Talk About ShellBags in Findings

When you report ShellBag analysis, aim for language that reflects what the artefact actually supports.

A strong, defensible statement is usually along the lines of:

The user account’s shell state indicates that the directory was rendered through Explorer or a standard shell dialog.

If you have supporting view-state indicators, you can add:

View state was recorded for the folder, consistent with it being displayed in a context where folder contents were available.

If timing matters, you can say:

Registry state changes associated with this entry occurred within the window X to Y.

and then explain how you anchored that window and what you used to corroborate it. If your tooling provides first/last interacted, treat those as derived observations and, where possible, explain what they’re derived from rather than presenting them as primary timestamps.

If you need to speak to what happened next, use ShellBags as an entry point. “Following this navigation evidence, we identified corroborating file-open artefacts for specific documents in the directory” is far more defensible than implying those opens from ShellBags alone.

If you have negative space, describe it with the same care. “No shell navigation evidence was identified for this directory under this user on this endpoint” is useful when paired with what it does and does not exclude.

This style of writing isn’t just cautious, it also communicates to your reader that you understand the operating system behaviours you’re describing. That increases trust in the rest of your analysis.

What Windows Remembers, and Why the Distinction Matters

ShellBags record where Windows remembers a user has navigated through shell-mediated interfaces. They reflect exploration and interaction with folder views. They persist beyond deletion and disconnection, which makes them valuable for reconstructing historical navigation.

They don’t record file access. They don’t record execution. They don’t prove intent.

That distinction matters because it changes what you can responsibly claim. It changes how you corroborate. It changes how you use absence. It also changes how you build a narrative that can withstand scrutiny.

If you treat ShellBags as evidence of navigation, they become one of the cleaner ways to answer where did the user go in the UI, and what might they have been looking for. If you treat them as indicators of access or intent, they become a source of overreach.

The practical skill here is analytical restraint. You should be able to look at a ShellBag entry and say, with confidence, what it supports and what it doesn’t. Then you should be able to use it to guide targeted corroboration, align it to a timeline with appropriate caution, and make conclusions that remain accurate even when challenged.

That’s the difference between artefacts as indicators and artefacts as evidence. ShellBags make the boundary visible.

In the next post, we’ll shift from where the user navigated to what they likely selected and returned to.

Recent Files and Jump Lists sit closer to application behaviour than shell state. They can add file-level context to a ShellBag-driven story, but they come with their own bias. They record what applications choose to remember, not everything a user touched.

That makes them a useful companion to ShellBags. ShellBags can help you identify the directories a user explored. Recent Files and Jump Lists can help you test what that exploration turned into, and where the user returned repeatedly.

We’ll work through that boundary next.

You can follow the full series here: Windows Artefacts as Evidence.

References

1. Windows ShellBag Forensics – Harlan Carvey
2. Windows Registry Forensics, Part 2: Shellbags – Harlan Carvey
3. The Windows Shellbag: What It Is and How It’s Used – Andrew Case
4. Registry Explorer and Shellbags: What They Can (and Can’t) Tell You – Eric Zimmerman
5. Shellbags: Evidence of User Interaction – Corey Harrell
6. The Truth About Shellbags (And Why They’re Often Misinterpreted) – Doron Davidson
7. Shellbags: User Access or User Awareness? – Matt Suiche
8. Windows Explorer Artifacts (Shellbags, Jump Lists, LNKs) – David Klein
9. Shellbags in Windows 10 and 11 – Behavioural Testing Notes – AboutDFIR