SSRF to Cloud Compromise: Attack Chains Explained

📅 September 20, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A single misconfigured web application endpoint handed attackers the keys to a Fortune 500 company’s entire AWS infrastructure in 2024. The attack chain required no zero-days, no sophisticated malware, and no physical access — just an unvalidated HTTP request parameter and a cloud metadata service running on its default settings. Server-Side Request Forgery, or SSRF, has quietly evolved from a nuisance-class web vulnerability into the opening move of some of the most damaging cloud compromise campaigns documented in the last two years. Understanding how these attack chains are constructed — and where they can be broken — is now a non-negotiable competency for any security team operating workloads in AWS, Azure, or GCP.

What SSRF Actually Is — And Why Cloud Environments Amplify Its Danger

SSRF occurs when an application fetches a remote resource based on user-supplied input without adequately validating or sanitizing that input. An attacker tricks the server into making requests on their behalf — often to internal network addresses that would otherwise be unreachable from the public internet. In isolation, this might expose internal service banners or internal API responses. Inside a cloud environment, the blast radius is categorically different.

The Cloud Metadata Service: An Attacker’s First Destination

Every major cloud provider maintains an Instance Metadata Service (IMDS) accessible from within the virtual machine at a well-known, non-routable address. For AWS, that address is 169.254.169.254. For Azure, it’s the same IP but accessed via a different path structure. For GCP, it’s metadata.google.internal. These services exist to provide running instances with configuration data, instance identity documents, and — critically — temporary IAM credentials tied to the instance’s attached role.

When an SSRF vulnerability exists in an application running on an EC2 instance with an attached IAM role, the attacker’s request chain looks like this: exploit the SSRF to query http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name}, extract the AccessKeyId, SecretAccessKey, and Token fields from the JSON response, then use those credentials — from an entirely external IP — to authenticate against AWS APIs. The Capital One breach of 2019, which exposed over 100 million records, followed precisely this pattern. A WAF misconfiguration created an SSRF vector; the attacker pivoted directly to the metadata service and exfiltrated credentials that allowed broad S3 bucket access.

Anatomy of a Modern SSRF-to-Cloud-Compromise Chain

Modern attack chains are rarely single-step operations. Threat actors who exploit SSRF for cloud credential theft typically follow a structured kill chain that maximizes persistence while minimizing detection surface. According to Wiz’s 2025 Cloud Threat Landscape Report, 34% of critical cloud environment compromises analyzed began with a web-layer vulnerability — with SSRF representing the plurality of initial access vectors in that category.

Phase 1: Discovery and SSRF Validation

Attackers begin with reconnaissance — identifying web applications that accept URLs or IP addresses as parameters. Common targets include PDF generation services, image thumbnail generators, webhook configuration endpoints, URL preview features, and XML parsers that process external entity references (a related XXE vector). Tools like Burp Suite’s Collaborator, interactsh, and custom DNS callback infrastructure help attackers confirm blind SSRF conditions where responses aren’t directly returned to the user.

Once a viable SSRF vector is confirmed, the attacker probes internal IP ranges. In cloud environments, the first probe is almost always the metadata service. A successful response to the IMDSv1 endpoint (which requires no authentication headers) immediately signals an exploitable path to credential material. IMDSv2, which requires a session-oriented token obtained via a PUT request, was specifically designed to mitigate this — but adoption remains inconsistent across enterprise cloud estates.

Phase 2: Credential Harvesting and Privilege Enumeration

With temporary credentials in hand, attackers move laterally into the control plane. The first action is almost universally an IAM enumeration call — typically sts:GetCallerIdentity, which requires no special permissions and reveals the account ID, user/role ARN, and identity context. From there, attackers use tools like Pacu (AWS exploitation framework), ScoutSuite, or custom Python scripts leveraging Boto3 to enumerate what the compromised role can access.

High-value findings at this stage include overly permissive IAM policies (particularly wildcard * actions on * resources), attached policies granting access to Secrets Manager or Parameter Store, permissions to assume other roles via sts:AssumeRole, and write access to Lambda functions or ECS task definitions that could allow code injection into running workloads.

Escalation Paths: From SSRF to Full Account Takeover

The distance between a stolen EC2 instance role credential and full AWS account takeover is often shorter than security teams expect. Several well-documented privilege escalation paths exist that require only moderate initial permissions. The research by Bishop Fox and the Rhino Security Labs AWS Privilege Escalation repository catalogues over 25 distinct escalation techniques — many of which can be chained together within a single compromised session.

