Trust Me, I'm a Shortcut: How LNK Files Lie to Windows Explorer

You double-click a shortcut. Windows Explorer shows you it points to C:\Program Files\Microsoft Office\Office16\WINWORD.EXE. You see Microsoft Word open. But somewhere in the background, a payload has already executed — and Explorer never showed you that part.

This is not a theoretical attack. It is what five documented LNK spoofing techniques allow attackers to do right now, on fully patched Windows systems.

TL;DR

Windows .lnk shortcut files contain multiple internal structures that specify the target — and Explorer picks between them inconsistently

Five techniques let attackers display a fake target in the Properties dialog while executing a completely different one

CVE-2025-9491 abuses the 260-character display limit to hide command-line arguments

Microsoft classifies these as UI bugs, not security vulnerabilities — so no patch is coming

Open-source tool lnk-it-up can both generate and detect these deceptive shortcuts

Why This Matters

LNK files are everywhere. Every Windows desktop shortcut, every Start Menu entry, every pinned taskbar item is an LNK file. Attackers have used them as phishing payloads for years — zipped up, emailed, delivered via Teams or OneDrive links.

The conventional wisdom is: “Just right-click → Properties to check where a shortcut really points.” These techniques break that assumption entirely. The Properties dialog can lie. Explorer trusts data it should not trust, and the inconsistency between what is displayed and what is executed is the vulnerability.

Security researchers, incident responders, and anyone deploying detection rules for LNK-based malware need to understand this — because standard LNK analysis tools may also be fooled.

How Windows Shortcuts Actually Work

An LNK file is a binary format with a fixed 76-byte header followed by several optional sections. The critical sections for understanding these attacks are:

LinkTargetIDList — Represents the target as a list of Shell Items (think: a structured path through the filesystem). This is the most common way a shortcut stores where to point.

EnvironmentVariableDataBlock (ExpString) — A 788-byte fixed block that stores the target path as a plain string, supporting environment variables like %WINDIR%. Activated by the HasExpString flag in the header.

LinkInfo — A fallback resolution mechanism. If the original target cannot be found (e.g., file was moved), Explorer uses this to locate it via local or UNC paths.

Here is the problem: Windows Explorer prioritizes these structures inconsistently. Depending on which flags are set, Explorer may display one structure’s value in the Properties dialog while executing a completely different structure’s target. And because Explorer is forgiving — it never rejects a malformed LNK, it just falls back silently — attackers can craft files that exploit every gap in this priority logic.

The Five Spoofing Techniques

Technique 1 — CVE-2025-9491: Hidden Arguments via Padding

The command-line arguments field in an LNK file supports up to 65,536 characters. Explorer’s Properties dialog only displays the first 260 characters.

An attacker sets the real arguments after 260 characters of whitespace (spaces, tabs, newlines, carriage returns). The Properties dialog shows nothing after the initial padding — but when the shortcut executes, Windows passes all 65,536 characters to the process.

[Displayed in Properties]
"C:\Windows\System32\cmd.exe"
Arguments: (appears empty)

[Actually executes]
cmd.exe /c powershell -EncodedCommand <base64 payload here>

Limitation: The target executable is still visible. The whitespace padding is detectable in process execution logs if you know to look for it.

Technique 2 — ExpString with Null Bytes

If the HasExpString flag is set, Explorer expects an EnvironmentVariableDataBlock. This technique sets that block to null bytes only — an effectively empty path.

Explorer responds by hiding both the target and arguments fields in the Properties dialog entirely. The user sees blank fields. But the LinkTargetIDList target still executes, along with its arguments.

This effectively makes the shortcut appear “empty” in the UI while remaining fully functional as a payload launcher.

Technique 3 — Path Spoofing via Invalid Characters

