Dangerous shortcuts so LNK files can fool Windows and run malware

For decades, direct access .lnk has been part of the Windows ecosystem: they arrived with Windows 95 and since then their binary format has grown in complexity. This complexity is precisely what a Dutch security researcher, Wietze Beukema, took advantage of to show that these files can become sophisticated traps for unprepared users.

In a presentation at Wild West Hackin 'Fest, Beukema detailed several new techniques that allow to create shortcuts that show one thing in the Windows Explorer's property window but that, by running them, they launch a completely different one. The core of the problem is that a .lnk file can contain multiple optional structures that describe the target route, and Windows Explorer does not always consistently prioritize or validate those fields. The result: you can make direct access that appears to point to a PDF, for example, and that actually run PowerShell or other malicious orders.

Among the techniques described are variants that exploit prohibited characters on Windows routes - such as double quotes - to build routes that seem valid to the naked eye but are technically invalid. Explorer, instead of rejecting these .lnk, presents them in a conciliatory way, showing the "false" route while opening the direct access runs the "real" route hidden in another structure of the file.

One of the most powerful techniques is based on manipulating the EnvironmentVariableDataBlock structure within the .lnk. Beukema found that leaving the Unicode field empty and filling out only the ANSI version of the destination, it is possible to show an innocuous target on the interface - for example, "invoice.pdf" - while the actual content of the EnvironmentVariableDataBlock invokes malicious commands or executables. In addition, in these settings the command line arguments can be hidden, which complicates even more that a user detects the deception simply by looking at the properties.

Beukema published a technical analysis with examples and tests on his blog, where he explains in detail how these structures work and why Explorer behaves permissively to poorly formed LNK files: analysis of Wietze Beukema. He also released an open source tool called lnk-it@-@ up that allows you to generate shortcuts with these techniques and compare what Explorer shows against what actually runs, useful for testing and detection: lnk-it-up in GitHub.

When Beukema informed Microsoft about the problem related to EnvironmentVariableDataBlock (VULN-162145 record), the company decided not to classify it as security vulnerability in its MSRC, arguing that its exploitation requires the user to voluntarily execute a malicious file and therefore does not break the security limits of the system. That position was communicated by Microsoft to different media, and the company recalled that Windows warns when trying to open .lnk downloaded from the Internet and that tools like Microsoft Defender and Smart App Control add protective layers.

However, recent history shows why many researchers and response teams care about .lnk. A related failure, identified as CVE-2025-9491, also allowed to hide command line arguments and was exploited in real attacks for years. Industry reports showed that multiple groups, including state actors and criminal gangs, have used such weaknesses to deploy malware and remote access Trojans. For further information on the scope of these holdings, see the CVE public record: CVE-2025-9491 in NVD and the threat analysis that documented the activity of several actors: Trend Micro report.

In the face of the active exploitation of CVE-2025-9491 Microsoft ended up introducing changes in the management of .lnk in June 2025 with the intention of mitigating the vector that was being used in real attacks. However, the position that a technique "requires user interaction" remains the official line for classifying gravity, leaving room for discussion on the obligation to correct how the system shows and prioritizes information in direct access.

For any user or security officer there are several practical points that should be taken into account right now. First, .lnk should be considered potentially dangerous files: if they come from unknown sources or from unexpected messages, the safest option is not to open them. Second, detection solutions and application implementation policy (e.g. Smart App Control) reduce risk but do not eliminate it; attackers continue to invent tricks to evade controls. Finally, those who manage equipment or networks can use tools such as the one mentioned by Beukema to analyze and detect .lnk suspects in their environment, always in controlled laboratories and not in production systems.

The case of .lnk direct access is a good reminder that attack vectors do not always pass through e-mails with .exe attachments or by macro documents: sometimes exploitation is more subtle and takes advantage of permissive behaviors of the operating system itself. The combination of social engineering (convince someone to click) and a lenient implementation in the software results in difficult to detect traps in plain sight.

If you want to deepen the technical tests and experiment with the examples, check the material published by Beukema and use its tool in an isolated environment: technical input and repository. To understand the historical context and campaigns that abused similar failures, information collected in the NVD database and reports from security companies such as Trend Micro provide concrete examples of exploitation: NVD and analysis of Trend Micro.

In short, it is not a bad idea to review the safety practices in the organization and remind users that system warnings are not mere formalities: many successful campaigns have prospered because people click without thinking. Windows shortcuts, however innocent they seem, remain a useful vector for attackers and deserve attention from security teams and end users.