Tips for DFIR Analysts, pt VI

This article has been indexed from

Windows Incident Response

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 in

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.

Read the original article: