This post is the ninth of a multi-part series called Advanced Methods to Detect Advanced Cyber Attacks. The series explores advanced investigative analytic searches that analyze network traffic and enable incident responders and security analysts to think and react as fast as the attackers targeting their organization’s network.
Today we’re going to look at how to start playing Six Degrees of Kevin Bacon with network traffic for the purpose of efficiently executing a network security investigation.
In the Computer Network Defense version of Six Degrees, we’re looking to link network hosts together based on who they’ve exchanged traffic with (vs. starring in films together). When hosts contact each other, either to exchange information or to ask network configuration questions, that activity can be captured both in the form of event logs and the raw network traffic. We can examine this traffic to inspect relationships between network hosts based on common activity with other hosts. Our goal is to identify all of the network hosts that communicated with each of the two hosts (or groups of hosts) we are investigating. This is a simple form of graph analysis and is a powerful investigation tool.
Why would someone want to spend time doing this? To answer that question, let’s imagine the following scenario:
You’re a security analyst investigating a confirmed intrusion on your corporate network. In your initial assessment you’ve learned that an external attacker has compromised a number of internal hosts, installed malicious software, and has had plenty of time to move laterally and send information back to her attack infrastructure. Initial isolation and containment has been performed, and your task now is to map out the full scope of the compromise and produce an exhaustive timeline of attacker activities so that a full impact assessment and root cause analysis can be performed. Looking at log files and host-specific information is helping you piece this together, but you need a way to discover additional internal compromised hosts and external attacker hosts by analyzing communications. Without this you won’t be certain that you have your arms around the full extent of the intrusion.
In today’s security landscape, analysts find themselves in this high-pressure scenario much more frequently than they would prefer (their preference being never). And when they are in this situation, they enter a world of uncertainties. They are continually surrounded by questions like:
- Did we manage to identify and block all of the attacker’s infrastructure?
- Did we find all the affected internal hosts?
- What data or intellectual property did the attacker get to and were they able to exfiltrate it?
- Did the attacker go through us to attack another party?
- Are there any hidden infections, backdoors, or stealthy communication pathways we haven’t found yet?
- And on and on…
So why is it so hard to answer these questions? Well the data the analyst is using is often a partial view of reality and is scattered across a bunch of different sources. What do we mean by that?
Log files provide a partial view of reality, and they sometimes lie to analysts. Logs only contain what the endpoint, server, or network device logged based on its configuration. And, perhaps more importantly, log files can be altered by attackers during an intrusion. Attackers know how to flood log files so that important entries roll off, and they know how to purge log entries to cover their tracks. So logs are at best an unreliable partial story of what happened in the network.
In Novetta’s network traffic analysis solution, Novetta Cyber Analytics, there is a capability to rapidly perform this type of discovery by looking at network traffic metadata instead of log file sources. Network traffic is more reliable than logs because it can’t be doctored by attackers — it’s the record of activity on the network and it can’t be purged or altered. It’s like surveillance data that’s captured, analyzed, indexed, and sent to a secure repository.
Within Novetta Cyber Analytics there are many pre-built analytics that can be performed on metadata extracted from network traffic. One particular analytic can immediately be applied in investigation situations like these and it’s called Two Degrees of Separation — it’s the first step in playing Six Degrees. Here’s how it works:
Two Degrees of Separation is a straightforward and powerful search that takes two known hosts (IP addresses) or network segments (CIDR blocks) as inputs and returns all IP addresses that communicate with both. So, as a simple example, if attacker A talks to 20 hosts on the corporate network, and client B talks to 50 hosts on the corporate network, this analytic will find the overlap.
We can use this search to intersect traffic created by an attacker node with traffic created by a known compromised host, where the attacker node and the compromised host never communicated directly. This creates a Venn diagram that looks like this:
The security analyst now knows where to focus her attention.
A more complex example is one in which an attacker has used the same command and control (C&C) infrastructure across multiple compromised networks. If the attacker is using the same attack nodes to hit multiple corporate subnets or locations, then we can use that information to connect the dots of an attack and put together a more complete timeline of events.
This scenario would look more like this:
In this scenario the ability to intersect traffic provides analysts the ability to rapidly narrow in on infrastructure areas that could also have been impacted during the attack.
So we see in today’s topic that analysts who have the ability to perform network traffic analytics are armed with a powerful tool for performing investigations. Perhaps think about how you would do this in your current environment. How would you play Six Degrees (or even Two Degrees) using your current tools and how long would it take?
We’ll stop there for today. Thanks for reading all the way through! I hope you enjoyed the content and it provoked a few interesting thoughts.
As a preview for next month, our next and final blog in this series will be on the topic of identifying unknown services within a network. How can a security solution separate normal well-formed traffic from abnormal attacker traffic by looking at network data only, and why is that useful? Subscribe to the blog or check back a little later for that post.
Read the final post in this series: Unknown Service.