If you've followed me for any amount of time, particularly recently, you'll know that I've put some effort forth in correcting the assumption that individual artifacts, particularly ShimCache and AmCache, provide "evidence of execution". The is a massive oversimplification of the nature and value of each of these artifacts, in addition to just being an extremely poor analytic process; that is, viewing single artifacts in isolation to establish a finding.
Okay, so now, the question I was asked was, what is my "go to" artifact to demonstrate evidence of execution?
First, let me say, I get it...I really do. During my time in the industry, I've heard customers ask, "..what is the product I need to purchase to protect my infrastructure?", so an analyst asking, "...what is the artifact that illustrates evidence of execution?" is not entirely unexpected. After all, isn't that the way things work sometimes? What is the one thing, which button do I push, which is the lever I pull, what is the one action I need to take, or one choice I need to make to move forward?
So, in a way, the question of the "go to" artifact to demonstrate...well, anything...is a trick question. Because there should not be one. Looking just at "evidence of execution", some might think, "...well, there's Prefetch files...right?", and that's a good option, but what do we know about application prefetching?
We know that the prefetcher monitors the first 10 seconds of execution, and tracks files that are loaded.
We know that beginning with Windows 8, Prefetch files can hold up to 8 "last run" times, embedded within the file itself.
We know that application prefetching is enabled by default on workstations, but not servers.
Okay, this is great...but what happens after those first 10 seconds? What I mean is, what happens if code within the program throws an error, doesn't work, or the running application is detected by AV? Do we consider that the application "executed" only if it started, or do we consider "evidence of execution" to include the application completing, and impacting the endpoint in some manner?
So, again, the answer is that there is no "go to" artifact. Instead, there's a "go to" process, one that includes multiple, disparate data sources (file system, Registry, WEVTX, SRUM, etc.), normalized and correlated based on some common element, such as time. Windows Event Log records include time stamps, as do MFT records, Registry keys and some values.
Our analytic process needs to encompass two concepts...artifact constellations, and validation. First off, we don't ever look at single artifacts to establish findings; rather, we need to incorporate multiple, disparate data sources, through a process of parsing, normalization, decoration and enrichment to truly determine the context of an event. Looking at just a log entry, or entry from EDR telemetry by itself does not truly tell us if something executed successfully. If it was launched, did it complete successfully? Did it have the intended impact on the endpoint, leaving traces of its execution?
Second, artifact constellations lead to validation. By looking at multiple, disparate data sources, we can determine if what we thought was executed, what appeared to have been executed, was able to "survive". For example, I've seen malware launched, visible through EDR telemetry and log sources, that never succeeded. Each time it launched, it generated an error, per Windows Error Reporting. I've seen malicious installation processes (MSI files) fail to install. I've seen threat actors push out their ransomware EXE to multiple endpoints and run each instance, resulting in files on those systems being encrypted, but not be able to get the executable to run on the nexus endpoint; I've seen threat actors run their ransomware EXE multiple times with the "--debug" option, and the files on that endpoint were never encrypted.
If you're going to continue to view single artifacts in isolation, then please understand the nature and nuance of the artifacts themselves. Thoroughly review (and understand) this research regarding AmCache, as well as Mandiant's findings regarding ShimCache. However, over the years, I've found it so much more straightforward to incorporate these artifacts into an overall analysis process, as it continually demonstrates the value of the individual artifacts, as well as provides insights into the intent and capabilities of the threat actor.
No comments:
Post a Comment