Context & Finding Persistence
I was looking into an unusual mechanism for launching applications recently, and that research brought back a recurring issue I've seen time and again in the industry, specifically pivoting from one data point to another based on knowledge of the underlying system.
Very often, during SOC monitoring or live response, we'll find a process executing via EDR telemetry (or some other means) and have no clear understanding of the mechanism that launched that process. Sometimes, we may have the data available to assist us in discovering the root cause of the process launch; for example, in the case of processes launched via web shell, all you need to do is trace backward through the process tree until you get to the web server process (i.e., w3wp.exe, etc.).
Other times, however, it's not so easy to do this, as the process tree proceeds back through the parent and grandparent processes with no clear indication of the source. In such cases, we may need to seek other sources of data, such as Windows Event Log records, to determine a system boot, or a user login to the system. Then, we may need the Windows Registry hive files, or file system data, to determine persistence mechanisms. What this means is that understanding the context of a suspicious process can help us pivot to determining the origin of the process launch, and that context can be determined by an event's proximity to other events.
Tools
Over time, I've seen tools...forensic analysis suites...evolve and include more "things". For example, Paraben's E3 application (version 2.8) includes parsing of data from the Registry, and I've seen analysts use Magnet Axiom to do something similar. ForenSafe blogs about the ArtiFast application, including screen shots of the information available from the Registry. This is all in addition to tools that specifically parse various data sources, such as Eric Zimmerman's Registry Explorer, and other tools.
What analysts need to remember is that these are just tools; it is still incumbent upon the analyst to correctly interpret the information presented by the tools. For example, this ForenSafe article discusses printer device information available in the Registry, and it appears to present the information for the analyst to interpret (as many tools do). How would you, as an analyst, use this information to determine if the printnightmare exploit had been used by a threat actor, or if a threat actor had enabled the "keep print job" functionality on the printer, as a means of staging data for exfiltration?
This JumpSec Labs article does a good job of discussing data sources and tools that can be used in the absence of Windows Event Logs. However, there are a couple of items that do need to be mentioned; for example, artifacts should never be viewed in isolation from each other, as context is missed. In the article, the author mentions the use of Prefetch files, and then the AppCompatCache/ShimCache, to demonstrate program execution. Rather than being viewed separately, these should be viewed together whenever possible. The reason is that 32-bit Windows XP was the only version of Windows where the AppCompatCache data recorded a second time stamp, indicating the time of last execution; in all other instances, the available time stamp is the last modified time extracted from the $STANDARD_INFORMATION attribute within the MFT. I've seen cases over the years...not just my own cases, but also investigations discussed during conference presentations...where the threat actor placed the EXE on the system and "time stomped" it before executing it. In one instance (shared at a conference in 2015) the misinterpretation of this data had a profound, negative impact on the "victim", as it was a PCI case and the "window of compromise" was 4 yrs, rather than a couple of weeks.
All of this is to say that I highly recommend the intentional, purposeful use of tools to further forensic analysis. However, at the end of the day, it is still incumbent upon the analyst to correctly interpret the data presented by the tools, and this interpretation is often heavily impacted by the completeness of data collection and parsing.
Artifact Constellations
As discussed the JumpSec Labs article, analysts may encounter systems upon which some data sources are not readily accessible. The article describes threads that analysts can pursue in the absence of Windows Event Logs, but something the article doesn't touch on is "artifact constellations"; that is, when some action occurs on a system, there are often secondary and tertiary artifacts created that, when considered together, provide much greater evidence of activity.
Articles like this one do a great job of illustrating some of the different artifacts available, but it is still up to the analyst to complete the constellation, and to correctly interpret the data.
Spelling & Grammar
Take spelling and grammar seriously. I know a lot of folks don't, and that when someone points out poor spelling, they're referred to as the "grammar police" or as a "spelling Nazi".
However, consider this...let's say you work for me, and don't care about spelling or grammar. Now, I have to review EVERYTHING you produce before it goes to the next level, be it an internal executive or a customer. I know that every time you send me a report or an email via Outlook, it's going to be full of words with red squiggly underlines...you know, MSWord's way of saying, "hey, you misspelled this word...". Once those are corrected, I still have to spend a great deal of time reviewing what you wrote, because now I have to deal with incorrect grammar, incomplete sentences, and correctly spelled but incorrect words.
Let's reduce it a little bit...what happens when you transpose an IOC? Let's say you transpose an IP address or a domain name to be blocked, and you misspell it...what happens then? Well, the IOC intended to be blocked isn't, and the organization isn't any better off; in fact, it's worse because everyone thinks the correct IOC has been submitted.
What happens when you misspell a Registry value name (or the data) for a setting on a critical system? The system doesn't recognize the value (or data), and the intended functionality is not applied.
Apply the same thought to threat hunting, either as part of a proactive threat hunt or a DFIR threat hunt. Or, if you're looking for an IOC in logs...either way, you misspell it and report, "...nothing found...", what's the result?
Now, let's look at it another way...I work for you, and I'm the one who's not spelling things correctly. In what position does that place you?
No comments:
Post a Comment