PS Product SecurityKnowledge Base

🟧 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 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

# 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.