Offensive Security

Phishing with Shortcuts: The Hidden Power of .LNK Files

In this blog, we explore Windows Shell Link files in detail, showcasing their use cases, creation, and structure in phishing campaigns.

Skidz Security Research Team

12 Mar 2025 — 7 min read

In the cat and mouse game of the offensive and defensive cyber space, phishing highlights the creativity of both sides, driving each other into a continuous cycle of adaptation and escalation.

This blog is highly technical, focusing on .LNK files, interacting with them through the Windows Script Host and COM objects, and using their hidden power for unconventional purposes.

These files are highly effective for phishing due to their stealth and versatility. They can masquerade as harmless shortcuts with a familiar icon, tricking users into double-clicking, while silently executing other actions. They relatively bypass more security measures than other file extensions (i.e. exe), and are windows native, requiring no dependencies.

This blog is purely educational, with the purpose of understanding the methodology behind discovering more and more advanced techniques, empowering both defensive experts to harden their security measures and offensive experts to think out of the box, using tools from the box.

Definition & File Attributes

Shell Link (.LNK) files are binary files with a special structure. They are normally used as shortcut files in Windows. More specifically, they contain information that can be used to access another data object [1].

Shell Link files have a handful of properties. The following snippet showcases the attributes of a Microsoft Word shortcut.

All of these properties will be discussed further on.

Interacting with .LNK Files

The Windows Script Host (WSH) allows access to some COM Objects, enabling automation of Windows tasks. In the following section, we'll explore how to use a certain COM object, WScript.Shell to interact with .LNK files.

WScript.Shell COM Object

Since the Shell Link files are binary files, interacting with them manually would involve low level communication, maybe through C/C++. However, the Windows Script Host (WSH) and Component Object Model (COM) Objects simplifies the process for us.

The following code snippet showcases instantiating a COM Object called WScript.Shell

$shell = New-Object -ComObject WScript.Shell

The WScript.Shell is a COM Object provided by WSH that enables access to some Operating System Shell methods.

COM Objects, very briefly, are reusable code that is language independent. COM is basically a framework/standard for creating COM objects with certain conditions so that they can interact with other objects and be interacted with in a certain way, all through COM interfaces (i.e. IUnknown or IDispatch interfaces). As long as the chosen language can satisfy the COM’s conditions (i.e. C and Java), it can be used to write COM objects. “COM is the foundation technology for Microsoft's OLE (compound documents), ActiveX (Internet-enabled components), as well as others.” [2]. Finally, each COM object has a unique global identifier (Class identifier - CLSID).

The following figure showcases the properties and methods that the WScript.Shell COM Object made available to us.

We can see the Object’s CLSID {41904400-be18-11d3-a28b-00104bd35090} as well as some interesting methods that we can use. The Run method, for example, enables us to run other applications using this COM Object.

The following snippet showcases running Notepad using the Run method:

Running Notepad using a WScript.Shell Object

Moreover, to solidify the concept, we can use the Popup method to display a message, as shown in the following figure:

Displaying a Popup using a WScript.Shell Object

In those two examples, we have seen how COM Objects help us re-use code and interact with the Windows environment.

Viewing .LNK Files and Their Attributes

The WScript.Shell COM Object also has the CreateShortcut method, which is used to interact with Shell Link files. “A Shell link is a data object that contains information used to access another object in the Shell's namespace—that is, any object visible through Windows Explorer.” [3] This is done through the IShellLink COM Interface. [4]

The following code snippet showcases creating a WScript.Shell COM object and using its CreateShortcut method to instantiate a Shell Link COM Object to interact with a Shell Link file.

$shell = New-Object -ComObject WScript.Shell
$lnk = $shell.CreateShortcut("C:\\Absolute\\Path\\To\\Link\\File.lnk")

What happens under the hood is that the Shell Link file is loaded into memory and parsed through IShellLink. We can view the previously mentioned properties/attributes of the Microsoft Word Shell Link file by simply displaying the output of the Shortcut Object ($lnk in our case), as shown in the following figure:

