AWS VAPT: IAM Escalation Paths and Metadata SSRF

AWS Identity and Access Management (IAM) is the primary authorization surface for cloud environments and consistently one of the highest-risk areas surfaced by cloud VAPT. The complexity of the IAM policy language and the operational pressure to grant broad permissions to keep applications working combine to produce configurations that permit privilege escalation from low-value roles to full account administrative access. This document describes how a defensive VAPT programme assesses IAM configuration and validates metadata service exposure without disrupting production.

Assessing IAM Configuration Systematically

A defensive IAM assessment begins with enumeration of every principal in the account — users, roles, service accounts — and every policy attached to them. AWS provides read-only APIs sufficient for this enumeration, and the assessment can be conducted with an iam:Get* and iam:List* policy without requiring any write permissions. The output is a graph of principals and the permissions they possess directly or via role assumption chains.

The permissions graph is then analysed for known escalation paths. Specific IAM permissions, when combined, permit privilege escalation without any additional vulnerabilities. Permissions like iam:CreatePolicyVersion, iam:AttachUserPolicy, iam:PassRole combined with a service that accepts passed roles, and sts:AssumeRole against roles with permissive trust policies are all documented escalation vectors. Rhino Security Labs' research catalogues over twenty distinct escalation paths that can be checked systematically against any AWS account.

Trust policy analysis is frequently overlooked. Cross-account role assumptions rely on the trust policy of the assumed role, and overly permissive trust policies (using wildcards or trusting broad principals) permit unintended cross-account access. A defensive assessment enumerates every role trust policy in the account, resolves the trusted principals to specific accounts or services, and flags any trust relationship that does not match the organisation's documented cross-account architecture.

The Instance Metadata Service in Modern VAPT

The EC2 Instance Metadata Service (IMDS) exposes instance-scoped configuration data — including temporary credentials for the instance's IAM role — at the well-known address 169.254.169.254. Server-Side Request Forgery (SSRF) vulnerabilities that reach this address can retrieve credentials from applications running in the affected instance. The 2019 Capital One breach, which involved SSRF against IMDS to extract credentials that then accessed S3 buckets containing customer data, established this pattern as the canonical cloud VAPT concern.

AWS introduced IMDSv2 in 2019 as a mitigation. IMDSv2 requires a session token obtained via a PUT request before allowing metadata reads, which defeats the majority of SSRF-based exploitation because most SSRF vulnerabilities can only issue GET requests. IMDSv1 remains available by default on legacy instance launches; a defensive VAPT programme audits whether IMDSv2 is enforced on every instance and identifies any instance where IMDSv1 is still permitted.

IMDS enforcement can be verified via the instance metadata options API. The assessment checks whether HttpTokens is set to required (IMDSv2 enforced) versus optional (IMDSv1 still available). The hop limit setting (HttpPutResponseHopLimit) controls whether container workloads can reach IMDS; the recommended value of 1 prevents containers from reaching IMDS via the host, forcing them to use their own credential mechanism. These settings can be enforced organisation-wide via Service Control Policies.

STS AssumeRole and Cross-Account Risk

AWS Security Token Service (STS) issues temporary credentials via AssumeRole. In multi-account architectures, cross-account role assumption is the primary mechanism for legitimate access between accounts. Misconfigured trust policies can permit unintended parties — including any AWS account holder — to assume roles that grant substantial permissions in the target account. A defensive assessment resolves every trust policy to its concrete set of trusted principals and validates that each is authorised.

The external ID mechanism, when correctly implemented, prevents the "confused deputy" problem in cross-account access from third parties. Third-party services that require cross-account access to customer AWS accounts should use external IDs, and customers should verify that their trust policies enforce the external ID condition. Assessments frequently find trust policies that document an external ID requirement in comments but do not enforce it via a policy condition, which is functionally identical to having no external ID protection.

