LNK Files

Update, 28 Feb: Just a quick note...this post is not about tools.  I do not mention any tools in the post, and the content isn't about one tool being better than another. I do mention using a hex editor, but that is simply to verify finds from whichever tool is used.  In the first example below, every parsing tool available would've returned the exact same time stamps, and I would have (and recommended) used a hex editor to confirm the finding. At the time I'm writing this update, this post has been viewed 1258 times, and not one question about tools has been posted as a comment. This post is about LNK file metadata, what it means, and how it can be used in analysis. Thanks.

I know, I know...yet another blog post on LNK files...yeah.  I get it.  But some new things popped up recently that I wanted to take advantage of, and they ended up here.

I had an opportunity to look at several LNK files recently, and I wanted to dig a bit deeper into their metadata.  Most available write-ups make mention of the LNK file, but tend to gloss over the file and move right to the embedded command and the next stage download.  I wanted to take a closer look at what's in the LNK file, because after all, this is something created within the adversary's environment that they're sending out.  In a lot of ways, it's like free money, so why not make the best use of what you have available, and squeeze every little bit out of the data that you have?  Maybe it's just me, but when the adversary gives you something, it's hardly a "little bit".

Consider this: several years ago, the folks at JPCERT/CC said that LNK files give us a view into the attacker's development environment; this was, and still is, a great idea, so let's see if we can not only replicate what they did (with respect to metadata extraction) but also see if we can't squeeze just a bit more out of the files, and see  what we can learn about the adversary's development environment, and maybe even see what we can learn about the tools they use to create the LNK files.

Steroids
I ran across two write-ups on LNK files recently; perhaps it would be more correct to say two write-ups on the same (or very similar) LNK file.  I found this write-up at D3xt3r's Malware Lab (blog includes a hash), and this write-up on Max's blog (blog includes a link to download the sample).  While D3xt3r's write-up is dated 16 Feb 2019, Max's doesn't have a date as part of the published material, but it does appear to have been published in Feb 2019, as well.  This is to say that they're both fairly recent posts, and as such, the LNK file itself may be fairly recent, as well.

Anyway, I wanted to take a look at a few things associated with the LNK file metadata that weren't discussed in either blog post, specifically what we could learn by going really deep in parsing the files.  One of the first things that I looked at was the shell item ID list, shown below:

shitemidlist       My Computer/C:\/Windows/system32/cmd.exe
**Shell Items Details (times in UTC)**
  C:0                   M:0                   A:0                  Windows (8)
  C:0                   M:0                   A:0                  system32 (8)
  C:0                   M:0                   A:0                  cmd.exe (8)

As we can see from the above output, I parsed the shell item ID list, but the time stamps embedded within the individual shell items (the creation, modification, and last accessed times of the resources) appear to all be zeros.  Using a hex editor, I verified this quite easily, and in fact, the bytes at the locations for the time stamps within each of the shell items are all zeros.  Interestingly enough, the LNK file mentioned here also has the shell item time stamps zero'd out, so this is likely not a unique finding.  However, it's unclear whether this is the result of the tool used to create the LNK file, or of anti-forensic/obfuscation efforts taken after the LNK file was created.

We also see that the version information for the shell items is "8", indicating that the platform is Windows 2008, 7, or 8 (per section 6.5 here).  This gives us some additional (beyond what the JPCERT/CC folks discussed) insight into the development environment used by the adversary.

Now, let's take a look at the contents of the PropertyStoreDataBlock, shown below:

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
         SID: S-1-5-21-1243223150-2135741377-3118647425-500
{f29f85e0-4ff9-1068-ab91-08002b27b3d9}/6

As we can see,there are two GUID/ID pairs, the first of which points to a Unicode string that is a SID.  This is fairly common, in that we not only see the GUID/ID pair populated with a SID in a good number of LNK files, but we can use native tools (PowerShell, etc.) on Windows systems to create LNK files that contain this property set.  In this instance, the RID points to the default Administrator account for the system.  For the second property, the GUID indicates that it's a Summary Information Property Set, and the ID indicates that it's a comment.  Looking at the contents of the property set itself (via a hex editor), there don't appear to be any visible strings.

Interestingly, the LNK file does not appear to have a TrackerDataBlock, and as such, there is no machine ID (system NetBIOS name) embedded in the LNK file.  Again, this is pretty easy to verify via a hex editor.

