LNK File Documentation

---

Technical details

Feature	Value
Full name	Windows Shell Link (Shortcut)
File extension	.lnk
MIME type	application/x-ms-shortcut
Format type	Binary shell-link metadata (a pointer, not a document)
Developer	Microsoft
Introduced	1995 (Windows 95)
Specification	[MS-SHLLINK] Shell Link Binary File Format (published 2010)
Open standard	Partial — documented by Microsoft, but Windows-specific
Byte order	Little-endian
Header size	76 bytes (0x0000004C)
Magic number	4C 00 00 00 followed by CLSID 00021401-0000-0000-C000-000000000046
Stores	Target path, arguments, working directory, icon, hotkey, window state
Forensic metadata	Volume serial number, NetBIOS name, timestamps, sometimes MAC address
Created automatically in	%AppData%\Microsoft\Windows\Recent, Start menu, desktop, taskbar
Extension visibility	Always hidden by Windows (NeverShowExt registry flag)
Association key	HKCU\...\Explorer\FileExts\.lnk\UserChoice
Security note	Common malware delivery vector (can launch cmd/PowerShell)
Related extensions	.url, .pif, .desktop
Specification URL	learn.microsoft.com/openspecs/windows_protocols/ms-shllink

What is a LNK file?

LNK is the Windows Shell Link format, the binary structure behind every shortcut on a Windows system. Microsoft introduced it in 1995 with Windows 95, and it has backed the desktop, Start menu, taskbar and the “Recent items” list ever since. A shortcut is not a copy of anything: it is a small record that points at a target (a program, a document, a folder, or even a Control Panel item) and stores how to launch it. The binary layout was published by Microsoft in 2010 as the open specification [MS-SHLLINK], so the format is fully documented even though it is Windows-specific.

Windows hides the .lnk extension unconditionally. The lnkfile type carries a NeverShowExt registry value, which overrides the “show file extensions” setting, so a shortcut shows only its name and a small curled-arrow overlay on the icon. That invisibility is convenient in normal use and dangerous in a hostile one: a file named invoice.pdf.lnk displays as invoice.pdf. Everything below describes what is actually inside the file, section by section, and why those fields make LNK both a forensic goldmine and a favourite of malware authors.

The ShellLinkHeader: 76 fixed bytes

A shell link begins with a fixed 76-byte header. Every multi-byte integer in the format is little-endian. The header both identifies the file and, through a flags field, declares which optional sections follow it.

ShellLinkHeader (76 bytes, offset 0)
  0x00  HeaderSize       uint32   always 0x0000004C (76)
  0x04  LinkCLSID        16 bytes 00021401-0000-0000-C000-000000000046
  0x14  LinkFlags        uint32   bitmask: which optional blocks are present
  0x18  FileAttributes   uint32   target's file attributes (FILE_ATTRIBUTE_*)
  0x1C  CreationTime     FILETIME target creation time (8 bytes)
  0x24  AccessTime       FILETIME target last-access time
  0x2C  WriteTime        FILETIME target last-write time
  0x34  FileSize         uint32   low 32 bits of the target size
  0x38  IconIndex        int32    index into the icon resource
  0x3C  ShowCommand      uint32   SW_SHOWNORMAL / SW_SHOWMAXIMIZED / ...
  0x40  HotKey           2 bytes  keyboard shortcut (low = VK, high = modifiers)
  0x42  Reserved1        2 bytes  (0)
  0x44  Reserved2        4 bytes  (0)
  0x48  Reserved3        4 bytes  (0)

The HeaderSize at offset 0x00 is always 0x4C; a reader can reject anything else immediately. The 16-byte LinkCLSID at 0x04 is the constant class ID 00021401-0000-0000-C000-000000000046, which is what makes the first 20 bytes a reliable signature. The three FILETIME stamps hold the target’s creation, access and write times as 100-nanosecond intervals since 1 January 1601 (UTC), copied when the shortcut was made. Those cached timestamps, distinct from the shortcut’s own file dates, are one reason LNK files are valued in forensics: they can record when a now-deleted file was last touched.

LinkFlags: the bitmask that shapes the rest of the file

The LinkFlags field at offset 0x14 is a 32-bit bitmask that a parser must read before anything else, because it declares which optional structures come after the header and how strings are encoded. The order of the sections in the file is fixed; the flags say which of them exist.

Bit / name	Meaning
HasLinkTargetIDList	An IDList (shell item list) follows the header
HasLinkInfo	A LinkInfo block with volume and path data is present
HasName, HasRelativePath	Description and relative-path strings are present
HasWorkingDir, HasArguments	Working directory and command-line argument strings are present
HasIconLocation	An icon path string is present
IsUnicode	StringData is UTF-16LE rather than the system code page
HasExpString	An environment-variable data block (e.g. %WINDIR%) is present

The IsUnicode bit matters for parsing every later string: when set, all StringData is length-prefixed UTF-16LE; when clear, it is in the ANSI code page of the machine that wrote the file. A parser that ignores this flag will mis-read foreign-language paths.

The LinkTargetIDList: locating the target in the shell namespace

If HasLinkTargetIDList is set, the header is followed by an IDList: a chain of shell item IDs (ItemID structures) that walks the Windows shell namespace from a root down to the target. Each ItemID is a 2-byte little-endian size followed by opaque, shell-folder-defined bytes; the list ends with a TerminalID of 0x0000.

LinkTargetIDList
  IDListSize   uint16          total size of the item list
  ItemID[0]    size + data     e.g. "My Computer"
  ItemID[1]    size + data     e.g. drive C:
  ItemID[2]    size + data     e.g. folder
  ...
  TerminalID   uint16 = 0x0000 end of list

