Cybersecurity first principles: intrusion kill chains.

By Rick Howard

May 26, 2020

CSO Perspectives is a weekly column and podcast where Rick Howard discusses the ideas, strategies and technologies that senior cybersecurity executives wrestle with on a daily basis.

Cybersecurity first principles: intrusion kill chains.

Listen to the podcast episode.

Note: This is the third essay in a planned series that discusses the development of a general purpose cybersecurity strategy for all network defender practitioners-- be they from the commercial sector, government enterprise, or academic institutions-- using the concept of first principles. The first essay explained what first principles are in general and what the very first principle should be for any infosec program. The second essay discussed zero trust. This third essay will discuss intrusion kill chains as the next building block that we will install on the infosec first principle wall.

Let’s talk about that wall. I am using it as a metaphor to describe our first-principle cybersecurity program. Think of our program as a brick wall we’re constructing from scratch. The foundation has to be flat and level and strong, something that can hold the entire weight of the program, the complete weight of the blocks we’re going to put on it later. In that first essay, I concluded that the ultimate first principle foundation for all network defenders is this:

Reduce the probability of material impact to my organization due to a cyber event.

That’s it. Nothing else matters. This simple statement is the pillar on which we can build an entire infosec program.

Defense-in-depth vs intrusion kill chains.

The idea of cyber intrusion kill chains is so obvious to me that I am gobsmacked that many organizations do not have a robust strategy already in place. It began with the famous white paper from the Lockheed Martin research team back in 2010. It introduced the network defender world to the concept and revolutionized how we all thought about digital protection. The previous strategy was something called defense-in-depth and most network defenders were pursuing some version of it as far back as the late 1980s.

The main characteristic of defense-in-depth (and you can say this about zero trust, too) is that it’s passive. Network defenders would install overlapping digital defensive controls and hope the bad guys would run into them. The in-depth part of the strategy was the idea that if the bad guys somehow got past the first control, they would probably run into the second. And if they got past that, they would most likely run into the third, etcetera, etcetera. The reason the strategy is passive is that it’s not based on how specific cyber adversaries attack their victims. It’s a general-purpose protection scheme.

It is similar to an infantry platoon setting up a defensive perimeter. The soldiers have no specific knowledge of when and where the enemy will attack so they install a defense-in-depth posture. They dig fighting positions so that they’re not exposed to enemy fire. They put overhead cover on the fighting positions so that they’re protected from enemy fragmentation. They coordinate overlapping fields of fire with the positions to their left and right so that there are no gaps in the coverage area to their front. You get the idea. Defense-in-depth tactics are not based on intelligence. They are general-purpose practices designed to defend against any attack. They are necessary but not sufficient.

The genius of the intrusion kill chain strategy is that it provides a framework for deploying defenses where we know the enemy must travel. In my infantry platoon scenario, it’s like discovering that we know the exact avenue of approach the enemy will take to attack our position. If the platoon leaders knew that the approaching enemy would most likely cross the river in front of our position at a specific point, and then walk up a slight rise, they would have something special planned when the enemy got there. It’s the same thing for digital defense.

The Lockheed Martin team realized that all cyber adversaries, regardless of their motivation— crime, espionage, hacktivism, low-level-cyber-conflict, and general mischief— and regardless of the toolset they use, must traverse the same digital ground to complete their task. All adversaries have to negotiate a set of the same attack milestones to be successful. Lockheed Martin called these milestones the intrusion kill chain taking the name from what the U.S. Air Force called their process for quickly tracking down targets on the battlefield.

Origins of the intrusion kill chain.

During the first Gulf War in 1991, Iraq’s mobile SCUD missiles gave the United States Air Force and Navy pilots trouble. Iraqi soldiers were able to fire them long before the U.S. planes could find their location and blow them up. After the war, General John Jumper changed air combat doctrine to address that issue by formalizing the techniques necessary to compress the time it takes to find and kill the enemy on the battlefield. The Air Force’s target acquisition model is called Find, Fix, Track, Target, Engage, and Assess, also known as F2T2EA, because, you know, military acronyms. More simply, they call it the kill chain. Jumper’s mandate to the Air Force was to compress the kill chain from hours or days to under 10 minutes. The Lockheed Martin research team took that idea and applied it to cyber defense.

Since the original Lockheed Martin publication, many network defenders have tweaked the concept by adding their own special sauce to it. But from the original, these are the seven attacker milestones:

Recon
Weaponization
Delivery
Exploitation
Installation
Command and Control
Actions on the Objective

Think about each milestone in the attack sequence, each link in the chain, as an opportunity to disrupt the hacking campaign. Instead of the defense-in-depth idea of general purpose controls, network defenders deploy controls at every phase of the intrusion kill chain designed specifically for every known adversary campaign.

