It's great when a plan, or a puzzle, comes together, isn't it? 

I'm not just channeling my inner Hannibal Smith...I'm talking about bringing various pieces or elements together to build a cohesive, clear picture, connecting the dots into a cohesive analysis.

To kick this off, Florian had this to say about threat actors moving to using ISO/IMG files as result of Microsoft disabling VBA macros in docs downloaded from the Internet, a change which results in entirely new artifact constellations. After all, a change in TTPs is going to result in changes as to how the system is impacted, and a change in the resultant constellations. So, this sets the stage for our example.

In this case, the first piece of the puzzle is this tweet from Max_Mal_, which points to the BumbleBee campaign (more info from TAG here), described in the Orion Threat Alert. Per the tweet, the infection looks like this:

Zip -> ISO -> LNK -> rundll32.exe (LOLBin) -> Cobalt Strike

This all starts with a zip archive being delivered to or downloaded by the user; however, what's not mentioned or described here are the system impacts. Downloading the archive often (depending upon the process) results in MOTW being "attached" to the zip archive. This tweet thread by Florian Roth includes a couple of resources that discuss MOTW, one of which is an excellent article by Mike Wolfe that provides a really nice explanation and details regarding MOTW. I've been fascinated by NTFS alternate data streams (ADSs) since I first encountered them, in particular how they're used by the OS, as well as by the adversary. As a result, I've been similarly interested in really leveraging MOTW in every way possible.

The other useful component of Florian's thread is this tweet by Nobutaka Mantani regarding MOTW propagation support in archiver software for Windows. This is huge. What it means is that when the ISO file is extracted from the zip archive by one of the software products that supports MOTW propagation, the extracted file "inherits" MOTW, albeit without the same contents as the original MOTW. Rather, the MOTW attached to the ISO file points back to the zip archive. This then gives us a great deal of insight into the origin of the extracted file, even if the zip archive is deleted.

The benefit is that this may provide us with a detection opportunity, something that depends upon the framework and/or approach you're using. For example, it may be a good idea to alert on files being written to suspicious locations (ProgramData folder, user's StartUp folder, etc.) by one of the archiver software packages, where the target file has a MOTW. Or, we can search for such files, via either proactive or DFIR threat hunting, as a means of locating "badness" on systems or within images. Imagine having an automated process that parses the MFT, either from a triage file collection or from an acquired image, and automatically identifies for the analyst all files with MOTW in suspicious locations. MOTW propagation also appears to occur if the downloaded zip archive includes an LNK file (rather than an ISO file), or a batch file, as well. There have been instances where a batch file is extracted from an archive, to the user's StartUp folder, and has an associated MOTW. As such, automating the detection process, via alerts based on EDR telemetry, or via proactive or DFIR hunting, provides for efficiency and consistency in the analysis process.

So, where we once had to deal with weaponized documents, we're now extracting files from an archive, mounting an ISO or IMG file, and accessing the embedded LNK file within the "new volume". All of this results in a completely new artifact constellation, one that we have to understand in order to fully address coming attacks.

One of the challenges within DFIR, particularly as we've moved to an enterprise approach by leveraging EDR telemetry, is the root cause analysis, or "RCA". In short, the challenge is observing malicious activity and determining the root cause; the challenge itself stems from the fact that EDR telemetry is only partial visibility, or that correlating observed malicious activity with causal data not evident or available via EDR telemetry requires additional context, and by extension, additional effort/expenditure of resources. It also requires an additional "leveling up" of skillsets. 

Yes, many organizations that deploy EDR tooling also include a means for extracting additional files/data from the endpoint, and what to collect isn't usually in question. Rather, how to truly exploit the collected data is the issue, with the exploitation of that data being the "levelling up".

When malicious activity is observed, or the impact of malicious activity is discovered (via threat hunting, etc.), the challenge then becomes, how do we determine the root cause? In the past, when someone has shared suspicious activity with me and sought guidance as to next steps, I've often asked, "...did a reboot or login occur just prior to the activity?" as a means of developing context around the observed activity. Was the executable launched via an auto-start mechanism, such as a Windows service, entry in a Run key, or as a Scheduled Task? The thought process has been to seek causal events for the observed activity, which can be important to not only determine the root cause, but perhaps to also identify a shift in TTPs, once we're to a point where we can arrive at attribution.

There are a lot of different ways for threat actors to persist on Windows systems, some of which were mentioned earlier in this post. Each has their advantages and disadvantages, and both require and provide different levels of access. For example, creating an entry in the user's Run key means that the malware won't start again until the user logs in, and then runs within the user context. However, if the threat actor has Admin privileges, they can create a Windows service or Scheduled Task, which then will run malware with SYSTEM level privileges. As a result, the persistence mechanism used provides a great deal of context beyond just the entry for the malware. 

To provide further insight into this topic, Krz wrote up an excellent blog post not long ago about how a laptop going on battery (unplugged from the power cord) can impact an investigation.

Based on the MITRE "Event Triggered Execution: Screensaver" page, I created a RegRipper plugin for my local repo to parse the screensaver settings out of the NTUSER.DAT hive, and ran it against a hive extracted from my local system, the output of which follows: