Pivoting Between Evidence Sources for Better Investigations
An incident investigation will only go as far as the evidence allows it. Of course, there’s a lot of components that have to come together to make that happen. The network must support the collection of robust and diverse evidence sources and it must be searchable by the analyst. From there, the incident investigation hinges on the ability of the analyst to ask questions, successfully traverse evidence to answer those questions, and draw conclusions from the findings.
This process is wrought with peril, as evidence isn’t always as clear-cut as we might like for it to be. In this post I’m going to talk about evidence abstraction and why awareness of what evidence represents is important. From there, I’ll show you how Sqrrl allows for quick pivoting between evidence sources so you can traverse this abstraction and make better investigative decisions.
Fundamentally, evidence represents something. If you’ve collected evidence it likely represents an artifact left by an attacker who has accessed your network. It is any data found on disk, memory, or the network or can be as large as an entire memory image or as small as a single IP address in a log file.
Figure 1: Evidence Abstraction
This concept of representation is important because different types of evidence also represent different things. For example, an IP address represents a logical address assigned to a physical system, but it not fully equivalent to that physical system. After all, I can change my IP address rather easily and another system could assume the one I had. This separation between the physical system and something that represents it, the IP address, is an abstraction.
Ignorance of these abstractions can get you into trouble. Consider a scenario where I’ve investigated an IP address and found no sign of malicious activity. Unbeknownst to me, the host I was looking into got a new DHCP lease during the time of interest, and a different host got the address I was looking into. This creates a blind spot which ensures I’m missing things in my cyber incident investigation.
INVESTIGATING AN ABSTRACTION
There are a lot of abstractions when dealing with evidence. Let’s consider one that you’ll face every day — the abstraction between a DNS name and an IP address.
Let’s say that you’ve received an alert that a host on your network is communicating with a suspicious domain found in a blacklist. Since you’re starting with a domain name, you have to know that DNS actually exists as a protocol to provide abstraction that makes it easier for you to access things. When you request a domain name, your system uses DNS to find out the IP address that domain currently represents. That is a layer of abstraction. Normally, the abstraction that exists between that domain and IP will be readily available in DNS transaction logs. This is usually a very simple pivot, and that relationship is mapped below.
Figure 2: Mapping a domain to an IP
The graph of the relationship is straightforward. Most people are going to stop there and continue their cyber incident investigation, but then you’d be missing out on a full examination of the abstraction provided. At the moment the alert was generated, MTZLPLP.3322[.]ORG resolved to 22.214.171.124. That domain represented that IP for that moment in time, but what’s to say it didn’t represent another IP seconds before or second after? By expanding the scope of the investigation to consider the abstraction you will find an opportunity to uncover additional evidence.
In a traditional SIEM, exploring this abstraction would require a fair bit of effort making large queries to multiple data sources. In Sqrrl, it’s a two-click operation. You can right click the domain name and chose the Hostname resolvedTo IP Address expansion. This queries all the DNS and HTTP records in the environment and maps any additional IP addresses that the MTZPLK.3322[.]org subdomain resolved to.
Figure 3: This domain resolved to three IP addresses
This search shows you that this domain has resolved to at least three other IP addresses. The fact that this has been observed in your network data means that your hosts have either resolved or communicated these the addresses. From here, you can pivot off all three of these IP addresses to further the incident investigation. You’ve effectively expanded the scope of the investigation by examining the abstraction inherent to the domain name you were given by the alert.
The previous example demonstrated the most common type of abstraction you’ll face, but there are quite a few others that come into play. Some of those include:
User name to human user: Just because you’ve observed a username authenticating to a system doesn’t mean it’s the human who owns that account. How can you verify if it was the real human user?
File name to file: Even though a threat intel report might cite a malicious e-mail attachment with a specific name, the file name will likely change as the campaign evolves and might even be per unique per e-mail sent. How can you map different file names to the same file?
File hash to file: We usually think of a file hash as having a one to one relationship with a file, but changing that hash is as simple as adding a bit of padding to the file itself. Attackers are doing this more and more. How can you map different file hashes to files with the same practical structure?
What abstractions are present in the evidence you collect? Once you’ve identified those you can begin to map them. If you’re using Sqrrl, you can build your data model to support this so that mapping abstractions is only a couple of clicks away.
Figure 4: Multiple abstractions are represented here. Can you find them all?
It’s not enough to simply have access to evidence, you also should understand what it represents. Understanding evidence abstraction will provide additional leads that can prevent an incident investigation from stalling, and may be the thing that prevents you from making a dangerous mistake and missing something important. Sqrrl excels in mapping the relationships between your data and highlighting evidence abstraction so that you’ll be performing more thorough incident investigations.
This is the third post of the cyber incident investigation how-to series by Chris Sanders. Previous posts can be found here: