This article has been indexed from Windows Incident Response
One of Shakespeare’s lines from Hamlet I remember from high school is, “…there are more things on heaven and earth, Horatio, than are dreamt of in your philosophy.” And that’s one of the great things about the #DFIR industry…there’s always something new. I do not for a moment think that I’ve seen everything, and I, for one, find it fascinating when we find something that is either new, or that has been talked about but is being seen “in the wild” for the first time.
Someone mentioned recently that Microsoft’s Antimalware Scan Interface (i.e., AMSI) could be used for persistence, and that got me very interested. This isn’t something specifically or explicitly covered by the MTRE ATT&CK framework, and I wanted to dig into this a bit more to understand it. As it can be used for persistence, it offers not only an opportunity for a detection, but also for a #DFIR detection and artifact constellation that can provide insight into threat actor sophistication and intent, as well as attribution.
AMSI was introduced in 2015, and discussions of issues with it and bypassing it date back to 2016. However, the earliest discussion of the use of AMSI for persistence that I could find is from just last year. An interesting aspect of this means of persistence isn’t so much as a detection itself, but rather how it’s investigated. I’ve worked with analysis and response teams over the years, and one of the recurring questions I’ve had when something “bad” is detected is where that event occurred in relation to others. For example, whether you’re using EDR telemetry or a timeline of system activity, all events tend to have one thing in common…a time stamp indicating the time at which they occurred. That is, either the event itself has an associated time stamp (file system time stamp, Registry key LastWrite time, PE file compile time, etc.), or some monitoring functionality is able to associate a time stamp with the observed event. As such, determining when a “bad” event occurred in relation to other events, such as a system reboot or a user login, can provide insight into determining if the event is the result of some persistence mechanism. This is necessary, as while EDR telemetry in particular can provide a great de
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.
Read the original article: Testing, and taking DFIR a step further