Windows Incident Response
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 SYST
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.
Read the original article: