LNK: A perfect vector for living-off-the-land attacks

An ideal tool for living-off-the-land criminals’ arsenals.

Author: Symantec Threat Engineering Team

LNK files often arrive via email

The LNK file is a shortcut file used by Microsoft Windows, and is often a direct link to an executable file. LNK files are often placed in the Desktop and Start Menu to help users access or launch a file quickly, instead of having to navigate to it. It’s also not unusual for hackers to use LNK files as an attack vector — one of the most well-known examples was Stuxnet (PDF).

When carrying out a living off the land style attack, an attacker needs a way to execute at least one command or script on the target machine to kick off a string of follow-on activities. The initial step could be achieved using numerous techniques such as using a macro enabled document, a SMB vulnerability exploit, an RDP connection with brute forced access, or they could just use an LNK file that tricks the user into opening it, which then leads to the running of a remotely downloaded script. Of the techniques mentioned above, an LNK file is undoubtedly the most economical way for the attacker to choose.

Perhaps because of its economy, we have been seeing an increasing number of attacks leveraging LNK files in the past few months. These LNK files often arrive via email, either as an attachment or a download link contained within the email body. The hackers use social engineering to trick users into clicking on the LNK files. A closer look at Symantec telemetry shows that hackers are in favor of using LNK files as a gateway for fileless attacks.

Figure 1. Number of LNK attacks through email, August 2018 to mid-August 2019

We recently came across a very interesting case when investigating a collection of samples, which may be related to a particular malware campaign. The following diagram illustrates the various stages of this malware campaign that used LNK files in the initial stage. Protection and Symantec detections are provided for the various stages of the attack for reference.

Figure 2. Symantec has a full stack of protections against this living off the land attack campaign

A closer look at the LNK files

For the purpose of this discussion we’ll just focus on the LNK files used in this attack. First, we need to understand how the attackers are using the LNK files, so we need to take a closer look at the internals of these files. In an LNK file, the command line is usually composed of two parts:

1) the executable and its file path

2) the command-line arguments

The command-line arguments are pretty straightforward and are always saved as a unique string in the string data field of the LNK file. Two other fields of note are the “HasArguments” and “IsUnicode” flags in the LNK header:

· The Arguments string is only available if the “HasArguments” flag is set

· The Arguments string will be in Unicode format if the “IsUnicode” flag is set, otherwise it will be a standard ASCII string

The most interesting part of the file is the target executable and its path. Let’s take a look at the sample from the case we mentioned. If we right click the LNK file in Windows and check the command line in the file properties, we see the executable and its path (Figure 3).

Figure 3. File properties of malicious LNK file

As shown in Figure 3, the executable name is “oword.exe”. However, this is a fake name, you won’t find an executable file inside the %Windir%\system32 folder with this name. But if we click “Open File Location”, we can see that the real executable used in this LNK file is actually “mshta.exe” (Figure 4).

Figure 4. Real file location shown after clicking “Open File Location”

It’s not just the file properties window that’s fooled, many third-party scanners and parsers can also be evaded using this trick. During our research we noticed there were many fields and flags that an LNK file uses to indicate its target executable file and corresponding path. Figure 5 shows the complete structure of this LNK file (relevant flags and strings have been highlighted).

Figure 5. Structure and contents of the LNK file

As we can see from Figure 5, the executable name and path information in the LNK file is listed in more than one place. The information is available in multiple fields in various sections:

· In the LinkTargetIDList

o Short names (8.3 filename) are provided by default (highlighted in blue)

o For Windows XP and later, a Unicode version name (long name) is available in the extension blocks (red)

o For Windows XP and later, an extra localized name (ASCII) could also be available in the extension blocks

o For Windows Vista and later, an extra localized name (Unicode) could also be provided in the extension blocks

· In the LinkInfo

o A local base path (ASCII) is provided (yellow)

o A local base path (Unicode) could also be provided

· In StringData

o A relative path for the executable is provided (yellow)

· In the ExtraData (EnvironmentVariableDataBlock)

o A “TargetAnsi” string could be provided to indicate the executable name and path (green)

o A “TargetUnicode” string could be provided to indicate the executable name and path (green)

· In the TargetMetadata (VistaAndAboveIDListDataBlock):

o An executable name could be provided (yellow)

o An executable path could be provided (yellow)

Meanwhile, according to the official documentation and our own testing, there are several flags that could also affect system behaviors:

o HasExpString

o HasLinkTargetIDList

o EnableTargetMetadata

o DisableLinkPathTracking

o PreferEnvironmentPath

So, the question is which executable name and path will be used on the victim machine? The following two cases were tested on a computer running a 64-bit version of Windows 7 Enterprise SP1:

CASE 1: Using the long name of the executable (same method used by the malware sample we have seen earlier)

Under the flag settings shown in the Figure 5, the actual target executable name highlighted in red in Figure 5 is used. Malware authors could change the short names to whatever they want, while still ensuring that the LNK file works as intended.

However, one thing to note is that the executable path used here is not the one from LinkTargetIDList. No matter what you change the short or long names to, the intended LNK target is still extracted correctly. The executable path being used when the LNK file is opened is actually from the EnvironmentVariableDataBlock (highlighted in green in Figure 5). As we confirmed in our tests, the path from the Unicode version is used by default, while the ASCII version is used if the Unicode version is removed.

As already mentioned, the long name is only available in Windows XP and later versions of Windows. So, what if we remove the extension block from the IDList items? Will the short name be used in this case? The answer is no. Removing the extension block from the IDList items will make the LNK file invalid.

CASE 2: Using the environment path to recover the LNK file

From CASE 1, we understand that the executable name used will be the long name from LinkTargetIDList, and the executable path will be the one extracted from EnvironmentVariableDataBlock. But what if we change the long name field to an incorrect value and change the value in EnvironmentVariableDataBlock field to the correct value? The result is the LNK file becomes invalid, and will display an icon as shown in Figure 6.

Figure 6. Invalid LNK file icon

Despite being invalid, the attackers can still use this LNK file to do their bidding. If a user double clicks the invalid LNK icon to open the “invalid” LNK file, Windows will automatically recover the LNK file fields by using the strings from the EnvironmentVariableDataBlock field. After the recovery process is done, all names and paths, except for the ones in the VistaAndAboveIDListDataBlock field, will be updated to the correct values. Moreover, users don’t need to double click on the LNK file again, the fixed LNK file will be directly “executed” to load the malware. The user will not even be aware that a recovery process took place at all.

LNKed with endless possibilities

Besides the example we have just looked at, there are many other ways that malware authors can tinker with LNK file settings to fool parsers in security software and evade detection. As discussed earlier, there are multiple flags and fields that can be set in the LNK file to achieve different system behaviors. For example, according to the official specifications, if the PreferEnvironmentPath flags are set, the “target IDList SHOULD NOT be stored; instead, the path specified in the EnvironmentVariableDataBlock SHOULD be used to refer to the target.”

There are many more tricks that can be used for what seems on the surface to be an extremely simple file format.

At Symantec we make sure to parse LNK files carefully and detect the string of follow-on fileless activities effectively so that we don’t miss a single attack.

Check out the Security Response blog and follow Threat Intel on Twitter to keep up-to-date with the latest happenings in the world of threat intelligence and cyber security.

Like this story? Recommend it by hitting the heart button so others on Medium see it and follow Threat Intel on Medium for more great content.