This is a path expressed the way Explorer thinks of it, not as a plain string. It can point at things that have no simple file path at all, such as a network place or a virtual folder. Because the item data is shell-defined, the IDList is exactly where several historic parsing bugs lived: CVE-2010-2568, the flaw Stuxnet used, was an icon-loading vulnerability triggered while resolving a malformed shortcut’s target list, so merely displaying the icon ran code.

LinkInfo and StringData: volume, path, arguments and icon

After the target list comes the LinkInfo block (when HasLinkInfo is set). It records where the target physically lives: a VolumeID with the drive type and the volume serial number, plus a LocalBasePath for local files, or a CommonNetworkRelativeLink with the share name for network targets. The volume serial number embedded here is another forensic marker, tying a shortcut to a specific formatted volume.

Then follows StringData: a series of optional strings, each a 2-byte character count followed by the characters (UTF-16LE if IsUnicode is set). In file order they are the description (NAME_STRING), the relative path, the working directory, the command-line arguments, and the icon location. The arguments string is the security-critical one: it holds whatever is passed to the target on the command line, and this is how a shortcut aimed at cmd.exe or powershell.exe can carry an entire hostile command.

ExtraData blocks and the machine fingerprint

The file ends with an ExtraData section: a sequence of optional, self-describing blocks, each a 4-byte size, a 4-byte signature, then its payload, ended by a TerminalBlock whose size is less than 0x04. Each block type has a fixed signature.

ExtraData block
  BlockSize        uint32   size incl. header
  BlockSignature   uint32   e.g. 0xA0000003 TrackerDataBlock
  ...payload...
  TerminalBlock    uint32 < 0x00000004  end

The most telling is the TrackerDataBlock (signature 0xA0000003), written by the Distributed Link Tracking service so Windows can find a moved target. It stores the NetBIOS name of the machine that created the shortcut plus two NetworkNodeID droid GUIDs, which are version-1 UUIDs that embed the creating machine’s MAC address and a timestamp. This is why LNK artefacts can attribute a document to a specific computer. Other blocks include EnvironmentVariableDataBlock (an expandable path such as %WINDIR%\system32\...), ConsoleDataBlock (console window colours and size), and IconEnvironmentDataBlock (an icon path with environment variables). Because each block is length-prefixed and signed, a reader can skip any block it does not recognise, which keeps old parsers working against files that use newer block types.

Why LNK is a malware delivery vector

A shortcut can launch any executable with any arguments and wear any icon, and Windows runs it on a double-click with no “this is a program” warning. That combination makes LNK one of the most abused initial-access formats on Windows. A typical malicious shortcut targets powershell.exe or cmd.exe, puts the real payload in the arguments string, and sets IconIndex and an icon path so the file looks like a PDF or a folder. After Microsoft blocked macros in Office documents that came from the internet in 2022, attackers shifted heavily to LNK files delivered inside ZIP or ISO email attachments, because those containers strip the Mark-of-the-Web that would otherwise flag the download.

A long-lived user-interface flaw made this worse. In ZDI-CAN-25373 / CVE-2025-9491, attackers padded the arguments string with large amounts of whitespace so that the Properties dialog’s Target field appeared empty or benign while the real command sat far off-screen. That trick was used by at least eleven state-sponsored groups from around 2017 and was only fixed in Microsoft’s November 2025 Windows updates, which now show the full command. The safe response to a .lnk that arrives by email, chat or USB is never to double-click it, but to inspect it: tools such as LECmd, ExifTool, or liblnk’s lnkinfo dump the target, arguments and machine metadata without executing anything.

The “shortcut virus” and broken .lnk associations

Two recurring problems bring people to this file type, and neither is solved by converting anything. The first is the shortcut virus: worms that spread over USB drives set the hidden and system attributes on the real folders, then drop .lnk files with the same names that launch the malware before opening the original folder. The files are not gone. Scan the drive with an antivirus, then reveal the originals from a command prompt with attrib -h -r -s /s /d X:\*.* (replacing X: with the drive letter), and delete the leftover shortcuts.

The second is a broken association: choosing “Always open with…” and picking a program for a .lnk makes every shortcut on the PC open in that application, because the choice is written to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice. Deleting that UserChoice key and restarting Explorer restores normal shortcut behaviour. Shortcuts on Windows are not files you convert or open with an editor; they are a system mechanism, and the questions around them are about resolving targets, cleaning infections and repairing associations.

Frequently asked questions

All my files turned into .lnk shortcuts — are they gone?

Almost certainly not. A shortcut virus has set the hidden and system attributes on your real files and folders and replaced them with malicious .lnk copies. Scan the drive with an antivirus, then run attrib -h -r -s /s /d X:\*.* in Command Prompt (using the affected drive letter) to unhide the originals, and delete the leftover shortcuts.

How do I see what a shortcut points to without running it?

Right-click the shortcut, choose Properties, and read the Target field on the Shortcut tab; “Open file location” jumps to the real file. Since the November 2025 Windows update the dialog shows the full command including long arguments that malware previously hid with whitespace padding. To inspect a suspicious file with zero risk, use ExifTool or LECmd, which read the fields without executing the link.

Can I open a Windows .lnk on a Mac or Linux?

Not to launch it: the target is a Windows path that does not exist on those systems. You can still read what it points to with ExifTool or liblnk’s lnkinfo. If someone sent you a .lnk expecting you to read a document, they attached the shortcut by mistake and should send the actual file.

References

• Microsoft — [MS-SHLLINK]: Shell Link (.LNK) Binary File Format
• libyal/liblnk — Windows Shortcut File (LNK) format documentation
• Trend Micro ZDI — ZDI-CAN-25373: Windows shortcut exploited by state actors

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.