SSRF → IMDS → AssumeRole chain → Org admin

§ Context

Assumed environment: target is a multi-account AWS organisation. The compromised EC2 role has broad sts:AssumeRole and the trust policies on more privileged roles include wildcards or rely solely on external-id checks.

§ Steps

1. 01
   Web SSRFLateral Movement

   W-SSRF— Server-Side Request Forgery (SSRF)
2. 02
   Steal EC2 role credentialsCredential Access

   C-IMDS-V1— IMDSv1 Credential Theft
3. 03
   Enumerate IAM (Pacu / enumerate-iam)Discovery

   T1087— Account Discovery
4. 04
   AssumeRole into member accountLateral Movement

   C-AWS-ASSUMEROLE-CHAIN— AWS sts:AssumeRole Chain
5. 05
   iam:PassRole on a higher-priv rolePrivilege Escalation

   C-AWS-IAM-PASSROLE— AWS iam:PassRole Chain
6. 06
   Drop privileged LambdaExecution

   C-AWS-LAMBDA-EXEC— AWS Lambda Code Update → RCE
7. 07
   AssumeRole into the management accountLateral Movement

   C-AWS-ASSUMEROLE-CHAIN— AWS sts:AssumeRole Chain
8. 08
   Attach AdministratorAccess to selfPrivilege Escalation

   C-AWS-IAM-ADDUSER-POLICY— AWS iam:AttachUserPolicy → AdminAccess
9. 09
   Backdoor IAM user for re-entryPersistence

   C-AWS-IAM-BACKDOOR— AWS IAM Backdoor User / Access Key

§ References

• T1087Account Discovery

§ Frequently asked

What is the "SSRF → IMDS → AssumeRole chain → Org admin" attack path?

A web SSRF leaks the EC2 instance role; iam:PassRole + sts:AssumeRole hops across two member accounts land you with AdministratorAccess in the organisation's management account. It chains 9 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Web SSRF (W-SSRF) — a lateral movement primitive. Assumed environment: target is a multi-account AWS organisation.

What is the final impact of this kill-chain?

The final step lands on Backdoor IAM user for re-entry (C-AWS-IAM-BACKDOOR), which falls under Persistence. From here, an operator typically pivots into post-exploitation or maintains persistence.

How can defenders detect or prevent this attack?

Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers

• Shared techniques2

  WAF SSRF → IMDS → S3 mass exfil (Capital One 2019)

  A misconfigured ModSecurity rule on a customer-facing app allowed SSRF; SSRF hit EC2 IMDSv1 for the instance role; the role had ListBucket + GetObject on a major customer-data bucket.

• Shared techniques2

  pull_request_target injection → secrets → cloud takeover

  A GitHub Actions workflow runs on pull_request_target and checks out the PR's head SHA. The attacker's PR injects code that runs with the base repo's secrets, including a cloud deploy role.

• Shared techniques2

  Secret echoed to public build log → cloud takeover

  A workflow accidentally runs `env` or `set -x` during debugging — the AWS access key is now in public CI logs and indexed by Google Cache / GitHub search.

• Shared techniques2

  GitHub OIDC trust over-broad → AWS admin

  An IAM role trusts GitHub Actions OIDC with a wildcard 'repo:*' subject. Any attacker GitHub repo can assume the role and run with its privileges.

• Shared techniques2

  Public bucket → CI/CD secret leak → cloud takeover

  A public S3 bucket hosts a build artefact containing CI tokens / .env files. Use them to push to the prod CI/CD pipeline and gain a deploy role.

• Shared techniques2

  SSRF → IMDS → cloud creds → lateral

  An image-fetcher / link-preview endpoint fetches attacker-controlled URLs server-side. Pivot to the cloud metadata service and steal the instance role credentials.