What can a forensic analyst learn from Jump Lists?

The target path of each opened file, the last-access timestamp and access count, and the NetBIOS hostname of the machine that originally held the file.

Do Jump Lists record file access from network shares?

Yes. The DestList stream stores the originating NetBIOS hostname for every entry, which makes Jump Lists a strong source for tracking remote file access and lateral movement.

How do I parse a Jump List file?

Use Eric Zimmerman's JLECmd for command-line triage and Jumplist Explorer for interactive analysis, or drop the file on this site to decode it in the browser without uploading.

Can a user delete their Jump List history?

Yes — the Settings UI has a toggle to hide recent items, and the files themselves can be deleted. Windows recreates them on the next interactive use, so absence of older entries is itself an indicator.

Jump List Forensics: A Practical DFIR Walkthrough

Jump Lists answer a question other artifacts dance around: which application opened which file, on which host, at which time. After enough cases you stop reaching for ShellBags or Prefetch as the first move on a "what did this user touch?" question and start with AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\. The fields you care about are inside, every time, on every Windows version since 7. This is the workflow I run.

What the artifact actually gives you

Per entry, after parsing:

Full target path of the opened item — local, UNC, or removable.
Last-access timestamp (FILETIME, UTC) and a per-entry access count. The count is a float; pinned entries store a sentinel instead.
NetBIOS hostname of the machine recorded at the time of access. This is the field that matters for lateral movement.
Pinned state. Pinned means the user actively clicked "Pin to this list".
AppID, which deterministically maps to the launching application (truncated CRC64 over the executable path).
Volume ID and volume label from the embedded LNK. Useful for removable-media correlation.
Three FILETIMEs from the LNK header — creation, access, write time of the target as seen when the LNK was written. They snapshot the moment, then never update.
Command-line arguments and working directory when present.

A 5-step DFIR workflow

Acquire. Pull %AppData%\Microsoft\Windows\Recent\AutomaticDestinations\ and the sibling CustomDestinations\ folder for every user profile. Live files are typically locked by explorer.exe, so work from a forensic image, a VSS snapshot, or a tool that handles the lock correctly. KAPE has a target for this; otherwise robocopy /b from a mounted shadow copy works. Do not copy live with plain xcopy.
Triage by AppID. List the AppIDs (filenames minus the extension) and map them to applications. The AppID list shipped with JLECmd is the de-facto reference. Anything unmapped is worth a closer look — custom and portable apps generate their own AppIDs, and so do attacker tools that registered as shell-aware. An unfamiliar AppID with a recent DestList row is a lead.
Parse. Extract every numbered LNK stream and the DestList rows. JLECmd produces CSV or JSON for batch work. JumpListExplorer (the Eric Zimmerman GUI sibling) is the right tool for interactive review. Plaso / log2timeline emits timeline events. Autopsy surfaces them as ingest results. For one-off review without moving the artifact off the analyst workstation, the in-browser parser on this site runs the same logic client-side and never uploads.
Correlate. Line up DestList access timestamps with the user's interactive session timeline. The pivots that actually work:
- Security.evtx 4624 / 4634 / 4647 for logon and logoff windows (see the EVTX parser).
- The UserAssist key in NTUSER.DAT for GUI launches (see the registry parser).
- Prefetch hits for process execution.
- The USN journal for create/access events on the target file.
- AmCache and ShimCache for the executable itself.
- SRUM for network and CPU usage of the launching application.
- A RAM dump via Volatility if you have one, to confirm the application was resident at the time.
Report. Cite each finding by source file, stream number, and DestList entry ID — for example, 1b4dd67f29cb1962.automaticDestinations-ms, stream 7, DestList entry 0x12. Reproducibility is what makes the finding hold up under review. "The Jump List showed it" is not a citation.

The hostname field, and why it earns its keep

Every DestList row carries the NetBIOS hostname recorded when the target was opened. On a workstation that mounts shares from multiple servers, that field reveals which server held each opened document — without needing the server's own logs. In lateral-movement investigations, a Jump List on a compromised host frequently contains the attacker's staging server name long after the share has been unmounted and the server reimaged.

I have closed cases on this single field. An RDP-jumped user opens a file from a staging host, the attacker tears down the staging host, the SOC has nothing. The compromised endpoint's automaticDestinations-ms for Notepad still has the NetBIOS name and the volume GUID six weeks later.

Common pitfalls

FILETIME math. 100-nanosecond intervals since 1601-01-01 UTC. Convert with unix_seconds = (filetime / 10_000_000) - 11_644_473_600. Off-by-one-day errors here are the most common source of bad timelines I review.
DestList version skew. Win7 wrote version 1. Win10 and Win11 commonly emit v3 or v4. Row sizes and field offsets shift. Older parsers that hardcode v1 layout will silently misalign on modern hosts and you will spend an hour wondering why the hostnames look like garbage.
Pinned entries inflate counts. Some applications (Office, Explorer) pin items aggressively and bump access counts on background indexing. A high count is not by itself proof of repeated user interaction. Cross-check with Prefetch and UserAssist.
"Show recently opened items" toggle. Disabling it under Settings → Personalization → Start truncates the per-AppID files. The files are recreated on next use, so unexpectedly short DestLists with all timestamps clustered around the same recent date are an indicator the user (or something pretending to be the user) flipped the toggle.
Pinned customDestinations-ms entries survive resets. Useful — a pinned UNC path is intent. Note them separately from MRU evidence in the report.
AppID collisions are rare but real. Two installations of the same executable at the same path produce the same AppID. If you are working a multi-tenant Citrix or VDI environment, expect overlap; rely on the hostname field and the LNK's TrackerDataBlock to disambiguate.

A finishing pivot

Once you have a list of suspect entries, take the LNK's TrackerDataBlock droid GUID and pivot through every other LNK on the host (Desktop, Start Menu, Recent\, both Destinations folders). Same droid means same source machine. Different droid in the same Jump List means the file was opened on more than one host and Windows preserved both versions. That second case is unusual and almost always interesting.

Drop a file on the homepage to see all of this without sending data anywhere. For the byte-level reference, the automaticDestinations file format post is the next read.