Understanding Windows Jump Lists

Jump Lists shipped in Windows 7 to give users quick access to recently and frequently used files per application. For a DFIR analyst they are something else entirely: a per-user, per-application record of file interaction that survives the deletion of the target file and frequently survives the user's attempts to clear it. If you are not already pulling Jump Lists on every "what did this user touch?" engagement, you are missing the cheapest source of that answer.

Start with the primer on Windows Jump Lists if you came in cold. Otherwise, the short version is below.

Two files, two authors

• AutomaticDestinations (*.automaticDestinations-ms) — an OLE Compound File written by the shell. Each numbered stream is a Windows shell link (LNK). A single DestList stream orders them and records access timestamps, access counts, the originating NetBIOS hostname, and volume / object GUIDs. This is what Windows tells you about the user.
• CustomDestinations (*.customDestinations-ms) — a flat byte stream written by the application itself via ICustomDestinationList. Categories of LNK structures concatenated back-to-back, terminated by 0xBABFFBAB. This is what the application told the shell to show.

Both live under %AppData%\Microsoft\Windows\Recent\(Automatic|Custom)Destinations\ and use the same <AppID>.<extension> naming. The AppID is a truncated CRC64 over the executable path — same binary at the same path produces the same AppID on every machine, which is what makes published AppID lists useful for triage. See where Windows stores Jump List files for the per-user paths and acquisition notes.

What you actually get out of one

After parsing, per entry: the full target path (local, UNC or removable), three FILETIMEs from the embedded LNK header, a DestList access timestamp and count, the pinned flag, the NetBIOS hostname recorded at access time, the volume serial and label, command-line arguments and working directory if present, and the TrackerDataBlock with its droid GUIDs (which include the MAC address of the LNK-creating machine).

That set covers the questions the case actually asks: who opened it, when, from where, and from which physical disk. The hostname field is the one I reach for most often in lateral-movement work — the Jump List on the compromised endpoint remembers the staging server's NetBIOS name long after the staging server is gone.

Why parse in the browser

Chain of custody matters in DFIR. So does the fact that Jump Lists from regulated environments almost always contain user PII and document paths you do not want crossing a vendor boundary. The parser on this site compiles a Rust crate to WebAssembly and runs it entirely client-side. No upload, no server-side logging, no telemetry. Drop a file, get the parsed view.

For a side-by-side look at the other options (JLECmd, JumpListExplorer, Kacos2000's Jumplist-Browser), see the tools comparison. For a step-by-step investigation, the DFIR walkthrough is the next read. Trying to remove Jump List history instead? See how to clear or delete Windows Jump Lists — but read the section on what survives the clear before you trust it.

Further reading

• Yogesh Khatri and Mike Stevens, "Jumping into the Past" — original DestList reverse engineering.
• Eric Zimmerman, JLECmd and JumpListExplorer.
• For corroborating artifacts: LNK parser, Prefetch parser, AmCache parser, ShimCache parser, EVTX parser, MFT parser, USN journal parser.