Lateral Movement in the 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 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.
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 can be reached from a compromised one
- What credentials can 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 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):
- The network layer.
- The Identity & Access Management (IAM) layer.
- 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.