Modeling Multistep Attack Scenarios for Detection

Home » Sled Meta Blog » Incident Response » Modeling Multistep Attack Scenarios for Detection
Many incidents that impact an organization’s security involve multiple steps. For example, an alert that a malicious email was transferred over the network is of concern, but there can be many thousands of these per day in a typical environment, and vetting each one out individually is prohibitive. Of more interest to the defender would be information about a malicious email being delivered, followed by a user clicking on a link contained in the email, followed by any downloads initiated by that user from blacklisted servers. In this example, we have an indicator (malicious email) followed by an action (clicked a link), followed by another action (download). In general, a “behavior” or “attack” consists of a sequence of causally related activities. Vetting these complex behaviors out by hand can be tedious at best, and intractable in most cases. You have to manually implement an algorithm known as “forward chaining”. Start with the first step in the sequence, and use attributes from the sensor data to perform a query for the second step using results from the previous query, and continue through the sequence until either a result is found or the trail goes cold. One interesting aspect of the “forward chaining” algorithm is that it explodes in both data and time. Performing this task by hand is more or less impossible, yet we commonly refer to this practice as “incident response”. These “incident responders” rely on a tremendous amount of experience, domain knowledge, and expertise to extract out behaviors that could potentially be security incidents. At Packetsled, we chose to capture that knowledge in a repeatable way.

Capturing knowledge from domain experts into models is a broad research topic, but I think we would all agree that at some point you will need a designer, e.g., a method for users to build models of attacks, so let’s start there. We chose a graphical notation for our models. Domain experts can visually model the causal relationships between queries, and those queries can contain forward- and backward- chaining references, e.g., those queries can depend on the results of previous or future queries. This is the magic.

Let’s create an example model for the example of a user clicking a malicious email link followed by an infection.

The first step simply looks for an email that contains links
In the second step, we look for any url that was present in the previous step. Note the $ syntax in the query, this is forward-chaining. In these queries, we can refer to the results of previous queries, and it is implemented automatically for you by the platform.

In the third step, we leverage the rich threat detection and intel provided by the packetsled platform.

Finally, we create our own custom alert

Now, when we execute this rule (which can be scheduled to execute automatically as often as we like), it will detect all three of these steps, correlate them, and provide us with a custom alert in a dashboard. Clicking on the alert will show us all of the individual steps, and the detailed flow metadata for each step.

By only alerting when a potentially impactful event occurs this approach can reduce the number of alerts that need investigation by orders of magnitude. Having 50 or 100 of these rules executing continuously would give leverage to the defender by surfacing actionable, vetted out incidents automatically.

Giving users a simple way to model attack behaviors and automating them at scale is just the beginning. In a future post I intend to explain how we can generalize the set of rules into a single model, capable of recognizing potential novel attacks not present in any of the individual rules.
in Incident Response by Troy Molsberry Comments are off

© 2017 PacketSled, Inc.