For example, if we want to stop a Fancy Bear campaign, we design and deploy specific controls to counter how Fancy Bear recons for victim weaknesses, for the malware they deploy, for the techniques they use to deliver their malware to their victims, for the exploitation code they use to compromise victim zero, for the process they use to download and install additional tools to help them in their mission, for the interdiction of their communications channel, and finally, for how they move laterally within the victim’s network looking for the data they have come to steal or destroy. With this model, we know exactly where Fancy Bear is going to cross the river in the digital space. So let’s make it difficult for the Bear every step of the way. Let’s look at an example.

Kill chain analysis of Fancy Bear and the DNC Hacks

On 13 July 2018, the FBI indicted twelve members of the Russian Federation’s General Staff Main Intelligence Directorate (GRU) for conducting a successful adversary attack campaign that targeted Secretary Hilary Clinton, the Democratic Congressional Campaign Committee (DCCC), and the Democratic National Committee (DNC) just prior to the U.S. Presidential Election of 2016.

As a network defender, you owe it to yourself to read the indictment. It reads like something a commercial cybersecurity vendor intel team would release for publicity. Admittedly, I don’t read a lot of FBI Indictments, but I think it fair to say that the amount of detail included in this indictment is extraordinary. And for you newbies out there, if you want to read the perfect case study of an adversary negotiating the intrusion kill chain, well, here is one that’s had national impact.

According to the indictment, from March 2016 until November 2016, members of the Russian military units 26165 and 74455, or Fancy Bear, as the networks defender community refers to them, compromised accounts of over 300 volunteers and employees from the DCCC, the DNC, and Secretary Clinton's campaign team to include the email account of her campaign chairman, John Podesta. They successfully stole email credentials and thousands of email messages from numerous individuals affiliated with the Clinton Campaign and they stole ~50,000 documents from Mr. Podesta. Fancy Bear subsequently leaked hundreds of those documents using fake online personas like DCLeaks & Guccifer 2.0. Here’s how they did it.

Pre-Attack Preparation:

To fund their operation, Fancy Bear mined bitcoin. They then laundered some $95,000 through a web of transactions structured to capitalize on the perceived anonymity of cryptocurrencies. They also used bitcoin for all financial transactions to pay for their command and control infrastructure.
They also built the social media persona DCLeaks & Guccifer 2.0 to leak stolen documents.

Recon:

After owning several victim’s computers, Fancy Bear members conducted a technical recon of the internal victim's networks.
While they were moving laterally within the DCCC and the DNC networks, Fancy Bear members sought files and folders that mentioned “Benghazi" and "opposition research.”
Fancy Bear members reconnoitered the networks of election officials from specific counties in Georgia, Iowa, and Florida.

Weaponization:

Fancy Bear operators created and modified two malware packages, X-Agent and X-Tunnel.

Delivery:

Fancy Bear members spearphished potential victims from spoofed accounts that looked as if they originated with a voter-registration software company. The email contained Word documents that presented the software vendor’s logo but also containerd malware.
They also used a watering-hole attack by compromising the DCCC website and using it to deliver malware to potential victims.

Exploitation:

Fancy Bear members specifically compromised at least ten machines within the DCCC network.
They used the intelligence gained from the DCCC network to compromise the DNC network using stolen credentials.
They used X-Agent Malware on compromised hosts to collect keystrokes (passwords) and screen captures.
They compromised the DCCC website and redirected visitors to a look-alike site called actblues.com.
They also compromised the State of Illinois Board of Elections website.

Command and Control:

Fancy Bear members exfiltrated documents to their own GRU-leased command and control servers located in Arizona and Illinois. They called it their "AMS Panel.”
They placed a proxy server overseas they called the “middle server” designed to obscure communications between the DCCC and the AMS Panel.

Lateral Movement:

Fancy Bear members moved laterally within the DCCC and DNC networks, compromising other victim’s machines seeking files and folders that mentioned “Benghazi" and "opposition research.”

Exfiltration:

Fancy Bear members successfully stole email credentials.
They compressed and encrypted their stolen documents with a tool called “X-Tunnel."
They successfully stole thousands of emails from numerous individuals affiliated with the Clinton Campaign and they stole 50,000+ documents from Secretary Clinton's Campaign chairman.
They also stole the personal information of more than five-hundred-thousand voters from the State of Illinois Board of Elections website.

What do you do with information about the kill chain?

Let’s say that by some miracle, the DNC infosec team knew the attack sequence of the Fancy Bear campaign before March 2016. They didn’t. Nobody in the network defender community knew about this exact sequence. But for the sake of argument, let’s say that they did. What could they have done with that intelligence? For each link in the intrusion kill chain, they could manually devise and deploy prevention controls to deploy to their current security stack to counter each step in the Fancy Bear attack sequence. If they were extremely good, they could automate that process.

Specific actions might have taken these forms

Limit access with your zero trust program to any files related to “opposition research” or “Benghazi.”
Ensure that the internal security stack was looking for signs of X-Agent and X-Tunnel.
Scan the DCCC website for any code that the original webmasters didn’t put there.
Prevent access with your zero trust program from any employee to any web applications not specifically authorized especially the ones going to foerign countries.

