Why are .lnk files such a rich forensic source?

Because they record not just where a target was, but where the link itself was created. A single .lnk preserves the originating machine's NetBIOS name, a MAC-derived droid GUID, the volume serial of the disk it lived on, the target's full local path and three FILETIME timestamps captured at link creation. All of that survives long after the target file is deleted.

Where does Windows create .lnk files automatically?

Several places: AutoDest jumplists at %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations, custom destinations at the sibling CustomDestinations folder, the Recent folder itself (one .lnk per recently opened item), Start Menu and Desktop shortcuts, and Office MRU lists. Every one of these is fair game in an investigation.

What's a droid GUID and why does it matter?

The droid GUID lives in the TrackerDataBlock and is generated from the link-creating machine's MAC address using a version-1 UUID scheme. Two droid GUIDs created on the same machine within seconds share most of the bits, including the MAC. Investigators correlate droids across .lnk files to cluster activity onto a single source machine, even if the user account or path differs.

Do .lnk timestamps update over time?

No. The three FILETIMEs in the ShellLinkHeader are a snapshot of the target's creation, access and write times at the moment the link was created. They do not track the target afterwards. A shortcut whose timestamps disagree with the current target tells you when the link itself was first written — often more useful than the live target metadata.

Why are .lnk files such a rich forensic source?

Because they record not just where a target was, but where the link itself was created. A single .lnk preserves the originating machine's NetBIOS name, a MAC-derived droid GUID, the volume serial of the disk it lived on, the target's full local path and three FILETIME timestamps captured at link creation. All of that survives long after the target file is deleted.

Where does Windows create .lnk files automatically?

Several places: AutoDest jumplists at %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations, custom destinations at the sibling CustomDestinations folder, the Recent folder itself (one .lnk per recently opened item), Start Menu and Desktop shortcuts, and Office MRU lists. Every one of these is fair game in an investigation.

What's a droid GUID and why does it matter?

The droid GUID lives in the TrackerDataBlock and is generated from the link-creating machine's MAC address using a version-1 UUID scheme. Two droid GUIDs created on the same machine within seconds share most of the bits, including the MAC. Investigators correlate droids across .lnk files to cluster activity onto a single source machine, even if the user account or path differs.

Do .lnk timestamps update over time?

No. The three FILETIMEs in the ShellLinkHeader are a snapshot of the target's creation, access and write times at the moment the link was created. They do not track the target afterwards. A shortcut whose timestamps disagree with the current target tells you when the link itself was first written — often more useful than the live target metadata.

Forensic analysis of .lnk files: what investigators look for

A .lnk is small, it survives independently of the target it points at, and it captures a precise snapshot of the source machine at the moment the shortcut was created. After enough cases you stop thinking of shortcuts as user-convenience clutter and start treating them as one of the cheapest pieces of attribution evidence Windows produces. This post is the practitioner's map of what to actually pull out, mapped to the binary sections defined by MS-SHLLINK.

The headline artifacts

Drop a real .lnk into the parser and these are the fields a DFIR analyst checks first.

Artifact	Lives in	Why it matters
LocalBasePath	LinkInfo	Full path on the originating machine; the username is usually inline.
VolumeID (serial, label, type)	LinkInfo → VolumeID	Identifies the disk. Same serial across multiple links means same drive.
CreationTime / AccessTime / WriteTime	ShellLinkHeader	Target's FILETIMEs captured at link creation. Survives target deletion.
Machine NetBIOS name	ExtraData → TrackerDataBlock	Hostname of the machine that wrote the link.
Droid and DroidBirth GUIDs	TrackerDataBlock	Version-1 UUIDs whose last six bytes are the source machine's MAC.
Command-line arguments	StringData (COMMAND_LINE_ARGUMENTS)	What the target was meant to run with. Phishing tell.
Working directory	StringData (WORKING_DIR)	Often reveals USB letters or staging folders.
Network share path	LinkInfo → CommonNetworkRelativeLink	UNC path. Preserves vanished shares.
ShowCommand / IconLocation	ShellLinkHeader / StringData	Hidden window plus spoofed icon equals strong malware signal.
LinkTargetIDList	After the header	Shell namespace walk; sometimes resolves when LinkInfo does not.

The whole list comes out of standard fields documented in [MS-SHLLINK]. The same parsers that read them work on .lnk files extracted from Jumplist compound files — those are LNK streams in an MS-CFB wrapper.

The TrackerDataBlock, in depth

The TrackerDataBlock is the most cited LNK artifact in DFIR work, and earns the citation. Its payload is two 16-byte GUIDs (Droid and DroidBirth) plus a NetBIOS name. Each GUID is a Microsoft Distributed Link Tracking identifier, a v1 UUID generated from:

a high-resolution timestamp (when the link was first written), and
the link-creating machine's MAC address — the last six bytes of the GUID.

That means a single .lnk can leak the MAC of the machine that created it. Investigators correlate droid GUIDs across thousands of shortcuts to:

Cluster activity onto one originating host even when filenames and paths differ.
Identify the link source when only the .lnk survives.
Catch attribution mistakes — multiple public threat-actor attributions originated from .lnk files that leaked the attacker's build VM. The Lazarus / APT37 / APT41 reports are public examples.

MAC randomization, virtual NICs and modern Windows builds can break this in some cases. The artifact still appears in the majority of real-world samples I have parsed.

Where Windows writes shortcuts for you

The user-created shortcuts on Desktop and Start Menu are obvious. The interesting ones are the shortcuts Windows writes automatically:

%APPDATA%\Microsoft\Windows\Recent\ — one .lnk per recently opened item. Near-complete usage history. Pair with the registry parser for the matching RecentDocs keys in NTUSER.DAT.
%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\ — AutoDest Jumplist files. MS-CFB compound files holding numbered LNK streams plus a DestList stream with access timestamps, counts, and the originating NetBIOS hostname.
%APPDATA%\Microsoft\Windows\Recent\CustomDestinations\ — application-curated Jumplists. Flat byte stream, concatenated LNKs, terminated by 0xBABFFBAB.
%APPDATA%\Microsoft\Office\Recent\ — Office's parallel MRU.
Removable media themselves — Windows often writes .lnk shortcuts back onto USB drives when they are plugged in. Those are recoverable from the drive long after the host that created them is gone.

Every one of these is a recoverable timeline source even when the target is deleted.

Workflow

A typical investigative pass on collected .lnk files:

Parse and normalize. Convert every shortcut to a structured record with the fields above. LECmd --csv, lnkinfo from libyal, or lnkparse3 for Python integration. Decide on one tool's output schema and stick to it across the case.
Pivot on droid GUID. Group by source MAC. Rule in or rule out per-machine activity. A single droid showing up on shortcuts from multiple user profiles is a strong attribution signal.
Pivot on volume serial. Identify the disk lineage. Same serial across multiple links means the same drive across time. Different serials with the same drive letter means removable media.
Build a timeline. The header FILETIMEs are the link's snapshot of target metadata. Combine with the link's own MFT entry for the link-write time and the USN journal for create/delete events on the link itself.
Cross-reference. Prefetch, ShimCache, AmCache, Jumplist DestList rows, Office MRUs, browser history. The strongest claims have at least two sources.

What the parser exposes

The parser on this site decodes every field above. Inspection runs locally in WebAssembly — useful when you need quick triage on a file someone just emailed you and you do not want the NetBIOS name, MAC-derived GUID and target path leaving the machine. The output groups the data by section — header, LinkTargetIDList, LinkInfo, StringData, each ExtraData block — so the read matches the order of the spec.