# AWS Cloud Attack Chains

> **Intro:** In AWS, the decisive question is usually not “was there code execution?” but **“what identity did the workload end up with?”** Temporary credentials, IAM trust relationships, CI federation, and deployment APIs shape the real blast radius.
>
> **What this page includes**
>
> * high-probability AWS attack chains
> * where each chain usually starts
> * how the chain expands through IAM, storage, and orchestration
> * what to hunt first in CloudTrail, EKS, and workload logs

![AWS Cloud Attack Chain](/files/wyNj46HaJ95qCXB8Nd4V) *Figure: Common AWS sequence from workload foothold to IAM expansion and deployment control.*

## AWS chain logic in one sentence

The attacker wants to turn **application access** into **AWS credentials**, then turn those credentials into **broader trust**, then use that trust to reach **data, deployment, or persistence**.

## Chain 1 — SSRF or code execution to IMDS to broader IAM access

### Typical flow

1. the attacker gets SSRF or limited code execution in EC2-hosted software;
2. the process reaches the instance metadata service;
3. the attacker obtains temporary credentials from the instance profile;
4. they call discovery APIs to enumerate IAM, S3, Secrets Manager, ECR, EKS, and STS paths;
5. if the role can assume other roles or pass roles to services, the blast radius grows quickly.

### Why this chain exists

The instance metadata service exists for legitimate automation. The problem appears when:

* the workload can reach IMDS freely;
* the instance profile is broader than the application really needs;
* IMDSv1 is still allowed in legacy environments;
* containers inherit instance-level power they should not have.

### High-value evidence

* CloudTrail events for `GetCallerIdentity`, `AssumeRole`, IAM reads, and storage enumeration;
* sudden access from a workload role to services the application does not normally use;
* unusual reads from Secrets Manager or Parameter Store;
* suspicious calls shortly after application errors or WAF events.

### Fast containment moves

* restrict or disable metadata access where possible;
* reduce the role scope attached to the affected compute;
* rotate any secrets the role could read;
* review trust policies on every role the compromised identity could assume.

## Chain 2 — ECS or EKS workload identity abuse to secret and data access

### Typical flow

1. the attacker compromises a containerized application;
2. they recover task or pod credentials;
3. they enumerate access to S3, SSM Parameter Store, Secrets Manager, DynamoDB, ECR, and EKS APIs;
4. they pull secrets or data, or use deployment-plane rights to move further.

### What makes this chain dangerous

Workload identities are the correct design pattern, but **only** when the attached permissions are narrow. If a single service account or task role can read secrets, list infrastructure, and update deployment assets, the attacker inherits all of that.

### Special AWS nuance

On ECS with EC2 launch type, containers are not a hard security boundary. Poor isolation can expose other task credentials or the underlying instance profile if the host is not hardened correctly.

### Hunt pivots

* CloudTrail by `userIdentity.sessionContext.sessionIssuer.arn`;
* EKS control plane audit activity involving secrets, configmaps, role bindings, or pod exec behavior;
* ECR pulls or pushes from unusual principals;
* S3 object reads from workloads that usually do not touch those paths.

## Chain 3 — leaked CI/CD OIDC or access token to deployment takeover

### Typical flow

1. the attacker steals a GitLab/GitHub/OIDC-capable pipeline token or abuses an over-trusting role condition;
2. they exchange that identity for an AWS role via federation;
3. they push an image, change a manifest, alter an environment variable, or modify a release path;
4. the next deployment makes the compromise persistent.

### What defenders miss

Teams often secure the runtime better than the **delivery trust path**. If the OIDC trust policy is broad, the attacker may not need long-lived AWS keys at all.

### What to verify immediately

* the `sub`, `aud`, and branch or environment conditions on the trust policy;
* whether the federated role can push to ECR, update EKS, modify ECS services, or read secrets;
* whether image signing or manifest approval would have stopped the malicious promotion.

## Chain 4 — public or weakly controlled storage to internal expansion

### Typical flow

1. the attacker finds a public S3 bucket, over-shared artifact, or backup object;
2. they recover source code, deployment manifests, `.env` material, certificates, or architecture data;
3. they pivot into the live environment using recovered endpoints, roles, or assumptions;
4. they combine that intelligence with another foothold to accelerate compromise.

### Why it matters

Storage exposure often looks like a “data only” issue, but in Product Security it is frequently an **attack chain enabler** because it leaks infrastructure assumptions and operational secrets.

## Chain 5 — EKS administration path to cluster and cloud persistence

### Typical flow

1. the attacker gets AWS credentials that can reach the cluster administration layer;
2. they use EKS access plus Kubernetes permissions to read secrets, exec into pods, or create privileged workloads;
3. from the cluster they target other workload identities, nodes, or registries;
4. they leave persistence in IAM, ECR, or cluster objects.

### Fast scoping checklist

* who called `eks:DescribeCluster`, `UpdateClusterConfig`, or access-related APIs?
* were new Kubernetes bindings, privileged pods, or daemonsets created?
* did any workload identities read new secrets or call new AWS services afterward?

## AWS hunting priorities

### Control plane first

Start with **CloudTrail** and answer four questions:

1. which principal was first used?
2. what did it enumerate?
3. did it assume another role?
4. did it touch data, secrets, deployment, or IAM afterward?

### Then the runtime plane

Correlate with:

* application logs around the first suspicious API calls;
* EKS audit/control-plane logs for Kubernetes-side privilege expansion;
* ECR push history and deployment timestamps;
* EC2, ECS, or EKS node evidence if container escape is suspected.

## AWS CLI pivots

```bash
# identity confirmation
aws sts get-caller-identity

# recent CloudTrail lookup for a suspect role or user
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=<principal-name>

# inspect a role trust policy
aws iam get-role --role-name <role-name>

# list policies attached to a role
aws iam list-attached-role-policies --role-name <role-name>

# inspect EKS cluster logging posture
aws eks describe-cluster --name <cluster-name> \
  --query 'cluster.logging'
```

## Defensive defaults that break AWS chains early

* require **IMDSv2** and reduce metadata reachability where possible;
* prefer workload-specific roles over shared broad instance profiles;
* keep CI federation trust policies narrow and branch or environment aware;
* enable EKS control-plane logs and meaningful CloudTrail coverage;
* separate build, deploy, and runtime identities;
* require promotion controls for images and manifests.

## Cross-links

* [AWS IAM and Role Design](/cloud-kubernetes-and-infrastructure-security/index/aws-iam-and-role-design.md)
* [🌐 AWS Networking and Policy Baseline](https://github.com/D3One/Product-Security-Gitbook/blob/main/08-infrastructure-and-cloud-security/aws-networking-and-policy-baseline.md)
* [GitLab Security Baseline](https://github.com/D3One/Product-Security-Gitbook/blob/main/07-ci-cd-and-software-supply-chain/gitlab-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/aws-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.