How Server-Side Request Forgery Can Lead to Full Cloud Compromise – and What You Can Do About It

Introduction

Server-Side Request Forgery (SSRF) is a powerful exploit that enables attackers to trick a vulnerable server into making arbitrary HTTP requests on their behalf. While some view SSRF as merely a method to force the server into sending HTTP requests to 3rd party addresses, its true potential lies in accessing cloud metadata endpoints—a practice that can lead to the leakage of temporary credentials and, ultimately, a full cloud account takeover. In other words, SSRF, much like Remote Code Execution (RCE), SQL Injection, and password issues, represents one of the “holy grails” in security: once an attacker lands a successful exploit, the impact can be devastating. Not only can a single weakness compromise a customer’s application and infrastructure, but it can also trigger a domino effect by leaking access credentials that expose even more sensitive systems.

In this article, we’ll explore how SSRF can escalate from simple internal network reconnaissance to a complete takeover of cloud environments like AWS and Azure, among others. We’ll explain what metadata endpoints are—using AWS and Azure as prime examples—and discuss why they are both necessary for cloud operations and high-value targets for attackers. Whether you’re new to the concept or looking to deepen your understanding, this discussion will provide a comprehensive overview of SSRF and its far-reaching implications in today’s security landscape.

In this article, we’ll discuss:

1. A quick primer on SSRF and metadata endpoints.
2. Real-world consequences of successful SSRF attacks.
3. Privilege escalation in AWS (and similar principles for other cloud providers).
4. Best practices for mitigating these attacks.
5. Example code snippets for mapping AWS IAM account access.

Quick Intro To SSRF

Server-Side Request Forgery occurs when an application accepts user input (e.g., a URL) and fetches data from that URL on behalf of the user—without sufficient validation. This behavior lets attackers craft malicious requests to internal services that are normally inaccessible from the outside.

An SSRF goal is to access internal endpoints, such as the AWS or Azure instance metadata service. By querying these endpoints, attackers can obtain temporary access tokens or credentials used by the instance, often leading to further compromise within the cloud environment.

Further Reading:

• OWASP: Server-Side Request Forgery (SSRF)
• PayloadsAllTheThings (SSRF Section)
• PortSwigger’s Burp Academy – SSRF

Why Metadata Endpoints Exist

In modern cloud environments, instances (like AWS EC2, Azure VMs, or GCP VMs) frequently need to perform cloud operations, such as retrieving files from storage buckets or accessing secrets. Rather than embedding long-lived credentials in each instance, cloud providers offer “metadata endpoints” at a fixed address (commonly 169.254.169.254).

These endpoints allow an instance to retrieve temporary credentials and configurations. This approach reduces the risk of exposing static credentials but also creates a high-value target. If attackers can trick the server into making SSRF requests to these endpoints and return a response, they can steal these temporary credentials and impersonate the instance’s account.

Example Endpoints:

• AWS: http://169.254.169.254/latest/meta-data/
• Azure: http://169.254.169.254/metadata/instance?api-version=2021-02-01 (requires the header Metadata:true)

Note: Many other cloud providers also have similar metadata endpoints.

Real-World Dangers of SSRF

1. Cloud Account Compromise – A well-crafted SSRF that accesses the cloud metadata endpoint could expose temporary credentials. In some cases, these credentials may have overly broad permissions—sometimes full administrative privileges over the cloud account.
2. Accessing Internal Services – Beyond metadata, SSRF can expose internal APIs or administrative interfaces not intended for public consumption. This can lead to further attacks, such as reading sensitive configuration data and pivoting to internal networks.
3. Kubernetes Access – If the environment is containerized, SSRF could grant access to Kubernetes management endpoints. Attackers may then spin up malicious containers or gain control over the container orchestration layer—leading to a cascade of compromises.
4. Potential Domino Effect – Leaked credentials or tokens can compromise not only the immediate application but also downstream services. For instance, if you gain access to a build pipeline or a code repository, you could extract additional credentials from there.

Privilege Escalation in AWS

Let’s focus on AWS as an example. Once you obtain credentials via SSRF (e.g., from EC2 instance metadata), you should test what permissions you have—and see if you can escalate to a more privileged role or service. Even if the instance IAM role is “limited,” you might find creative ways to escalate.

Below are some AWS services to investigate after obtaining credentials:

