LNK Files

I know what you're thinking..."LNK files? Again? Dude, you are like a dog with a bone!"

Yes. Yes, I am. But in this case, I'll keep it short. I've posted a lot...a LOT...about LNK files, and there's very likely more to come in the future.

Wietze recently shared a blog post on LNK files, in which he provides a summary of the LNK file structure, some of the issues associated with LNK files/why threat actors use them, and provides a tool called "lnk-it-up" for "generating and identifying deceptive LNK files". 

One commentator described Wietze's blog post as a "nice summary". It's much more than that, as it provides an overview of the structure, as well as ways in which the LNK file can be modified to "exploit" casual viewing of the file via the Properties of the file.

However, what the article does not go into is the metadata associated with the LNK file, and how that can be used for threat intelligence, as well as for detections, if you have tooling that can be used for this, such as Yara rules, etc.

I do like how Wietze provides tooling to check for the some of the various aspects of malicious LNK files, and I think that combined with other mechanisms and tooling, these would provide a more thorough approach to detection, as well as utilizing the findings for intelligence purposes.

Links

I've been saving some things up in this draft blog post, adding new things, removing some older stuff that, after a few days, didn't quite hit the same as when I first read them. Most who know me know that I'm not so much about just dropping a link, as sharing my why for dropping the link. Dropping a list of links on a weekly or monthly basis is great, but sharing fewer links along with thoughts and perspective as to why seems to me to much more intentional and engaging. 

File Formats
I ran across this LinkedIn post a bit ago, and it caught my attention because it had to do with revision history in the Word docs, based on the current file format. That LinkedIn post led to this blog post, which provides a really good demonstration of how to access revision save identifiers (RSIDs) within the new(er) DOCX file format. This is pretty interesting; while it does not include timestamp information, it can be correlated with other data to demonstrate when/by whom MSWord was launched and the document opened, likely providing some indicators of when the document may have been modified.

In a lot of ways, this is similar to the issue found with the Blair document in 2003, where the older OLE/structured storage style .doc files retained a bit different, but no less damning revision information. Along similar lines, I've been working on a file metadata/"slack" space within files/deleted record blog post for a bit, one that I hope will one day be published. ;-)

Note that in the DOCX blog post, the author (Ross) also references "previous research" regarding plagiarism detection using RSIDs. Be sure to read that research thoroughly, as well, to develop a better understanding of the artifact. One of the issues we tend to see historically with artifacts (re: ShimCache, AmCache, etc.) is too few analysts going for the "easy win" (i.e., "...<artifact> demonstrates program execution...") without understanding the nuances of the artifact, and not reading the published and available research on the artifact. 

XstReader
BeerCow recently forked/updated XstReader to handle larger files, so if you're in need of parsing OST/PST files, take a look at this tool. I personally haven't had a need to parse such files lately; when I did, there were other tools available, and usually involved extracting just an email or two, or someone simply posted a screen capture of their tool output. 

In 2008 or so, when I first released RegRipper, someone asked me to have it parse PST files, so...if you're still out there...here, try this tool instead. ;-)

Bad Affiliates
Apparently, not long ago, some ransomware RaaS groups got together and agreed to "out" bad affiliates. 

In Feb 2006, I read Brian Krebs' article about a hacker/botherder known as "0x80", and later that year, I heard about the USSS presentations regarding credit card theft and "carder planet", and specifically how the cybercrime eco-system was structured. Since then, we've read reporting as to how ransomware threat actors have followed a similar evolution, starting out managing the entire ransomware attack life cycle, to breaking apart and compartmentalizing various aspects of the attacks as a means of monetization. Instead of managing the entire life cycle the way we saw Samas do it in 2016, some (albeit not all) ransomware groups have opted to move to a Ransomware-as-a-Service (RaaS) model, allowing affiliates to engage with initial access brokers (IABs), steal data, deploy ransomware, and profit. Some RaaS groups have reportedly also provided legal services to assist affiliates in determining the value of the stolen data. 

Now, there seems to be an effort to add a "Yelp-for-affiliates" aspect to the model, almost like rating your ride-share driver. And why not? If you, as a RaaS, say your ransomware will not be deployed against, say, hospitals and some affiliate hits a hospital, your brand is damaged. 

Artifacts
Arun has been posting on his blog recently, and as of this writing, has 3 articles up (maybe more by the time I finally hit the "Publish" button...). One involves forensic analysis of Windows Media Player, under the AppX/Universal Windows Platform format, and another involves session information on Windows and MacOS. Take a look and see if you find anything useful there. I'm going to go back and dig in a bit more on the WMP article; I'm used the more traditional application and want to see if there's something from Arun's research that can be added to my own process going forward. 

ElComSoft has published a couple of interesting blogs recently, one on USB-connected Device Forensics, and one more recently on File System Artifacts under C:\Windows. 

I really like how the USB devices blog addresses and identifies that there are actually different types of devices, that use different protocols, that can be connected to a computer via USB. This very often means that a thumb drive doesn't "appear" the same way, doesn't leave the same artifacts as a digital camera or a smart phone. This can be a very important distinction, depending upon your analysis goals.

The Windows artifacts article contains more than a few pointers to useful data sources within the file system, but there's precious little information regarding how to incorporate them into an overall process. For example, whenever I see an incident report for a Windows 11 endpoint, I try to grab the PCA files because I have an easy means for incorporating them into my overall analysis process, one that has provided tremendous value during analysis.