LNK (Ab)use

I've discussed LNK files a number of times in this blog, and to be honest, I really don't think that this is a subject that gets the attention it deserves. In my experience, and I humbly bow to collection bias here, LNK files are not as well understood as they (sh|c)ould be in the DFIR and CTI fields, which puts defenders at a disadvantage. When I suggest that LNK files aren't really well understood by DFIR and CTI teams, I'm basing that on my own experience with multiple such teams over the years, largely the result of direct interaction.

Why is that? Well, the LNK file format is well documented at the MS site, and there have been a number of tools written over the years for parsing these files. I've even gone so far as to create the smallest functioning LNK file, based on the minimum functional requirements, and with all of the metadata zero'd out or altered. However, IMHO, the real issue is that the actual functional, operational use of these files is not discussed often enough, and as such, they fall out of scope, much like other aspects of Windows systems (Ex: NTFS alternate data streams (ADSs)). As such, LNK files are not something that is closely examined during DFIR or proactive threat hunting engagements, and even more rarely do they appear in reporting. Finally, as effective as these files can be, they simply are not the "new shiny hotness"...they aren't 0-days, and they aren't the newest, hottest exploits. As a result, not a lot of focus and attention are given to these files, and it's likely that their use is less evident than might otherwise be the case.

V3ded's Github repo includes an article that does a great job of covering how LNK files can be abused. While the title refers to "initial access", it seems to describe the use of document macros to create an LNK file, rather than "weaponized" LNK files being delivered to a target. The difference is an important one...using macros (or some other method) to create LNK files on a target system means that the LNK file metadata is going to be specific to the target system itself. Alternatively, an LNK file delivered to the target is going to contain metadata specific to the threat actor's dev environment.

V3ded's article refers to a couple of means of persistence that are very interesting. One is the use of shortcut keys, defined within the structure of the LNK file. Per the article, an LNK file can be placed on the desktop and structured to be activated by a specific and common key sequence, such as Control+C (copy), Control+V (paste), or some other commonly used sequence. Another means of persistence involves the use of the "iconfilename" element within the LNK file structure; by pointing to an icon file located on a remote, TA-controlled system, attempts to access the resource (via activation of the LNK file) will involve authentication, allowing the threat actor to collect password hashes. What's interesting about both of these techniques is that neither one requires the threat actor to authenticate to collect information and gain access to your systems. This means that following containment and eradication steps, when you think you've ejected the threat actor and you've changed passwords in your environment, the threat actor is still able to collect information that may allow them to re-enter your environment. 

Again, when LNK files are sent to a target, from a threat actor, those files will contain metadata specific to the threat actor's dev environment. For example, consider MalwareByte's analysis of an "LNK attack" tied to a threat actor group referred to as "Higaisa". This attack apparently involved an LNK file being sent to the target in a zip archive; the LNK file would have to have been developed by the threat actor, and the file metadata would provide insight into the threat actor's development environment. 

A similar example could be seen in Mandiant's analysis CozyBear phishing campaigns. In this example, the Mandiant team did an excellent job leveraging LNK files, and looked specifically at differences between successive campaigns to derive insights into the threat actor's evolution.

Over time, we've also seen LNK files sent or linked to a target while embedded in ISO or IMG file formats, allowing them to bypass MOTW (re: ADS) restrictions. In cases such as this, the metadata within the LNK file structure can provide insights as to the build or production method, proliferation of build methods, etc., similar to the way EOD professionals look to toolmarks and artifacts to identify bombmakers. As such, these resources should not be ignored by DFIR and CTI professionals, but should instead be leveraged for a range of insight. For example, Yara rules can be used to perform retro-hunts via VirusTotal to look for the use and proliferation of specific platforms, as well as view changes in LNK file production techniques between campaigns, or simply over time. Tools can be designed to comb through specific locations within Windows systems (or images), scanning for persistence techniques and other anomalies, automatically providing them for analysis and development into retro-hunts.