Events Ripper Update

Yet again, recent incidents have led to Events Ripper being updated. This time, it's an updated plugin, and a new plugin.

appissue.pl - I updated this plugin based on Josh's finding and Tweet; I can't say that I've ever seen this event before, but when Josh mentioned it, I thought, hey, this is a great way to go about validating activity! Okay, so here's a batch file, and we see commands run via EDR telemetry...but do they succeed?? We may assume that they do, but it's a pretty straightforward process to validate these findings; in the incident that Josh reported, it turns out that the driver being loaded failed because it was blocked. Correlate that event with the other two events that Josh pointed out, and you've got pretty decent evidence indicating that while an infection was attempted and the driver was created within the file system, it's not loading. This gives us some headspace for our investigation, and provides evidence we can report to regulatory oversight bodies, etc.

sec5381.pl - I created this plugin as a result of analysis conducted during a recent investigation into the use of credential theft tools. We'd seen the use of a number of credential theft tools...lazagne, mimikatz, VNCPassView, PasswordFox64, etc. Some of these triggered alerts, so I started by creating a timeline from the EDR telemetry. As our telemetry does a great job of illustrating the process tree, I was able to tie all of these alerts, as well as other processes identified by analysts hunting for additional activity, to the original login session. As I began using the process creation time stamps to pivot into a timeline created from WEVTX data, I began to see several Microsoft-Windows-Security-Auditing/5381 records; in two instances, these events correlated to the use of WebBrowserPassView and IEPV. 

What's interesting about this event record is that it includes the logon ID; I ran the following commands:

type events.txt | find "<logonID>" > id_events.txt
parser -f id_events.txt > id_tln.txt

I now had a micro-timeline of just the events associated with the unique logon ID, so I could see the breadth of the activity (i.e., when it started, when it ended, what occurred during that time, etc.). Depending upon the audit configuration of the endpoint, there are a number of other event records that also contain the logon ID, and would be included in our micro-timeline. However, even without those, we can fill in "gaps" via other means, such as just looking at the span of time, from the "oldest" to the most recent event from our "logon ID" search.

By the way, this approach is nothing new. I've used this technique...used simple DOS commands...to navigate, pivot, and get a specific view into timelines for some time now. This is part of the reason why I persist in maintaining the intermediate file ("events.txt") in a flat text file; it's easy to parse and enumerate with simple commands (no SQL queries needed), it's easy to combine multiple timelines, and the files compress really well for storage and shipping. Because they're text-based, they also don't need any special tools to access; doing a search in Notepad++, for example, I can choose the "Count" option to see how many times the search term appears in the file, and I can search backward to find the earliest event associated with that term.