Windows paths cannot contain certain characters: quotes ("), angle brackets, pipes, and others. This technique exploits what happens when Explorer encounters an invalid path in EnvironmentVariableDataBlock.

The attacker sets:

EnvironmentVariableDataBlock → a fake-looking but invalid path (e.g., C:\Windows\System32\"notepad".exe)
LinkTargetIDList → the actual malicious target

Explorer displays the EnvironmentVariableDataBlock value (the fake path) in Properties because it is preferred for display. But since the path is invalid, Explorer executes the LinkTargetIDList target instead.

Result: the Properties dialog shows Notepad, the system runs something else.

Technique 4 — LinkInfo Fallback

This variant chains three structures together:

HasExpString flag set with an invalid EnvironmentVariableDataBlock (forces display of the fake path)
HasLinkTargetIDList flag set with a non-conforming LinkTargetIDList (prevents normal execution)
LinkInfo containing the actual payload path (becomes the fallback execution target)

Explorer shows the EnvironmentVariableDataBlock display value and executes the LinkInfo path. Command-line arguments are hidden because the ExpString field disables that UI element.

Important caveat: This variant is broken on Windows 11 24H2 and later. Microsoft changed the fallback behavior in that release, making this specific technique ineffective on the newest Windows versions.

Technique 5 — Unicode/ANSI Field Mismatch

EnvironmentVariableDataBlock contains two target fields: TargetAnsi (260 bytes) and TargetUnicode (520 bytes). Both are always present in the structure regardless of encoding flags.

This technique sets:

TargetUnicode → null bytes (empty)
TargetAnsi → the real malicious path + arguments

Because TargetUnicode is null, Explorer falls back to displaying the LinkTargetIDList target in Properties — which the attacker has set to something benign. But execution uses TargetAnsi along with its hidden arguments.

This is arguably the most dangerous variant: single execution, self-repairs after first run, supports environment variables in the actual target, and completely spoofs the displayed path.

A Real Attack Chain

Here is how these techniques fit into a phishing campaign:

1. INITIAL DELIVERY
   Attacker sends a ZIP via email or Teams:
   "Q1-2026-Payroll-Review.zip"

2. CONTENTS
   Q1-2026-Payroll-Review.lnk
   → Displayed target: C:\Windows\System32\excel.exe
   → Actual execution: powershell.exe -WindowStyle Hidden -EncodedCommand <loader>

3. USER ACTION
   Victim unzips, sees shortcut with Excel icon
   Right-clicks → Properties → sees Excel path
   Double-clicks → "nothing happens" (payload runs hidden)

4. PAYLOAD STAGES
   Stage 1: Downloads C2 beacon (HTTPS to legitimate cloud provider)
   Stage 2: Establishes persistence via scheduled task
   Stage 3: Begins credential harvesting / lateral movement

The LNK file is the initial access vector. Everything after is standard post-exploitation — but it only becomes possible because the shortcut file lied convincingly enough to get that first click.

Detection: What Blue Teams Can Do

Pre-Execution Detection

Standard LNK parsing tools may not catch these techniques. Tools like Python’s LnkParse3 or Eric Zimmerman’s LECmd parse the format strictly and may reject or misparse the deliberately malformed structures that Explorer handles permissively.

The right approach is behavioral matching rather than strict format parsing:

Use lnk-tester — part of the open-source lnk-it-up suite. It uses native Windows APIs to simulate what Explorer would actually do, then compares displayed target vs. execution target. Any mismatch is flagged.

# Clone and build lnk-tester
git clone https://github.com/wietze/lnk-it-up
cd lnk-it-up/lnk-tester

# Run against a suspicious LNK file
.\lnk-tester.exe "C:\Suspicious\Q1-2026-Payroll-Review.lnk"

# Output example:
# [!] MISMATCH DETECTED
# Displayed: C:\Windows\System32\excel.exe
# Executes:  C:\Windows\System32\cmd.exe /c powershell -EncodedCommand ...

YARA rules can catch structural anomalies — for example, EnvironmentVariableDataBlock blocks filled with null bytes, or unusually long whitespace sequences in the arguments field:

rule LNK_NullExpString {
    meta:
        description = "LNK with HasExpString flag but null EnvironmentVariableDataBlock"
        author = "Hive Security"
    strings:
        // HasExpString flag (0x200) in LinkFlags at offset 0x14
        $lnk_header = { 4C 00 00 00 01 14 02 00 00 00 00 00 }
        // 14-byte block signature for EnvironmentVariableDataBlock followed by nulls
        $null_expstring = { 14 03 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 }
    condition:
        $lnk_header at 0 and $null_expstring
}

Post-Execution Detection

If the LNK has already been clicked, look for these indicators:

What to look for	Where to look
Process spawned with unexpected parent (e.g., `powershell.exe` → parent `explorer.exe`)	Windows Event ID 4688, Sysmon Event ID 1
Command line with excessive whitespace before arguments	Sysmon Event ID 1 (CommandLine field)
LNK file in temp/download folder accessing unusual targets	Sysmon Event ID 11 (FileCreate) + 1 (Process)
`cmd.exe` or `powershell.exe` with encoded commands spawned from shortcut	EDR process tree
Short-lived processes after Explorer launches a shortcut	Process creation + termination within seconds

Sigma rule concept for Technique 1 (whitespace-padded arguments):

title: Suspicious LNK Execution with Whitespace-Padded Arguments
status: experimental
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith: '\explorer.exe'
        CommandLine|contains:
            - '   '   # three or more consecutive spaces in cmdline
    filter_legitimate:
        Image|endswith:
            - '\notepad.exe'
            - '\calc.exe'
    condition: selection and not filter_legitimate
level: medium

What You Can Do Today

For defenders:

Deploy lnk-tester in your email gateway or sandbox pipeline — run it against every LNK file that arrives in email attachments or downloads
Block LNK files in email entirely — most organizations have no legitimate need to receive .lnk files via email
Enable Sysmon with a comprehensive config — make sure CommandLine logging is active (Event ID 1) so whitespace-padded arguments are captured
Add LNK analysis to your YARA ruleset — check for null ExpString blocks, mismatched Unicode/ANSI fields, and excessive whitespace in arguments
Test your EDR — use lnk-generator from lnk-it-up to create test payloads and verify your EDR catches the execution chain

For red teamers:

Clone lnk-it-up and test all five variants in your lab against the target EDR stack before using in an engagement
Note the Windows version — Technique 4 (LinkInfo fallback) is broken on Windows 11 24H2+; use Technique 5 (Unicode mismatch) for modern targets
Combine with icon spoofing — a matching application icon makes the Properties dialog check even less likely
Embed in ISO/ZIP — LNK files in archives bypass some email filters; ISO mounting removes the Mark of the Web in older Windows versions

The Bigger Picture

Microsoft has classified these issues as UI bugs rather than security vulnerabilities. Their reasoning: the techniques require user interaction and do not break security boundaries in the traditional sense. No patch is planned.

This is technically defensible but practically dangerous. The entire security premise of “check the shortcut’s Properties before opening” collapses when the Properties dialog cannot be trusted. Organizations relying on user education as a mitigating control for LNK-based phishing are in a worse position than they realize.

The techniques are not new in concept — LNK files have been weaponized since at least Stuxnet (2010). What is new is the systematic documentation of exactly how Explorer’s priority logic can be exploited, combined with open-source tooling that makes generation and detection accessible to everyone.

The right response is technical: parse LNKs with tools that use native Windows APIs, not tools that assume the format is well-formed. Validate display vs. execution targets. And treat any LNK file arriving from an external source with the same suspicion you would give an executable.

The ‘Fix’ Is the Exploit: ClickFix, FileFix, JackFix and Pastejacking Attacks Explained — another class of UI-deception attacks that trick users into executing malicious commands
LOLBins in 2026: How Attackers Use Windows Against Itself — how attackers abuse legitimate Windows binaries, often launched via LNK files
Invisible Characters as an Attack Vector — similar theme of hiding malicious content in plain sight using non-printing characters

Sources

Wietze Beukema — “Trust Me, I’m a Shortcut” (original research)
lnk-it-up on GitHub — lnk-generator and lnk-tester tools
MS-SHLLINK: Shell Link Binary File Format — Microsoft’s official LNK format specification
Eric Zimmerman’s LECmd — LNK parsing tool