Blind SSRF → finding with Beacon

~8 min · Beacon · BYO Free / hosted Hunter Pro

The short version. Blind SSRF leaves no trace in the response, so you prove it out-of-band. Enable Beacon (Crusader's OOB engine, built on Interactsh), generate a payload tagged with a purpose, plant it in a suspected sink, and send. When the target's backend resolves or fetches your host, the callback lands in Crusader. Read the proof Chain — you sent → server accepted → beacon called — confirm it's a real HTTP request, and press P to promote it to an evidenced finding. This is a manual, operator-driven workflow: Crusader's scanner surfaces SSRF candidates but never auto-verifies them.

01What "blind" means, and why Beacon

Server-side request forgery is blind when the application makes the request you induced but never reflects the response back to you. You change a url or webhook parameter, the server fetches it, and you see nothing — a 200, a generic error, the same page. The only way to know the request happened is to make it call infrastructure you control. That's out-of-band application security testing (OAST), and in Crusader it's the Beacon tool.

Beacon plants a unique hostname in your payload. When the target's backend resolves that name (DNS) or actually fetches it (HTTP/HTTPS/SMTP), the interaction server records the hit and Crusader pulls it into your local workspace — with the source IP, timing, and a reproducible chain of evidence.

The scanner never proves this for you. Crusader's SSRF module is strictly passive — it ranks URL-shaped inputs as candidates but never generates Beacon hosts, replays requests, or verifies a callback. Proving blind SSRF is a deliberate, human-driven act. Only run it against systems you are authorized to test.

02Step 1 — Enable Beacon

Open Beacon from the sidebar, then Beacon settings. The overlay is titled Beacon setup. Pick a provider — this is the one tier decision in the whole flow:

Provider	Tier	When to use it
Crusader.sh	Hunter Pro	Hosted, zero-setup. Callback hosts use an opaque subdomain on shared infrastructure. Best for day-to-day work.
Custom server	Free	Bring your own Interactsh server. Callbacks land only on infrastructure you control, and it doesn't touch the hosted quota.

Set the ROOT DOMAIN, INTERACTSH SERVER, and OOB scheme, then click Save and enable. The Beacon domain pill at the top of the screen turns active. If you're going BYO, the full self-host walkthrough — DNS delegation, interactsh-server, token, and the exact fields to paste — is in Run your own private OAST server.

Beacon config and callback history are stored per-project. Each engagement keeps its own OAST settings and its own hits, so switching projects never crosses streams.

03Step 2 — Generate a payload with a purpose

On the Beacon screen, find the READY ADDRESS card. Before you copy anything, set a PAYLOAD PURPOSE — free text, e.g. ssrf (or something more specific like ssrf-avatar-url). The purpose is stored in the payload metadata so that when a hit lands days later, you know exactly which input you were probing. Then copy the payload in the scheme you need with the DNS, HTTP, or SMTP button.

Prefer the CLI when you're scripting a probe set:

# generate an HTTP payload tagged for SSRF
crusader beacon payload --kind http --purpose ssrf

# DNS-only (use when the sink may resolve but not fetch)
crusader beacon payload --kind dns --purpose ssrf

The empty-state hint on the card spells out the intended targets: "Copy a payload into a suspected SSRF, XXE, link preview, email, or stored XSS sink. Real callbacks will appear here." On the hosted provider the host is an opaque subdomain; the PAYLOAD PURPOSE lives in metadata, not in the hostname.

HTTP vs DNS. An HTTP payload proves the target made an actual request. A DNS payload only proves something resolved the name. For SSRF you want an HTTP callback — reach for DNS only when the sink is firewalled from outbound HTTP but its resolver still leaks. The promotion rules in section 08 follow exactly this distinction.

04Step 3 — Plant it in a suspected sink

Drop the payload host into any input where the server might dereference a URL on your behalf. Common sinks:

URL / fetch parameters — ?url=, ?next=, ?image=, ?target=, anything that takes an address.
Webhooks and callbacks — webhook registration, OAuth redirect_uri back-channels, payment/notification callback URLs.
Link-preview / unfurlers — paste the payload where the app generates a preview card (chat, comments, profile links).
Import-by-URL and document fetchers — "import from URL", avatar-by-URL, PDF/HTML renderers, XML SYSTEM entities (blind XXE).
Headers — Referer, X-Forwarded-For, and a Host header (routing-based SSRF — but read the caveat in section 08 first).

Send it the way you normally drive a request: edit and forward in Repeater, fan it across an injection set in Intruder, or trigger it through the browser. If a candidate came from the passive scanner, open that exchange in Repeater, swap your Beacon host into the suspect parameter, and send.

05Step 4 — Catch the callback

Watch the Beacon feed. When the target reaches your host, the row appears and a NEW HIT toast fires. A background poller pulls new interactions every 2 seconds; if you're impatient, hit Poll now to force an immediate fetch. The hits table columns are:

Column	What it tells you
#	Hit sequence number.
PROTO	DNS, HTTP, HTTPS, or SMTP — your first read on whether a real request was made.
PAYLOAD	The callback host that fired (matches the purpose you set).
SOURCE IP	The IP that contacted your server — often the target's egress or internal resolver.
TRIGGERED BY	The associated request, when Crusader can correlate it.
SEND→HIT	Delay between your send and the callback — fast means inline, slow means a queue or async job.
RECEIVED	Callback timestamp.
SEV	Provisional severity.

No hit? Confirm the request actually reached the target, give async sinks (email, background jobs) a minute, and on a BYO server double-check DNS delegation and that ports 53/80/443 are open — see the OAST troubleshooting section.

06Step 5 — Read the proof chain

Click a hit to open its detail tabs: Chain, Trigger request, Raw callback, and Payload notes. The Chain tab is the evidence story, in three links:

Link	What it shows
1 — YOU SENT	The request you issued, with your Beacon host in the sink.
2 — SERVER ACCEPTED	The target's response — typically unremarkable, which is the whole point of "blind".
3 — BEACON CALLED	The out-of-band callback that closes the loop: proof the backend reached your host.

Open the Raw callback tab for the forensic metadata Crusader parses from the Interactsh interaction:

Field	Meaning
source_ip	Who connected — pivot point for mapping internal egress.
geo / asn	Geo and network of the caller, when the server enriches it.
resolver	The DNS resolver that performed the lookup.
protocol	DNS / HTTP / HTTPS / SMTP.
sent_at → received_at	Both timestamps and the send→hit delta.

Geo and ASN come from the Interactsh server, not Crusader. They're parsed straight from the callback JSON, so they may be blank on a BYO server that doesn't enrich interactions — there's no built-in IP-geo database. A blank geo is not a failed hit; the source IP and chain still stand on their own.

07Step 6 — Promote to a finding

Once the chain holds up, promote it. Use the Promote to finding header button or the shortcut P. Crusader writes a Finding with source beacon, carrying the chain and callback metadata as evidence. The title is chosen from the callback type — for an HTTP SSRF callback it's "Blind SSRF callback"; related templates include "Routing-based SSRF via Host header", "Blind XXE callback", "Stored XSS payload callback", and "Email leak callback".

The finding lands in Scanner → Findings alongside everything else, where you can triage it and — on Hunter Pro — export a report (Markdown, SARIF, JSON, CSV, HackerOne, Jira). Local findings stay available on Free; exporting reports requires Hunter Pro.

Beacon evidence is yours to keep. Even if a Pro license lapses, local projects, findings, and Beacon callback history stay available — expiry only pauses new Pro actions.

08Weak signals & honest limits

Not every callback is a clean SSRF, and Crusader is deliberately strict about what it will let you promote — because a finding that doesn't survive a triager's scrutiny costs you credibility.

A DNS-only Host-header callback is refused

If your only hit is a DNS interaction triggered by a Host header, promotion is blocked. A Host value gets resolved during normal routing, so this is noise, not evidence. Promote only on an HTTP callback (which proves routing-based SSRF, the actual fetch).

Other DNS-only hits promote, but cap at INFO

A DNS-only callback from any other sink will promote, but Crusader caps it to INFO with an explicit note: "DNS-only callback (weak signal) — resolution proves the payload reached a resolver, not that the target made an HTTP request." To raise the severity, get an HTTP callback — that's the difference between "something looked up my name" and "the server fetched my URL".

The honest boundary

The scanner surfaces SSRF candidates but never auto-verifies them. Verification is this manual, authorized workflow — there is no one-button blind-SSRF prover.
Geo/ASN may be blank on BYO servers; enrichment comes from the Interactsh server, not Crusader.
Out-of-band testing reaches real third-party infrastructure. Only plant payloads against targets you are explicitly authorized to test.

Run your own OAST server → The Scanner → Identities & Shadow Replay →

Want a guide that isn't here yet? Email hello@crusaderproxy.com.