Run your own private OAST server

01Why a private OAST server

OAST (out-of-band application security testing) catches the bugs that never show up in a response — blind SSRF, blind XXE, blind SQLi, out-of-band command injection, deserialization callbacks, SSRF-to-metadata. You plant a unique hostname; when the target resolves or requests it, the interaction server records the hit.

The catch: every callback is sensitive intelligence. The DNS query and HTTP request that reach the interaction server reveal the target you're testing, the parameter and vuln class (encoded in your payload), the timing of your engagement, and often the egress IP of the target's infrastructure. On a shared, hosted interaction server, all of that lives on someone else's box.

Running your own server means:

• Confidentiality — callbacks for a private program or a sensitive client never touch third-party infrastructure.
• Reliability — no shared-server rate limits, blocklists, or downtime; some targets also block well-known public OAST domains outright.
• Custom payloads — your own root domain and payload prefix, which read cleanly in reports and dodge signature-based filtering of public OAST domains.
• Retention control — you decide how long interaction logs are kept, and where.

02What you'll need

• A domain you control, where you can edit DNS records (a cheap dedicated domain is ideal — you'll delegate a subdomain to your server).
• A VPS with a static public IPv4 (any small instance works). You'll open a few inbound ports on it.
• Go 1.21+ on your workstation for interactsh-client (or grab the prebuilt binary). The one-shot installer fetches the server binary itself, so the VPS needs Go only if you take the manual route.
• Crusader with Beacon (part of Hunter Pro). BYO mode points at your own server, so it doesn't use the hosted-callback quota.

03Step 1 — Delegate a domain to your server

Your interaction server has to be the authoritative DNS for an OAST subdomain so it can answer the lookups targets make. Pick a subdomain — we'll use oast.example.com — and, at your domain's DNS provider, create a nameserver pointing at your VPS and delegate the subdomain to it:

# at the DNS provider for example.com — replace 203.0.113.10 with your VPS IP
ns1.example.com.     A     203.0.113.10
oast.example.com.    NS    ns1.example.com.

That A record is the "glue" that tells the world where your nameserver lives; the NS record hands the whole *.oast.example.com zone to it. After this, any lookup of anything.oast.example.com is routed to your VPS. (Add a second ns2 pointing at the same IP if your registrar requires two nameservers.)

Open these inbound ports on the VPS firewall / security group:

04Step 2 — Run interactsh-server

Two ways to do this on the droplet — a one-shot installer that wires up everything, or the manual route.

Option A — one-shot installer (recommended)

This script downloads interactsh-server straight from ProjectDiscovery's official GitHub releases (nothing is bundled or re-hosted), verifies its checksum, then sets up a dedicated service user, a systemd unit, the firewall, frees port 53, and prints your token plus the exact Crusader settings. Review it first — never pipe an unread script into a shell:

# on a fresh Ubuntu/Debian droplet, as root
curl -fsSL https://crusaderproxy.com/oast-setup.sh -o oast-setup.sh
less oast-setup.sh                          # read it
sudo OAST_DOMAIN=oast.example.com bash oast-setup.sh

It auto-detects the droplet's public IP and generates an auth token; override either with OAST_IP= / OAST_TOKEN=, or add OAST_PORTS_SMTP=1 to also open the SMTP ports. When it finishes it prints the ROOT DOMAIN / INTERACTSH SERVER / API TOKEN to paste into Crusader — then skip to Step 3.

Option B — manual

Install and start the server yourself. Use -auth so only your token-bearing client can pull interactions:

# install from ProjectDiscovery's GitHub
go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-server@latest

# run (auto-provisions Let's Encrypt TLS when 80/443 are reachable)
interactsh-server -domain oast.example.com -ip 203.0.113.10 -auth

On first start it prints a line like Client Token: 9f3c… — copy that token. Run it under systemd (or tmux/screen to start) so it survives disconnects, and open ports 53/80/443 yourself (Step 1). On Ubuntu you'll also need to free port 53 by disabling the systemd-resolved stub listener — the one-shot installer handles that for you.

Either way, confirm the server is authoritative before moving on:

# should be answered by YOUR server, not NXDOMAIN
dig +short test.oast.example.com @ns1.example.com

05Step 3 — Install interactsh-client locally

Crusader doesn't reimplement Interactsh — it drives ProjectDiscovery's official interactsh-client on your machine and reads its event stream. Install it on the workstation running Crusader:

go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest

That drops the binary in ~/go/bin (or %USERPROFILE%\go\bin on Windows). Crusader auto-detects it on your PATH or in the Go bin directory; if you installed it somewhere custom, you'll set the path in the next step.

06Step 4 — Point Crusader's Beacon at it

In Crusader, open Beacon from the sidebar, then Beacon settings. At the top, switch the provider from CRUSADER to CUSTOM — this unlocks the fields for your own infrastructure. Fill in:

Click Save and enable. Crusader launches interactsh-client against your server, and the REGISTERED PAYLOAD field auto-fills with your live callback host (something like c8f1a2…oast.example.com). The Beacon domain pill at the top of the screen turns active.

07Step 5 — Verify a callback

From the Beacon screen, copy a payload (use Copy DNS or Copy HTTP), then trigger it yourself from another machine or shell:

# DNS interaction
dig +short <your-payload>

# HTTP interaction
curl -s http://<your-payload>/canary

Within a second or two the hit appears in Crusader's Beacon feed — protocol, source IP, and timestamp — and you can promote it straight to a finding. If you see it here and in your server's logs but nowhere else, you've got a fully private OAST pipeline. Drop the payload into a suspected blind SSRF/XXE/RCE sink and hunt.

08Troubleshooting

No hits at all

Confirm DNS delegation first — dig NS oast.example.com should return ns1.example.com, and dig test.oast.example.com should be answered by your server (not NXDOMAIN). If that's broken, callbacks never reach you. Then check the VPS firewall actually allows inbound 53/udp and 80/443.

"BYO Beacon needs an Interactsh server URL"

The INTERACTSH SERVER field is empty. Set it to your server URL and save again.

Registered payload never fills in

Crusader can't find or start interactsh-client. Verify it runs from a terminal (interactsh-client -server https://oast.example.com -token <token>); if it works there but not in Crusader, set CLIENT PATH explicitly to the binary.

Client connects but pulls nothing

Token mismatch. The API TOKEN in Crusader must equal the server's Client Token. If you restarted the server without persisting auth, it generated a new token — copy the current one.