# Cloud Attack Chains Overview

> **Intro:** Attack chains matter because individual findings rarely stay individual for long. A leaked token, a metadata endpoint exposure, or an over-scoped service account often becomes a **multi-step identity and deployment incident**.
>
> **What this page includes**
>
> * the cross-cloud pattern that repeats in AWS, Azure, and GCP
> * where the chain usually begins
> * where defenders can still break it cheaply
> * links to provider-specific deep dives

![Cloud Attack Chains Overview](/files/XihNN4pKsoPLfXG5UQH4) *Figure: Cross-cloud chain from foothold to persistence and business impact.*

## The pattern that repeats across providers

A surprisingly high percentage of cloud incidents follow the same six-stage pattern:

| Stage                         | What the attacker wants                      | Typical examples                                                                                               |
| ----------------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| 1. foothold                   | execute code or obtain a credential          | SSRF, exposed admin panel, leaked CI token, public bucket artifact, poisoned dependency                        |
| 2. identity harvest           | turn execution into **cloud identity**       | IMDS/metadata token, managed identity token, service account token, stolen OIDC token                          |
| 3. discovery                  | understand blast radius                      | list roles, projects, subscriptions, storage, registries, clusters, secrets                                    |
| 4. privilege expansion        | gain a better path than the first credential | assume role, use pass-role style permissions, abuse service principal grants, impersonate service account      |
| 5. platform control           | change deployment or data paths              | push image, modify pipeline, update cluster, change policy, read secrets, exfiltrate storage                   |
| 6. persistence / cover tracks | stay alive and make future access easier     | create new credentials, add federation trust, leave malicious image, alter logging, create backdoor automation |

## Why cloud attack chains accelerate fast

Cloud-native estates compress several control planes into one place:

* **identity** is programmable;
* **compute** can mint new credentials at runtime;
* **deployment** is usually API-driven;
* **logging** is rich, but only if the right categories are enabled;
* **misconfigurations** compound instead of staying isolated.

That combination makes the first foothold less important than the first **usable credential**.

## The five most common starting points

### 1) workload code execution plus metadata access

This is the classic “application bug becomes cloud incident” path. The attacker lands code execution or SSRF, then immediately checks whether runtime credentials are available.

### 2) leaked CI/CD or developer token

The attacker skips the application and goes straight to the delivery layer. If the token can read variables, assume roles, or push artifacts, the whole deployment path may be at risk.

### 3) over-privileged workload identity

The app is not necessarily vulnerable in the traditional sense. It simply runs with more cloud privileges than its job requires.

### 4) storage and registry exposure

Public or weakly protected buckets, blobs, artifact registries, and package feeds can leak code, secrets, templates, or allow poisoned artifacts.

### 5) logging blind spots

The chain moves faster when defenders only log management activity and miss the data or workload layer.

## The cheapest breakpoints for defenders

| Breakpoint                                                      | Why it matters                                                          |
| --------------------------------------------------------------- | ----------------------------------------------------------------------- |
| require short-lived workload identity instead of static secrets | removes the easiest theft-and-reuse pattern                             |
| harden metadata access and isolate workloads                    | stops app-level bugs from immediately becoming cloud identity incidents |
| minimize role grants to workloads and CI/CD                     | reduces lateral movement after the first credential                     |
| enable the right logs before the incident                       | makes scoping possible without guessing                                 |
| require promotion controls for images and manifests             | blocks poisoned delivery paths                                          |

## Provider-specific deep dives

* [🟧 AWS Cloud Attack Chains](/attack-paths-testing-detection-and-hardening/index-1/aws-cloud-attack-chains.md)
* [🟦 Azure Cloud Attack Chains](/attack-paths-testing-detection-and-hardening/index-1/azure-cloud-attack-chains.md)
* [🟨 GCP Cloud Attack Chains](/attack-paths-testing-detection-and-hardening/index-1/gcp-cloud-attack-chains.md)

## Cross-links

* [🟧 AWS Security Baseline and Top Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index/aws-security-baseline-and-top-misconfigurations.md)
* [🟦 Azure Security Baseline and Top Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index/azure-security-baseline-and-top-misconfigurations.md)
* [🟨 GCP Security Baseline and Top Misconfigurations](/cloud-kubernetes-and-infrastructure-security/index/gcp-security-baseline-and-top-misconfigurations.md)
* [☸️ Kubernetes Security Baseline](/cloud-kubernetes-and-infrastructure-security/index-1/kubernetes-security-baseline.md)
* [🧭 Runtime Investigation Playbook for Kubernetes and Containers](/cloud-kubernetes-and-infrastructure-security/index-1/runtime-investigation-playbook.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/attack-paths-testing-detection-and-hardening/index-1/cloud-attack-chains.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.