Lateral Movement in the Cloud After Initial Access

Lateral movement in a traditional network looks like an attacker hopping from machine to machine, leaving traffic a defender might spot. In the cloud, the picture is different and quieter. The adversary does not need to touch another host — they need another identity. Movement happens through API calls that assume roles, read secrets, and pivot between services, most of which look like ordinary, authorised activity.

Initial access is only the opening move: a leaked key, an SSRF into the metadata service, a compromised CI token, a phished console login. What determines the outcome is what the attacker can do next. In the cloud, "next" is rarely a network exploit. It is a chain through the control plane — assume this role, read that secret, invoke that function — that walks from a foothold to the data or the admin access they came for.

The cloud's lateral-movement primitives

• Role chaining. One role is permitted to assume another, which can assume a third. Each hop is a legitimate AssumeRole call; the chain lands somewhere far more privileged than the start.
• Harvesting secrets. A foothold with read access to a secret store or environment variables collects credentials to databases, SaaS APIs, and other accounts — pivoting beyond the cloud entirely.
• Metadata and instance takeover. Reaching the metadata service, or running commands on instances via SSM, yields whatever roles those workloads carry.
• Service-to-service pivots. Writing to a queue, updating a Lambda, or dropping a file where another service will process it lets the attacker execute in a different, often more trusted, security context.
• Cross-account jumps. Over-trusting cross-account roles turn one compromised account into a beachhead on the others.

Why the network won't save you

Traditional lateral-movement detection watches for unusual internal connections. That lens mostly misses cloud movement, because the attacker's traffic is HTTPS to the cloud provider's own API endpoints — indistinguishable, at the packet level, from every legitimate call your workloads make. The signal is not in the network; it is in the identity behaviour: a role assuming another it never has before, a service account reading secrets outside its pattern, a credential used from a new location.

Constraining the blast radius

• Least privilege as containment. The narrower each identity, the shorter every chain. Most movement depends on one over-permissioned role in the middle.
• Break the chains. Restrict which roles can assume which, require external IDs on cross-account trust, and separate accounts so a pivot has a hard wall to cross.
• Short-lived credentials. Tokens that expire in minutes give an attacker far less to harvest and reuse.
• Detect on identity, not packets. Alert on first-time role assumptions, anomalous secret access, and credentials used from new geographies or ASNs.
• Segment blast radius by account. A multi-account design means compromising one workload does not hand over the estate.

Cloud lateral movement is the discipline of turning one identity into many, quietly, through the front door of the API. Stopping it is less about walls and more about limiting what each identity can reach and noticing when one behaves out of character. Both require a complete map of the identities and trust relationships you actually have — and you can't defend what you haven't discovered.