Lambda, IAM PassRole, and the Persistence Problem

One particularly dangerous escalation path involves the iam:PassRole permission combined with access to Lambda or EC2. If the compromised role can pass a more privileged IAM role to a Lambda function, the attacker creates a new function, assigns that privileged role, and invokes it to perform actions at a higher permission level — effectively bootstrapping their way to administrative access without ever touching the IAM console directly.

Persistence is established through multiple mechanisms: creating new IAM users with programmatic access keys, adding backdoor OIDC identity providers that allow external identity federation, modifying existing Lambda functions to exfiltrate data continuously, or inserting malicious startup scripts into EC2 user data that survive instance reboots. A 2025 Mandiant incident response case study documented an attacker maintaining persistence in a compromised AWS environment for 47 days before detection — despite multiple automated security alerts that had been misconfigured to suppress low-severity findings.

Detection Engineering for SSRF-Initiated Cloud Attacks

Detection of these attack chains requires instrumentation at multiple layers. Single-layer visibility — WAF logs only, or CloudTrail only — creates blind spots that sophisticated actors deliberately exploit. Effective detection engineering for SSRF-to-cloud-compromise chains requires correlating web application logs, VPC flow logs, DNS query logs, and cloud control plane audit logs within a unified SIEM or security data lake.

Behavioral Indicators and Anomaly Signatures

Several behavioral patterns consistently appear in post-incident forensics of SSRF-driven cloud compromises:

• IMDSv1 requests from application processes: Most legitimate applications don’t query the metadata service directly. An application server making HTTP GET requests to 169.254.169.254 should trigger an immediate alert. VPC flow logs will capture this traffic if logging is enabled at the interface level.
• Credential use from unexpected geographic locations: Temporary credentials issued to an EC2 instance in us-east-1 being used from a residential IP in Eastern Europe is a high-fidelity indicator. AWS CloudTrail captures source IP for every API call — this data point is underutilized by most security teams.
• sts:GetCallerIdentity calls with no prior authentication context: This is often the attacker’s first control plane action. In a well-instrumented environment, a CloudTrail event showing this API call from an external IP using instance credentials should trigger an automated response.
• Rapid IAM enumeration calls: Sequential calls to iam:ListRoles, iam:ListPolicies, iam:GetPolicy, and iam:SimulatePrincipalPolicy within a short time window are characteristic of automated enumeration tooling.
• Unusual DNS lookups from application servers: Blind SSRF validation often involves DNS callbacks to attacker-controlled infrastructure. DNS query logs from Route 53 Resolver or a VPC-level DNS logging solution can surface this activity.

MITRE ATT&CK for Cloud (the IaaS matrix) maps these behaviors clearly. SSRF-based metadata service access falls under T1552.005 (Unsecured Credentials: Cloud Instance Metadata API). Building detection rules directly against ATT&CK technique IDs ensures coverage gaps are systematically identified through purple team exercises.

Defensive Architecture: Breaking the SSRF-to-Compromise Chain

Defense against SSRF-to-cloud-compromise chains is a layered problem requiring controls at the application layer, the network layer, and the cloud configuration layer simultaneously. Relying on any single control creates a brittle defense that a determined attacker can bypass.

IMDSv2 Enforcement and Network-Level Controls

The single highest-impact control for AWS environments is enforcing IMDSv2 (Instance Metadata Service version 2) across all EC2 instances. IMDSv2 requires a PUT request with a TTL-bound token before any metadata can be retrieved — a requirement that breaks the standard SSRF exploitation pattern, since most SSRF vulnerabilities involve GET-only request capabilities. AWS now allows account-level enforcement of IMDSv2 through an account setting, but as of mid-2026, Wiz research indicates that over 40% of enterprise AWS accounts still have instances running with IMDSv2 optional rather than required.

Network-level controls provide a complementary layer. Egress filtering on application server security groups should block outbound connections to 169.254.0.0/16 (link-local range) explicitly. Web Application Firewalls should be configured with rules that detect and block requests containing 169.254.169.254, internal RFC 1918 address ranges, and known cloud metadata hostnames in URL parameters. Both AWS WAF managed rule groups and Cloudflare WAF include SSRF-specific rules — these should be enabled and validated against your specific application logic.