Session policies attached during AssumeRole can reduce the effective permissions of the resulting session below the role's attached permissions. This is a valuable defence-in-depth control for services that assume roles on behalf of users because it ensures the resulting credentials cannot exceed the specific action being authorised. A defensive assessment identifies whether services performing AssumeRole operations use session policies and whether the session policies effectively constrain the permissions granted.

Service Control Policies and Guardrail Enforcement

Service Control Policies (SCPs) at the AWS Organizations level provide a mechanism to enforce guardrails across all accounts in an organisation regardless of individual account IAM configurations. Effective SCPs deny high-risk actions organisation-wide — modifying CloudTrail configurations, disabling GuardDuty, disabling Config, modifying root account settings, and creating access keys for the root user. A defensive VAPT assessment reviews SCP coverage against a reference set of recommended guardrails.

Permissions boundaries at the individual role or user level provide a secondary enforcement mechanism. A permissions boundary sets the maximum permissions a principal can have regardless of the policies attached; useful for delegating IAM administration to team leads without allowing them to grant permissions that exceed their own. Effective use of permissions boundaries reduces the impact of IAM administrative delegation, which is otherwise one of the highest-risk configurations in AWS accounts.

CloudTrail, AWS Config, and GuardDuty coverage should be validated as part of the assessment. Detective controls that are misconfigured or disabled reduce the organisation's ability to respond to the very issues that VAPT identifies. Assessments should include verification that CloudTrail is enabled in every region, that log integrity validation is enabled, that logs are shipped to an SIEM or centralised bucket with restricted write permissions, and that GuardDuty is enabled and its findings are being triaged.

S3 Access Analysis and Public Exposure

S3 bucket configuration remains a frequent source of high-impact findings. The relevant assessment surface includes bucket policies, ACLs, block-public-access settings at both bucket and account levels, and the effective public accessibility of every object. AWS IAM Access Analyzer and Config rules provide substantial coverage of this surface programmatically; a defensive VAPT programme uses these tools' output as input to a broader assessment that also considers indirect exposure paths.

Cross-account access to S3 via bucket policies is a legitimate feature that becomes a risk when policies are overly permissive. Wildcarded principal fields, missing conditions on the source account, and outdated bucket policies that reference decommissioned partner accounts are common findings. The assessment enumerates every bucket policy that grants cross-account access, resolves the granted principals to specific accounts, and validates that each grant matches the organisation's documented data-sharing agreements.

Object-level access via presigned URLs is a distinct concern that bucket-level assessment misses. Applications that generate presigned URLs may configure excessive URL validity periods, may not enforce access control before generating URLs, or may generate URLs for sensitive objects. A defensive assessment reviews the application code that generates presigned URLs alongside the bucket configuration to identify presigned URL practices that undermine bucket-level controls.

Defensive Controls That Work in Production

The most effective defensive control for the IAM escalation surface is the systematic use of AWS Organizations with a landing zone architecture. Isolating workloads into dedicated accounts, restricting cross-account access via well-defined roles with narrow trust policies, and using SCPs to enforce guardrails at the organisation level provides structural constraints that individual account misconfigurations cannot bypass. Retrofitting this architecture into an existing account structure is a substantial project but consistently one of the highest-return security investments an AWS-based organisation can make.

For metadata service exposure, the effective control is organisation-wide enforcement of IMDSv2 via SCPs combined with hop limit enforcement for containerised workloads. Runtime detection of IMDSv1 usage via CloudTrail alerts allows identification of workloads that regressed to IMDSv1 despite the policy. AWS provides a metric and a Config rule for tracking IMDSv1 usage that VAPT reports should reference.

For ongoing assurance, continuous IAM analysis via Access Analyzer, integration of Config rules into deployment pipelines to block non-compliant infrastructure changes, and periodic re-assessment by VAPT provide layered coverage. The IAM configuration in a production AWS account changes continuously; a point-in-time assessment describes the account as it was on the assessment date but says nothing about the account's state a month later. Continuous VAPT integrated with the infrastructure-as-code pipeline provides the ongoing assurance that periodic assessments alone cannot.