Viewing the Properties of a Shell Link File

Creating & Editing .LNK Files

After storing the Shell Link Object in a variable, we can create and/or edit the file through the variable as shown in the following snippet:

$shell = New-Object -ComObject WScript.Shell
$lnk = $shell.CreateShortcut("C:\\Absolute\\Path\\To\\Link\\File.lnk")

$lnk.TargetPath = "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
$lnk.Arguments = ''
$lnk.IconLocation = ""
$lnk.WorkingDirectory = ""
$lnk.Description = ""
$lnk.WindowStyle = 1
$lnk.Save()

The interface wrapped the Shell Link file into an object through WScript.Shell allowed us to access methods that set and get the properties of the Shell Link file.

If a Shell Link file already exists in the path, we are essentially editing on it, if it doesn't, we are creating one.

If we re-visit the Shell Link properties, we can see the following:

The following points provide a brief overview of each attribute:

FullName: The full file path of the .LNK file itself.
Arguments: Command-line parameters passed to the target executable.
Description: A user-friendly comment or tooltip for the shortcut.
Hotkey: Keyboard shortcut to launch the .LNK (e.g., Ctrl+Alt+T).
IconLocation: Path to the icon file and its index used for the shortcut’s display.
RelativePath: Relative path to the target (if applicable, often empty).
TargetPath: The executable or file the .LNK launches.
WindowStyle: How the target window appears (e.g., normal, minimized, maximized).
WorkingDirectory: The directory where the target runs from.

All changes needs to be saved in order to be reflected to shell’s environment.

The sky is the limit from here. We can create Shell Link files and finely tune them to execute an action in a specific way.

For now, we have explained what Shell Link files are and we’ve demonstrated how to interact and view them using deep technical terms. The following section will showcase how we can use .LNK files to execute some actions of interest, and, discuss some use cases in the wild.

.LNK Practical Use Cases

Standalone or coupled with other techniques, Shell Link files can provide a hidden way of executing commands on a system.

As a simple PoC, we can create a Shell Link file to download a payload (msfvenom Reverse-Shell) from a remote URL and execute it in memory using PowerShell. The following figure showcases the whole process of creating, editing, and saving a .LNK file:

Note that we have set WindowStyle to 7, which, when executing the .LNK file, the window will be minimized (opens minimized in the taskbar).

WindowStyle can have the following values:

1 - Normal window (default)
3 - Maximized window (fullscreen)
7 - Minimized window (opens minimized in the taskbar)

Executing the .LNK file will result in fetching the payload and executing it as shown:

0:00

/0:06

Note that defenses were turned off during the PoC.

In the wild, we can see multiple ways in which payloads, including .LNK files are crafted, hidden, and delivered.

One such example is presented in the following article by Lorenzo Meacci, where a .LNK file was employed to initiate a DLL sideloading attack by launching a batch script, which then executed an executable susceptible to DLL sideloading. Accompanying the payload was a DLL that, upon the executable’s activation, downloaded a Havoc C2 agent. Using some techniques, everything was running in the background while the user was presented with a legit PDF file.

The files (.LNK, executable, DLL, batch script, and the real decoy PDF) were packed and delivered to the victim.

Packing and delivering payloads is a very important aspect in phishing as more restrictions are applied to the files allowed to be sent, such as Gmail banning a hefty number of extensions and password protected ZIP files [5]. For that matter, attackers are becoming more and more creative in their packing techniques. In the previous example, the payload was packed into a .img file and then compressed into a password protected ZIP file, and finally hosted on a file sharing platform. A link to that platform was sent to the victim.

We can also see the .LNK files being wildly used by APT’s and malicious actors:

For a final word, Shell Link files that are downloaded from the internet (i.e. email attachments) are marked by Mark of the Web. Our previous blog delves into MotW and some bypassing techniques.