1. AWS S3 – A common place to store configurations, backups, and logs. The logs might contain tokens, password reset links, or other sensitive artifacts.
2. AWS Lambda – Serverless functions may run with potentially high privileges. If you can update the Lambda code or environment variables, you may gain access to sensitive secrets or run code under elevated roles. Also, you may dump the Lambda’s source code and extract in-code secrets.
3. AWS DynamoDB – A fast and scalable NoSQL database. If permissions allow, you could read or write sensitive data directly using the AWS CLI—no direct connection string is required.
4. CodeBuild and ImageBuilder – Automated build tools that may contain environment variables, source code, or recipes for AMIs that hold sensitive info.
5. AWS Secrets Manager – Securely stores API keys, passwords, and other secrets. Access could expose further credentials, letting you pivot deeper into the environment.
6. AWS Systems Manager (SSM) – Stores and manages configuration parameters. Compromising these parameters might leak secrets or application settings.
7. EC2 Volumes (EBS) – If volumes are unencrypted or you can snapshot them, you might extract entire file systems, revealing more credentials or data.
8. Amazon ECS – Manages containerized applications. Access might reveal cluster configurations, container definitions, or secrets stored in ECS.
9. AWS KMS (Key Management Service) – Manages cryptographic keys. If your stolen credentials can decrypt or manage keys, you could decrypt volumes, access sensitive data, or even sign malicious code.

Tip: Always enumerate your target’s cloud resources thoroughly. A seemingly “low-permission” credential could still expose misconfigurations that lead to privilege escalation.

Code Examples

Code Example to Check Permissions and Loot Staff from the Account
This Bash script, designed to run on Kali Linux or Kali WSL, automatically installs the necessary prerequisites. It supports multiple accounts using data from a local .\credentials file. The script checks which permissions an IAM account has and dumps information from the cloud account. The output is stored in the local folder, timestamped for your convenience. This script has been tested on multiple accounts.

Github Gist

IMDSv2 Access Example
Below is an example Bash script that retrieves AWS instance metadata using IMDSv2. It illustrates how to interact with the IMDSv2 endpoint:

#!/bin/bash
# Step 1: Retrieve IMDSv2 Token
TOKEN=$(curl -s -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
       http://169.254.169.254/latest/api/token)
# Step 2: Validate Token Retrieval
if [ -z "$TOKEN" ]; then
    echo "Error: Unable to retrieve IMDSv2 token. Exiting."
    exit 1
fi
# Step 3: Recursive Function to Fetch Metadata
fetch_metadata() {
    local path=$1
    local metadata=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
                     "http://169.254.169.254/latest/meta-data/${path}")
    
    # Process each line of the metadata
    for item in $metadata; do
        if [[ $item == */ ]]; then
            # If the item ends with '/', it's a subpath. Call the function recursively.
            fetch_metadata "${path}${item}"
        else
            # Otherwise, fetch and print the value.
            value=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
                         "http://169.254.169.254/latest/meta-data/${path}${item}")
            echo "${path}${item}: $value"
        fi
    done
}
# Step 4: Start Recursive Fetching
echo "Recursively fetching all metadata from IMDSv2..."
fetch_metadata ""

How to Protect Your Cloud Accounts

• Enforce Secure Metadata Access
  • AWS IMDSv2: AWS has introduced IMDSv2, which requires session-based authentication tokens to access metadata. This makes SSRF exploitation more difficult.
    • AWS Reference
  • Minimal IAM Permissions: Assign only the permissions that instances truly need. This principle of least privilege reduces the blast radius of compromised credentials.
• Harden Code Against SSRF
  • Filter and Validate User Inputs: Don’t allow arbitrary URLs to be fetched from user input. If you must, create an allowlist of safe domains.
  • Disable Internal Address Access: Block requests to 169.254.x.x and other internal IP ranges at the application layer. If possible, avoid returning the raw content of backend requests to the user.
• Monitor and Log Abnormal Requests
  • Configure network firewalls or logging tools to detect unusual connections to metadata endpoints or suspicious internal resources.
  • Use AWS CloudTrail, Azure Monitor, or similar services to track IAM role usage and API calls.
• Patch and Update
  • Stay current with security patches for your frameworks and libraries to minimize vulnerabilities that might lead to SSRF

Conclusion

SSRF is more than just a neat trick to force the server into connecting to arbitrary client-provided URLs — it’s a full-fledged risk that can cascade into a complete cloud takeover when metadata endpoints and misconfigurations collide. By understanding how SSRF works, limiting instance permissions, and enforcing best practices, you can significantly reduce the chances of a devastating compromise.

Key Takeaways

• SSRF can be surprisingly dangerous, especially in cloud environments.
• Always harden metadata endpoints with features like AWS IMDSv2.
• Apply the principle of least privilege for every cloud resource.
• Monitor logs and respond promptly to suspicious activity.