What we have so far is a pretty interesting view into the manufacture of this LNK file.  There are some 'normal' elements of the file structure that exist, and there are other elements that we expect to see, but have been removed.  This is only one file, so without more insight, anything regarding the "why" is simply speculation and assumption.  What we do know at the moment is that steps were taken, either during the manufacturing process or afterward, to remove elements of the file structure, and the removal of those elements did not impact the function of the LNK file itself.

Finally, the D3xt3r post also includes a link (no pun intended) to this TrendMicro post from 2017.  The TM post indicates that, at the time, the use of LNK files to download malware was a "rising trend".

Cb
I also ran across this write-up from Carbon Black, dated 11 Feb 2019. The LNK file discussed in the Cb blog post contains some interesting metadata.  For example, this file happens to contain a description field, as shown below:

description        AVI

I can't say that I've often seen a description field within an LNK file that's been populated.  However, I should note that the LNK file from the 2018 campaign described here did have a description field of "ds7002.pdf"; the LNK file from the 2016 campaign did not.

In addition, we can see from the shell item ID list (below) that the shell items contain time stamps, and that the version numbers embedded within the shell items indicate that the system is a Windows 8.1 or 10 system.

shitemidlist       My Computer/C:\/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
**Shell Items Details (times in UTC)**
  C:2018-04-11 21:04:34  M:2018-11-16 21:29:56  A:2018-11-16 21:29:56 Windows (9)
  C:2018-04-11 21:04:34  M:2018-11-21 17:32:02  A:2018-11-21 17:32:02 System32 (9)
  C:2018-04-11 23:38:22  M:2018-04-11 23:38:22  A:2018-06-28 23:05:46 WindowsPowerShell (9)
  C:2018-04-11 23:38:22  M:2018-06-28 23:04:20  A:2018-06-28 23:04:20 v1.0 (9)
  C:2018-04-11 23:35:28  M:2018-04-11 23:35:28  A:2018-04-11 23:35:28 powershell.exe (9)

Looking at the PropertyStoreDataBlock (below), we see a SID, as well as another property.

***PropertyStoreDataBlock***
GUID/ID pairs:
{446d16b1-8dad-4870-a748-402ea43d788c}/104
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
    SID: S-1-5-21-1607665944-3235443811-1991609163-1001

Looking at the SID, we see that in this case, the RID is "1001", indicating a user account was used to create the LNK file (as opposed to the built-in administrator account, with a RID of 500).  In fact, we know from the RID that this was the second user account created on the system.

Looking up the other GUID, it appears to be a System.VolumeID property; I'm still looking for information on how to parse this property field.

Finally, we have the TrackerDataBlock (below):

***TrackerDataBlock***
Machine ID                     : x10-slim
New Droid ID Time         : Sun Jul 29 22:57:38 2018 UTC
New Droid ID Seq Num  : 5969
New Droid    Node ID     : e8:9e:b4:3a:a3:ea
Birth Droid ID Time         : Sun Jul 29 22:57:38 2018 UTC
Birth Droid ID Seq Num  : 5969
Birth Droid Node ID        : e8:9e:b4:3a:a3:ea

As we can see from the TrackerDataBlock, the NetBIOS name of the system on which the LNK file was created is "x10-slim". Looking up the MAC address OUI (i.e., e8:9e:b4) indicates that it belongs to "Hon Hai Precision Ind. Co.,Ltd.", which was also mentioned in the JPCERT/CC article. Through the course of discussions of "toolmarks", one of the topics that came up was that a common virtual machine may be used by actors; the fact that a VM is used is supported by the OUI lookup, but something that hasn't been addressed is how common this may be.

RAT
I also ran across a Proofpoint blog post from August 2017 that was very interesting, and not just because of the use of Game of Thrones as the lure.  In this particular case, the LNK file was embedded within the .docx lure file

First, let's take a look at the shell item ID list (below):

shitemidlist       My Computer/C:\/WINDOWS/system32/WindowsPowerShell/v1.0/powershell.exe
**Shell Items Details (times in UTC)**
  C:2006-05-22 17:08:04  M:2007-12-06 05:29:12  A:2007-12-06 05:29:12 WINDOWS (3)
  C:2006-05-22 17:08:04  M:2007-12-04 00:44:06  A:2007-12-04 00:44:06 system32 (3)
  C:2007-09-21 00:56:32  M:2007-09-21 00:56:32  A:2007-09-21 00:56:32 WindowsPowerShell (3)
  C:2007-09-21 00:56:32  M:2007-12-03 06:20:46  A:2007-12-03 06:20:46 v1.0 (3)
  C:2009-07-13 23:49:08  M:2009-07-14 01:39:22  A:2009-07-13 23:49:08 powershell.exe (8)

In this case, the version of "3" from the shell items indicates a Windows XP or 2003 system.  And yes, I did catch (and verify) that the version info for the final shell item ("powershell.exe") is indeed "8".  This seems to indicate that the LNK file was created on an older platform.

Skipping past the encoded Powershell command, we see a couple of times of interest.  First, the PropertyStoreDataBlock (below):

***PropertyStoreDataBlock***
GUID/ID pairs:
{0c570607-0396-43de-9d61-e321d7df5026}/3
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
   SID: S-1-5-21-3345294922-2424827061-887656146-1000
{dabd30ed-0043-4789-a7f8-d013a4736622}/100
{b725f130-47ef-101a-a5f1-02608c9eebac}/10
{28636aa6-953d-11d2-b5d6-00c04fd918d0}/30

Okay, this LNK file has 5 items in this data block, which is unusual in itself.  We see the SID, which as with the LNK file from the Carbon Black post, is for a user account.  We also see a number of other GUID/ID pairs, as well, and I think that this may be the result of the EnableTargetMetadata flag having been set in the LNK file.  I say this because if you read the description of the flag (here), it says:

The shell link attempts to collect target properties and store them in the PropertyStoreDataBlock (section 2.5.7) when the link target is set.

I'm not 100% clear on what this means, but it seems to say that target properties are stored when the target of the LNK file is "set".  I guess maybe another question to consider is, was the flag specifically set, and if so, what tool or application was used to create the LNK file?

Moving on, we see that this particular LNK file has a code page value identified in the metadata, as shown below:

***ConsoleFEDataBlock***
Code page: 936

The code page is identified as "simplified Chinese", which makes sense because the campaign was thought to have a Chinese nexus.  However, what I have to wonder is how many times a code page is seen within LNK files.  For example, neither of the LNK files discussed here appeared to contain code pages.  I rarely see write-ups that mention LNK files that also mention a code page entry.

Is it possible that this field was modified as a "false flag" or "red herring"?  Sure.  When looking at any single metadata field with a file structure in isolation, the possibility exists that it was modified.  We've seen evidence, just in this blog post, of either a manufacturing process that creates the files in the state that we see them, or an "after market" process that removes the missing elements from the file structure.  But what we're not seeing is the exploration of these findings in the context of the larger campaign.  Are the actors creating other "false flags"?  If so, how pervasive are they?  Are the LNK file elements linked to other campaigns, possibly even ones associated with different actors?

Finally, the TrackerDataBlock contains a machine ID of "john-win764".  Used in conjunction with the SID and volume serial number (in this case, "CC9C-E694"), a VirusTotal retro-hunt might turn up other examples of similar LNK files.

Final Thoughts
Some thoughts come to mind as a result of looking at these files.  First off, there's a good bit of metadata that can be used to do research on campaigns, particularly through individual archives, as well as VirusTotal (re: retro-hunt).

I know some folks have said, "...yeah, but it's easy to change those fields...".  Sure, I agree to an extent, but there would be a 'cost' associated with that.  The Proofpoint team addressed this in their post.  However, what I'm referring to is parsing files already collected, ones that have been archived by teams following the campaigns and collecting data, or are available from other archival sources (VirusTotal, etc.).  If those files are tied to specific campaigns, or attributed to specific actors, then you may have something there.  Not only can you see if and how the files have changed over time (like the FireEye folks did), but what if LNK files with similar metadata appear across different campaigns, and are used by different actors?  What does that tell us?

Further, what this sort of analysis shows is that there's a lot going on underneath the MITRE ATT&CK technique, specifically, "Initial Access, Spearphishing Attachment".  In fact, quite a few sub-techniques and even specific technical details seem to pop right out.  Just look at what we've seen so far; some LNK files are sent as attachments themselves, but in other cases, the LNK files are embedded in a lure document.  Embedded commands differ (WMIC, Powershell, etc.), as does the level of obfuscation and encoding. Some LNK files contain embedded commands with some serious obfuscation, while some contain no obfuscation whatsoever.  We could create an entire matrix just for weaponized attachments.

The JPCERT/CC article described some work done in clustering LNK files based on some of the available metadata around different attacks, which was very interesting.

Additional Resources
FireEye blog post, re: FIN7 - mentions LNK "toolmarks"
PodCast with Nick Carr, discussing "toolmarks"
2018 NCSC Advisory - discusses not only the use of iconfilename fields in LNK files to maintain persistence across password changes, but also includes a very basic Yara rule for detecting the 'weaponized' LNK file (I should note that none of the metadata was shared)