Jump Lists From the Attacker's Side: Recon, Spoofing, Cleanup

Most Jump List writing is defensive, which leaves a gap: if you only ever read the artifact as an investigator, you miss what someone on the other side does with it. This is the offensive view, written for defenders and authorized testers. Knowing the moves is how you recognize them, and a couple of them are quieter than the literature suggests.

Everything here is detectable. I will say where, because the point is not "look how sneaky," it is "here is the residue."

Reading them is the cheapest recon there is

Before anyone deletes anything, the first attacker value is just reading. A user's AutomaticDestinations folder is an annotated map of what they work on. Recently opened documents by name and path. The DestList hostname field hands over the names of file servers and the shares mounted off them. Volume labels and GUIDs flag removable media that has been plugged in. Office and Explorer Jump Lists in particular tend to point straight at the sensitive shares an operator wants to find.

None of this requires elevation. The files live in the user's own profile and are readable as that user. So an attacker who has landed as a normal user, with no privilege escalation yet, can read the Jump Lists and learn where the interesting data lives and which servers to pivot toward. It is living-off-the-land discovery with no tooling, no LOLBins, nothing that lights up an EDR's process tree.

This maps to ATT&CK T1083 File and Directory Discovery, and from the defensive side it is awkward, because reading a file in your own profile is not an event most stacks alert on. The realistic detection is downstream: the access of the target shares the attacker learned about, not the reading of the Jump List itself.

Spoofing and planting

The format is documented, the file is not signed or authenticated, and the AppID is only a CRC-64 hash used as a filename (the AppID post covers why that matters). So the contents can be forged.

Two flavors. The attacker edits a real Jump List to insert entries that point somewhere misleading, a planted path implicating another user or another host, a fabricated hostname in a DestList row to misdirect a lateral-movement investigation. Or they drop a whole file named for a benign application, pre-filled, to manufacture a history that never happened. Because the shell does not validate the AppID against anything, a file named for Notepad does not have to have come from Notepad.

This is real, and it is also where attackers get caught, because hand-editing the binary structure is easy to get subtly wrong. Each DestList entry carries an integrity value most DIY scripts do not recompute. The header keeps a monotonic entry-ID counter that has to stay consistent with the rows. Edit timestamps without understanding the MRU ordering and the timestamp order contradicts the entry-ID order. Every one of those is a tell, and they are exactly what the timeline and anti-forensics post teaches you to look for. The planted content can still fool an analyst who takes the file at face value under time pressure, which is the whole bet the attacker is making.

Persistence: mostly overstated

You will occasionally see Jump Lists listed alongside persistence mechanisms. Be skeptical. A Jump List is not an autostart location. Windows does not execute anything in AutomaticDestinations on boot or logon. There is no Run key behavior here.

The grain of truth is in CustomDestinations. Those are the pinned and task entries an application defines, and a pinned entry is a shortcut that points at a target the user might click. An attacker who can write a user's CustomDestinations could pin an entry whose target is a malicious payload or a UNC path, sitting in the Jump List waiting for a click. That is a social-engineering vector, not persistence in any meaningful sense. It does not survive as code execution, it depends entirely on the user clicking it, and there are a dozen more reliable ways to get a malicious shortcut in front of a user. If you are building a detection program, do not spend persistence-hunting budget here. Spend it on the autostart locations that actually execute.

Cleanup, and why it rarely works cleanly

The last attacker move is removal, and the clear or delete guide covers the mechanics from the user side. Operationally the attacker has the same blunt options anyone does: toggle the recent-items setting, delete the per-AppID files, or run a cleaner. ATT&CK files this under T1070 Indicator Removal.

It rarely works cleanly, and a tester should know why so they can advise the blue team where to look. Deleting the file does not erase the history so much as relocate the evidence: the recreated file's recent MFT creation time gives away when the old one died, the write passes through the USN journal with a timestamp, and Volume Shadow Copy has very likely snapshotted the original out of reach. Selective surgery on a single entry leaves structural inconsistencies, a DestList row pointing at a stream that no longer exists, or an orphaned stream with no row. The cleanup that looks complete on the live volume is usually the one that left the most corroborating trace somewhere the attacker did not think to clean.

The defender's takeaway

Read the offensive moves backwards and they become a detection list. Watch for access to shares and files that a host's Jump Lists name, because that is recon paying off. Treat a Jump List on a host you already suspect as a claim to verify against independent artifacts, not as ground truth, because it may have been planted. Do not waste persistence-hunting effort on AutomaticDestinations. And when a Jump List looks suspiciously clean, go to the shadow copies and the USN journal first, because that is where the thing the attacker tried to remove is still sitting.