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 deal of insight, it is largely blind to a great deal of on-system artifacts (for example, Windows Event Log records). However, adding EDR telemetry to on-system artifact constellations significantly magnifies the value of both.
As I started researching this issue, the first resource to really jump out at me was this blog post from PenTestLab. It's thorough, and provides a good deal of insight as well as resources. For example, this post links to not only another blog post from b4rtik, but to a compiled DLL from netbiosX that you can download and use in testing. As a side note, be sure to install the Visual C++ redistributable on your system if you don't already have it, in order to get the DLL registration to work (Thanks to @netbiosX for the assist with that!)
I found that there are also other resources on the topic from Microsoft, as well.
Following the PenTestLab blog post, I registered the DLL, waited for a bit, and then collected a copy of the Software hive via the following command:
C:\Users\Public>reg save HKLM\Software software.sav
This testing provides the basis for developing #DFIR resources, including a RegRipper plugin. This allows detections to persist, particularly in larger environments, so that corporate knowledge is maintained.
It also sets the stage for further, additional testing. For example, you can install Sysmon, open a Powershell command prompt, submit the test phrase, and then create a timeline of system activity once calc.exe opens, to determine (or begin developing) the artifact constellation associated with this use of
Speaking of PenTestLab, Sysmon, and taking things a step further, there's this blog post from PenTestLab on Threat Hunting AMSI Bypasses, including not just a Yara rule to run across memory, but also a Registry modification that indicates yet another AMSI bypass.
No comments:
Post a Comment