Lateral Movement in the Cloud
Tags: cloud, security, threatmodeling, incidentresponse
Published: 2020-10-13 15:32:45

---
title: Lateral Movement in the Cloud
published: true
date: 2020-09-16 22:53:55 UTC
tags: cloud, security, threatmodeling, incidentresponse
canonical_url: https://cloudberry.engineering/article/lateral-movement-cloud/
---

In the context of incident response lateral movement is how attackers are able to penetrate deeper inside a system. Understanding this concept is critical to contain an ongoing breach.

## The Attack Lifecycle

There are many [models](https://en.wikipedia.org/wiki/Kill_chain#The_cyber_kill_chain) that help to understand an attack lifecycle in depth, but from a practical perspective assume all attackers will do the following endlessly: **compromise a resource** , **gain persistence** , **move laterally**.

![The attack lifecycle](https://cloudberry.engineering/attacklifecycle-lateralmovement.jpg)

As a defender you will need to walk forward and backward this cycle to stop the bleeding, and the tricky part is indetifying the **entry point** : the resource that have been compromised first.

The entry point is the front door you left open. It is usually a resource that is publicly exposed like a virtual machine running a public website.

If you identify a compromised resource that is not publicly exposed, most probably the attacker reached it by **moving laterally**.

## Modelling the movements

Lateral movement happens when the attacker compromise other resources from one which has already been breached.

It is enabled by two factors:

- What other resources we be reached from a compromised one
- What credentials we be found on compromised resources

These two factors defines the **blast radius** : the area that an attacker can _traverse_ inside your infrastructure and, as a consequence, the impact of the attack.

![The blast radius](https://cloudberry.engineering/blastradius.jpg)

The text book example of lateral movement is breaching a website, gain access to the virtual machine running it, finding the credentials to the database in the backend and compromise it.

In the cloud you can model attacker movements on three layers, which are loosely related to the way the cloud stack is segmented (IaaS, PaaS, SaaS):

1. The network layer.
2. The Identity & Access Management (IAM) layer.
3. The application layer.

## Network Layer

The network layer is mostly tied to infrastructure services (the “I” in IaaS).

It boils down to a classic network security problem: which cloud services are connected to the same Virtual Private Network (VPC), which firewall rules are in place, etc.

In the worst case a compromised virtual machine’s blast radius is everything attached to the same VPC.

## Identity & Access Management Layer

IAM is how access controls is governed in the cloud. It’s about authorising identities to certain actions on specific cloud services.

The concept of identity is fluid between cloud providers but it can be described as the authenticated entity to which authorisation grants are assigned. A user, a group, a service account, a workload.

Because identities can be very different things, and authorisation grants can be very granular, understanding the blast radius becomes complicated quickly.

From the attacker perspective compromising a user or compromising a random cloud service can have the very same impact if they have the same authorisation grants.

Instead from a defender point of view you will hardly be able to apply the same security controls, the same auditing and the same monitoring practices.

In short IAM is the layer where the economics of an attack skews in favour of attackers.

## Application Layer

All the secrets and credentials that are bundled in the application layer of a service will also contribute to the blast radius, since they can be used to access and compromise further resources.

Think of passwords to databases, api tokens, credentials to third party services.

## Conclusion

Modelling the lateral movements and the blast radius of an attack is an obligatory step for a successful containment of a breach.

An incident resolution will be as effective as how fast we will be able to answer the question: _“what services am I running in my infrastructure, and how can I reach them?”_

So be prepared: invest in an inventory of running cloud services you can query quickly and map their interconnections on the three different layers.

---

Did you find this post interesting? I’d love to hear your thoughts: `hello AT cloudberry.engineering`

I write about **cloud security** on my [blog](https://cloudberry.engineering), you can subscribe to the [RSS feed](https://cloudberry.engineering/index.xml) or to the [newsletter](http://eepurl.com/hecKnf).