SSRF in Cloud Environments: Practical Techniques to Find and Exploit It

Server-Side Request Forgery (SSRF) has evolved from a simple vulnerability into a cloud killer. In traditional data centers, SSRF might allow you to scan an internal network. In the cloud (AWS, Azure, GCP), it can allow you to steal temporary credentials, take over accounts, and compromise the entire infrastructure.

Why SSRF Is More Dangerous in the Cloud

Cloud environments rely heavily on “Instance Metadata Services” (IMDS). These internal REST APIs (available at 169.254.169.254) provide configuration data and, critically, temporary IAM credentials to the compute instance. If an attacker can force the server to request this IP, they can steal these keys.

Step 1: Identify SSRF Entry Points

Look for any feature that triggers the server to fetch a URL:

• Webhooks: “Enter a URL to receive notifications.”
• File Uploads via URL: “Paste an image URL.”
• PDF Generators: “Convert this webpage to PDF.”
• Link Previews: Unfurling metadata from a shared link.

WEBWant to practise this hands-on? Certified VAPT Web Exploitation covers it with live labs and mentor support.

Step 2: Test with Burp Collaborator / Interactor

Before attacking internal systems, confirm the server can make outbound requests. Inject a Burp Collaborator payload (e.g., http://[your-collaborator-id].oastify.com). If you see a DNS or HTTP interaction in your collaborator client, you have confirmed SSRF.

Step 3: Bypassing Filters

Developers often blacklist “localhost” or “127.0.0.1”. Bypass these filters using:

• Alternative IP Encodings: 2130706433 (Decimal), 0177.0.0.1 (Octal), 0x7f.0.0.1 (Hex).
• DNS Rebinding: Configure a domain you own to resolve to an internal IP (like 169.254.169.254) after the initial check.
• IPv6 Encodings: [::1] or [0:0:0:0:0:ffff:127.0.0.1].
• Redirections: Host a script on your server that redirects (302) to the target internal IP.

Step 4: Targeting Cloud Metadata Services

The primary target in cloud environments. Try these endpoints:

• AWS (IMDSv1): http://169.254.169.254/latest/meta-data/iam/security-credentials/
• Google Cloud (requires header): http://metadata.google.internal/computeMetadata/v1/ (Harder to exploit due to “Metadata-Flavor: Google” header requirement, unless you have Header Injection too).
• Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01 (Requires “Metadata: true” header).
• DigitalOcean: http://169.254.169.254/metadata/v1/

Step 5: Blind SSRF vs Full SSRF

Full SSRF: The response from the internal service is returned to you. This is the “Holy Grail” allowing direct data theft.

Blind SSRF: The request is made, but you don’t see the response. You can still use this for internal port scanning (based on response time) or exploiting blind vulnerabilities in internal apps (like Log4Shell).

Step 6: Internal Port Scanning

Use Burp Intruder to scan internal ports on the server itself (localhost) or the internal network (192.168.x.x, 10.x.x.x). Look for differences in response time or error messages to identify open ports (e.g., 22 SSH, 6379 Redis, 8080 Jenkins).

Step 7: Reading Local Files

If the application supports other URI schemes, try the file:// protocol:

• file:///etc/passwd (Linux users)
• file:///c:/windows/win.ini (Windows)
• file:///proc/self/environ (Environment variables, often containing keys)

Step 8: Cloud-Specific Wrappers

Some languages/frameworks support dangerous wrappers:

• PHP: expect://id (RCE via Expect extension), gopher:// (Construct arbitrary TCP packets).
• Java: jar:, netdoc: protocols.

Step 9: Validate Impact

If you retrieve AWS keys (AccessKeyId, SecretAccessKey, Token), DO NOT use them to scan the client’s infrastructure. Verify they are valid using aws sts get-caller-identity locally, then report immediately. Using them to access S3 buckets or spin up instances crosses the line into unauthorized access.

Step 10: Tools for Automation

• SSRFmap: Automates discovery and exploitation of SSRF.
• Gopherus: Generates Gopher payloads to exploit internal services like Redis, MySQL, or SMTP.
• Collaborator/Interactsh: Essential for detecting blind SSRF.

Step 11: How to Defend Against SSRF in Cloud Environments

• Enforce IMDSv2 (AWS): This requires a session token via a PUT request, effectively killing most SSRF attacks that can only perform GET requests.
• Network Segmentation: Ensure web servers cannot talk to internal admin panels or sensitive databases directly.
• Input Validation: Use a strict whitelist of allowed domains, protocols (http/https only), and ports.
• Disable Unused URL Schemes: Block file://, gopher://, ftp:// at the application library level.

Common SSRF Testing Mistakes

• Giving up after one failed payload (WAFs are common).
• Not testing for Blind SSRF (it’s less obvious but still critical).
• Confusing SSRF with simple external resource loading (e.g., <img src="..."> is XSS/CSRF territory, not backend SSRF).

Final Thoughts

SSRF in the cloud is a gateway to total compromise. As a hunter, mastering the nuances of cloud metadata services and bypass techniques will significantly increase the severity and payout of your findings.