The (Mis)Use of Artifact Categories

This article has been indexed from

Windows Incident Response

Very often in DFIR, we categorize artifacts in an easy-to-understand and easy-to-digest manner, as using or relying on these categories often helps us navigate our investigations. There are also times when we reduce those artifacts to a level where they’re easier to understand, and in doing so, the categorization of the artifact isn’t quite accurate. As such, it’s necessary now and again to go back and take a look at that categorization to determine if still holds, or if it truly served the community in the manner intended.

SPOILER ALERT – TL:DR 
Within the DFIR community, we should not be hanging investigation findings on single artifacts in isolation. If there are gaps in data, they need to be recognized, understood and communicated. Do not spackle those gaps over with guesswork and assumption; instead, ensure that you’re validating your findings through artifact constellations.

Program Execution
One such artifact category is Program Execution. As with other categories, this one often lists single artifacts, in isolation, that provide an indication to the examiner that a program may have been executed on the endpoint. This issue of the category’s misuse sprouts from when analysts do not use it as an indication for further investigation, but instead look to those single artifacts on which to build their findings, without further validation or support.

To start, the MITRE ATT&CK framework includes an “Execution” tactic, and the description of the Execution tactic includes the following:

The adversary is trying to run malicious code.

Execution consists of techniques that result in adversary-controlled code running on a local or remote system. Techniques that run malicious code are often paired with techniques from all other tactics to achieve broader goals, like exploring a network or stealing data.

Note that the description specifies “…trying to run code”; this does not say that it succeeded. This is an apt and necessary distinction, as there are times (many, many times) when code is attempted to be run but is not successful for some reason. As stated in the description, the tactic provides a number of techniques th

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

Read the original article: