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
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.
No comments:
Post a Comment