A few years ago at the RSA Conference I co-presented on the top cloud attack “kill chains”. Shawn Harris @infotechwarrior and I walked through what we considered to be the top 10+ real world cloud attacks. For each attack, we walked through each step, and some attacks had multiple branches to show the different options.

We called these “kill chains”, but technically, a cyber kill chain is a very specific technique for modeling attacks developed by Lockheed Martin. Each attack starts with Reconnaissance and runs through a series of proscribed steps until Actions on Objectives. In the talk, we pointed to Lockheed Martin’s work and how our approach differed since we didn’t limit ourselves to proscribed steps. Instead, we walked through each step for a successful attack. This also differs from the MITRE ATT&CK tool, which instead focuses on categorizing attack techniques into categories but doesn’t require a given attack to go through every stage in order. ATT&CK also includes in-depth modeling for techniques and sub-techniques.

Both tools help us model attacks to identify where we can insert security controls to break them. I aways liked the “chain” in “kill chain” since breaking one link in the steps to a successful attack stops the attack. But… kill chain kind of sounds like something a defense contractor would come up with. ATT&CK takes a different approach and documents adversary TTPs (tactics, techniques, and procedures) into a knowledge base. Both help us describe how attackers work to help us define our defenses.

Inspired by the Cloud

The original motivation for that RSA Conference presentation was the lack of public information on how attackers really break into cloud deployments. Most of the research reflected cool things the researcher was interested in, not necessarily how attacks really succeeded. We looked deeply at ATT&CK and the Cyber Kill chain, merging the concepts a bit to map out the exact series of steps for each of the top cloud attacks. The modeling helps find commonalities and chokepoints that could prevent multiple attacks.

There just isn’t enough collective institutional knowledge on cloud attacks, so defenders need cleaner maps to help them better internalize how these attacks work.

We called them kill chains even though they weren’t, and about six months ago on a call with an org who took our presentation and adopted it internally, they said, “these aren’t really kill chains, they are more like attack sequences.”  I hate that I can’t remember who I was talking with because they deserve all the credit for the term.

Attack Sequence is a much better description for the work since it maps the exact sequence of steps needed for the attack to succeed and can incorporate the different paths that might lead to the same end exploit. I posted that on Twitter and got some great responses:

Building an Attack Sequence

Attack Sequences aren’t a rigid model with pre-defined categories. Those absolutely have their place, but think more in terms of the map that ties together those TTPs to show the start to finish of an attack. Unlike the Lockheed Kill chain, the Attack Sequence can map different paths to the same destination. Let’s look at cloud ransomware as an example:

This model highlights a few points:

• There are two potential start points – exposed credentials or a compromised workload. There is an entirely different sequence for exposed credentials that includes much more detail, but this sequence can back-reference that one to focus on ransomware attacks.
• There is a bridge where the attacker can move from a compromised workload with storage access into the management plane, or they can work directly on the data within the workload.
• Both paths converge again with the uploading of a ransom note.
• There are other sequences to ransomware, but this focuses on the most common paths. You could obviously create an exhaustive model.
• TTPs and Indicators of Attack/Compromise can be identified and documented for each stage of the sequence.
• This is a generic sequence (it applies to most cloud providers), but it isn’t hard to extend this to a version for a provider or even a particular cloud service.
• Building defenses means breaking each possible path, or where the paths combine. PRO TIP: exposed credentials are seen in the vast majority of cloud attack sequences.

It’s a flexible approach that’s easy to understand. You can keep it high-level like my example or dig deep and model specific indicators. I think it pairs wonderfully with ATT&CK.

Even automated attacks have an adversary behind them. Knowing TTPs and IoCs is important, but so is understanding the big picture of how the attack ties together, and the adversaries different options.