Admittedly, this is Monday-morning quarterbacking at its worst. The community didn’t know any of the intelligence in the FBI indictment before it happened, but we knew pieces of it. The network defender community started seeing the first versions of X-Agent at least as early as 2010, six years before the DNC attacks. We saw the first versions of x-tunnel at least a year before the attacks in 2015. Even though the architects of this Fancy Bear campaign designed it specifically for Secretary Clinton, the DNC, and the DCCC, they didn’t do anything extraordinary here.

You might be saying that this is all well and good for government intelligence agencies and Fortune 500 companies. They can track adversary activity across the intrusion kill chain, but you have a small staff. You don’t have the resources to do this kind of thing. How do small and medium-sized businesses compete against the seemingly limitless army of hackers out there trying to cause my organization harm?

Here’s a non-intuitive thought. There are not that many of them.

How many adversary campaigns are there?

It turns out that the number of adversary groups like Fancy Bear active on the Internet on any given day is not that big. Nobody knows for sure how many there are, but the Cyber Threat Alliance, a cyber threat intelligence sharing group made up of about twenty-eight cybersecurity vendors, estimates that the number is between fifty and a hundred. The number of attack campaigns they run collectively is also not known for sure. But we do know that many groups run multiple campaigns. The Cyber Threat Alliance estimates that the total number of campaigns from all of the adversary groups could be as high as five-hundred on any particular day.

The thing about multiple campaigns run by a specific adversary group like Fancy Bear is that they are not 100% unique. Fancy Bear doesn’t string one set of techniques across the intrusion kill chain for one campaign and then string another completely different set of techniques for another. Instead, Fancy Bear tweaks. The group uses many of the same elements of campaign one in campaign two but might use a different malware version, or a different communications protocol, or change some other bit of the attack sequence.

In reality, adversary groups don’t run five-hundred unique campaigns on any given day. They run variations of a smaller number of campaigns. And that puts the advantage with the defender. If you already have prevention controls in place for campaign one, when campaign two emerges, your networks are already protected for the bulk of the attack sequence except for the new pieces.

The trick is to get the intelligence on the new bits quickly, design prevention controls for your already deployed security stack, and then distribute those controls to the security stack in all of its permutations behind the traditional perimeter, in your data centers, on your employee mobile devices, in your SaaS services, and in your multi cloud IaaS workloads. How we do that will take up two additional blocks on our first principle infosecurity wall: Intelligence Operations and DevSecOps. I will talk about those in later essays in the series.

Blocking technical things versus preventing adversary success.

My biggest pet peeve with the network defender community is that we have become comfortable reacting to the latest technical threats and don’t stop to think that there are humans behind those technical threats trying to accomplish some task. We like to talk about the latest zero day exploit, or the newest piece of malware, or the recent ransomware. We put all of our resources into blocking these one-off technical tools and spend little time trying to stop the humans that use them to accomplish some mission.

Our foundational first principle is to reduce the probability of a material impact to our company due to a cyber event. We can play whack-a-mole by blocking technical tools all day long and will probably have some effect. But if we decide to utterly defeat the humans that are using those tools, our impact can be so much larger. We shouldn’t just be blocking a random tool with no relation to the hackers behind it. We should be blocking every single tool, every possible technique, at every phase of the intrusion kill chain that the hackers use. We want to give Fancy Bear no place to hide. We want to force Fancy Bear to spend resources designing new attack tools and then we block those too.

And I am not talking about attribution here either. For the most part, it doesn’t matter if Fancy Bear is Russian, Chinese, Klingon, or for that matter working for Hydra. What matters is the digital path Fancy Bear takes to harm my organization. Just like our infantry platoon leader, I want to have something ready at every digital river crossing, every digital bridge, and at every digital mountain ridge Fancy Bear crosses. I want the Bear so frustrated with the obstacles I’ve put in its path that it decides I’m no longer worth the effort. You can’t do that if you only focus on random tools with no context about which group is using them. You can only do that if you design defensive campaigns targeting specific adversary campaigns. And it’s not like there are a million campaigns running today. There are only five hundred. If you chose to, you could probably manage it all in a spreadsheet. You may not want to do it that way, but you could.

One more block on the wall.

Intrusion kill chains are part of the key atomic thinking to our first principle cybersecurity wall. It’s as important as the zero trust strategy. You can’t just pursue one strategy and not do the other. You have to do both. In fact, you'll also have to follow a third strategy, resilience, but we’ll talk about that in the next essay.

For this building block though, we add a key element into our infosec wall. We’re no longer just implementing a passive strategy for a general purpose defense. Intrusion kill chains allow us to pursue an active defensive strategy tailored for how the adversary will specifically attack us, and it gives us another lever to pull to reduce the probability of material impact from a cyber event.