IAM Hygiene and Least-Privilege Enforcement

Even a successful SSRF exploitation of the metadata service becomes significantly less dangerous if the compromised IAM role follows least-privilege principles. Role policies should grant only the specific actions on specific resources required for the application’s function — not wildcards, not account-wide resource access, not iam:PassRole unless explicitly required. Tools like AWS IAM Access Analyzer, Cloudsplaining, and PMapper can identify overly permissive policies and privilege escalation paths in your existing IAM configuration before attackers do.

Service Control Policies (SCPs) at the AWS Organizations level provide a guardrail layer that cannot be overridden even by a compromised role with administrative permissions. SCPs should deny actions like iam:CreateUser, iam:CreateAccessKey, and organizations:LeaveOrganization from all principals except designated break-glass accounts. This limits the persistence mechanisms available to an attacker operating with stolen instance credentials.

Organizational Posture: Integrating SSRF Risk Into AppSec and Cloud Security Programs

SSRF vulnerabilities are discovered routinely in penetration tests and bug bounty programs, yet remediation timelines remain stubbornly long. A 2026 Veracode State of Software Security report found that server-side request forgery vulnerabilities have a median remediation time of 198 days in enterprise environments — nearly twice the remediation time for SQL injection or XSS vulnerabilities of equivalent severity. This gap reflects a structural disconnect between application security teams who identify the vulnerability and cloud security teams who understand the downstream impact.

Cross-Functional Threat Modeling and Developer Education

Closing this gap requires integrating cloud-specific threat scenarios into application security threat modeling exercises. When developers are evaluating a new URL-fetching feature, the threat model should explicitly include: “What happens if this endpoint is exploited to reach the IMDS? What IAM permissions does the hosting instance carry? What is the blast radius?” This analysis changes the risk conversation from “SSRF is a medium-severity finding” to “this SSRF could expose credentials with read access to every S3 bucket in the account.”

Developer education programs should include hands-on labs demonstrating the full SSRF-to-credential-theft chain in a safe environment. When engineers see firsthand that a single unvalidated URL parameter can translate into an attacker running arbitrary AWS CLI commands against their infrastructure, the urgency of input validation and output encoding controls becomes immediately tangible — far more so than abstract policy requirements.

Key Takeaways

• SSRF is a cloud-critical vulnerability class: In cloud environments, SSRF vulnerabilities that would be medium-severity in traditional infrastructure can directly enable full account compromise through metadata service credential theft. Risk ratings must reflect this amplified impact.
• IMDSv2 enforcement is mandatory, not optional: Enforce IMDSv2 at the account level across all AWS environments. Validate enforcement regularly — instance launches via older AMIs or launch templates can silently revert to IMDSv1.
• IAM least privilege limits blast radius: Even a successful SSRF attack against a properly scoped IAM role yields minimal attacker capability. Treat IAM hygiene as a compensating control for application vulnerabilities you haven’t found yet.
• Detection requires multi-layer log correlation: Correlate web application logs, VPC flow logs, DNS query logs, and CloudTrail events. Single-source detection misses the cross-layer nature of these attack chains.
• Remediation velocity matters: The 198-day median remediation time for SSRF creates an extended exposure window. Implement compensating controls — egress filtering, WAF rules, IMDSv2 enforcement — immediately upon SSRF discovery while code-level remediation proceeds.

Conclusion

SSRF-to-cloud-compromise attack chains represent one of the clearest examples of how web application vulnerabilities and cloud security posture are inseparable concerns. The Capital One breach demonstrated this at massive scale in 2019; subsequent incidents confirm the pattern hasn’t changed — only the attacker tooling has matured. Security teams that treat SSRF as an application team problem and cloud IAM as a cloud team problem create exactly the organizational blind spot these attack chains exploit.

The actionable path forward starts this week. Run ScoutSuite or Prowler against your AWS accounts and identify every EC2 instance still running with IMDSv2 optional. Use PMapper to graph the privilege escalation paths available from your highest-risk application instance roles. Review your SIEM detection rules against the MITRE ATT&CK IaaS matrix — specifically T1552.005, T1078.004, and T1098.001 — and identify uncovered techniques. Schedule a purple team exercise that simulates the complete SSRF-to-cloud-compromise kill chain against a production-representative environment. The attack is well-documented. The defenses are available. The gap between them is organizational will and execution velocity.