What is “Events Ripper”?

I posted to LinkedIn recently (see figure 1), sharing the value I’d continued to derive from Events Ripper, a tool I’d written largely for my own use some time ago.

Fig. 1: LinkedIn post

From the comments to this and other LinkedIn posts regarding Events Ripper, I can see that there’s still some confusion about the tool…what it is, what it does, what it’s for.

Now, I’ve posted about Events Ripper a number of times on this blog since I released it about 2 years ago, and those posts are trivial to find, including the post illustrated in figure 2.

Fig. 2: 30 Sept 2022 Blog Post

The point is that these blog posts are trivial to find. For example, while I’ve posted a number of “Events Ripper Update” blog posts over the past 2 years, here’s a really good example of a post from October, 2022 that includes a great deal of content regarding the use of Events Ripper. So, in addition to the repo readme file, there’s a good bit of info available, and I’m more than happy to answer any questions folks may have. 

To allay any lingering confusion, let’s talk a little bit about what Events Ripper is not, then a bit about what it is, and how it works.

What It Is Not
Let’s start with what it’s not…Events Ripper is not an analysis tool, nor does it do analysis. We often see this turn of phrase used to describe various tools, stating that they do analysis, and this is simply not the case. This is especially the case for Events Ripper. 

Let me say this again…Events Ripper does not do analysis. Nor does any other tool. Analysis is something an analyst, a human, does, by applying their knowledge and experience to the data before them. Tools can parse, normalize, even decorate, and present data, but it’s up to an analyst to make sense of the data and present it in an understandable manner.

If you’re not familiar with creating timelines as an investigative resource, and incorporating Windows Event Log records alongside other data sources (file system, Registry, etc.) into an overall timeline, you’re not going to see much use for Events Ripper. When I say, “creating timelines”, I don’t mean what many analysts do with Excel, begrudgingly, at the end of an “investigation”. What I mean by “creating timelines” is producing an investigative timeline from multiple data sources as a way to begin, and to facilitate analysis.

If, as an analyst, you believe that there are only three Windows Event Logs of interest…Security, System, and Application…then Events Ripper is not for you. It’s not something you want to be using, as it will provide no value to you. 

If you believe that event IDs are unique, and that event ID 4624 only refers to successful login events, then Events Ripper is not for you, it’s not something that you’ll derive value from using.

If you’re not familiar or comfortable with working at the command line, Events Ripper is not a tool you’ll find a great deal of value in using.

What Is Events Ripper
Events Ripper is a tool intended to facilitate analysis, to identify investigative timeline pivot points and to allow analysts to get to conducting analysis much sooner. The idea is to exploit what analysts have already seen, learned and documented through plugins, to get all analysts on the team (and beyond) to the point where they’re actually conducting analysis much faster. 

I look into endpoints on a daily basis, as part of deeper investigations into malicious activity. Collecting a dozen or fewer Windows Event Log files (the number is usually 9 or 10, under most circumstances) to create a timeline often results in 300K or more lines in the events file, which is the intermediate step to creating an investigative timeline. Again, this number of events is just from Windows Event Log files, so finding anything specific would be akin to finding a needle a huge stack of needles. This is why having a computer look through hundreds of thousands of events, extracting items of interest, is so much more efficient and doing to manually, either by opening individual .evtx files in Event Viewer, or by searching and tabbing through the results.

Even when I’m looking for just one thing, such as a list of all VHD, IMG, and/or ISO files mounted on the endpoint, it’s still a lot of work to parse through one Windows Event Log file and extract that list. While many analysts will download the .evtx file to their analysis workstation, open it locally in Event Viewer, and tab through the events, I’d much rather use available tools to parse and normalize the events in the file, and then use Events Ripper to give me either a simple list, or something a bit more interesting, such a sorted (based on time of ‘surfacing’) list of mounted files. 

How Does It Work
Straight from the readme file in the Github repo for the tool, you start by parsing your data sources into the 5-field, “TLN” format events file, which is an intermediate file format prior to creating an investigative timeline. You then create your timeline (I do), and then run Events Ripper against the events file. This is just a text-based file that contains the events that will be parsed into the investigative timeline, with one event per line. 

If you’re looking for something specific, such as mounted ISO files, you can choose to simply run a single plugin (in this case, mount.pl). If you’re working on something a bit more expansive, run all off the plugins, redirecting the results to a single text file for reference. Just follow the examples in the readme file. 

Event Ripper is incredibly versatile. For example, if I’m working on an incident that involves processes run as child processes of sqlservr.exe, I’ll get a copy of the Application Event Log, parse it, and run the mssql.pl plugin against it. If the output of that plugin tells me that there are multiple instances where the xp_cmdshell stored procedure was enabled, I can then go back to the events file, and create an “overlay” or micro-timeline of just those events, using the following command line:

C:data>type events.txt | find “xp_cmdshell” > x_events.txt

I can then create the timeline using the following command:

C:tools>parse -f c:datax_events.txt > c:datax_tln.txt

I know have an “overlay” timeline of just those events that contain references to the stored procedure, and very often these events will correspond to malicious use of the stored procedure to run commands on the endpoint with the privileges of the MSSQL instance (usually SYSTEM). 

Using simple DOS-based tools and commands, such as “find”, “findstr”, and redirection operators (all stuff I learned from using MS DOS 3.3 and beyond), I can create investigative timelines and case notes to thoroughly document my findings, facilitating analysis and getting me to results in a quick, efficient manner. This leads to incident scoping, as well as threat actor profiling, and developing detections, protection mechanisms, and documenting control efficacy. 

Tools like Events Ripper also provide a phenomenal means for documenting, retaining, and building on “corporate knowledge”; this applies equally well to both internal and consulting teams. If one analyst sees something, there’s no reason why they can’t develop and document it in a plugin, and share it with others so that now, other analysts can benefit from the knowledge without having to have had the experience. 

Conclusion
Again, Events Ripper does not do analysis…no tool does, regardless of what folks say about it. What Events Ripper does is facilitates analysis by allowing analysts to document their findings in a reproduceable manner, in a way that other analysts can exploit the knowledge without having to have the same analysis experience. 

Source: Read More