Self-hosting Oastify
Run your own out-of-band callback server, in-process or on a domain you own, so blind-bug callbacks land on infrastructure you control.
A shared out-of-band (OOB) service works, but the callbacks — and the proof they carry — pass through someone else's box. Self-hosting Oastify keeps every interaction on infrastructure you control, runs protocols the in-app server doesn't, and captures Windows credentials when a target authenticates back to you.
Why run your own
Every hit lands on your host, your disk, your domain. Nothing about a blind bug on a private target leaves your own infrastructure.
The standalone server adds RMI, gopher, TFTP, and raw-TCP listeners on top of DNS, HTTP/HTTPS, SMTP, LDAP, FTP, and SMB — the ones you reach for on JNDI, deserialization, and awkward SSRF chains.
When a target authenticates over SMB, the server decodes the handshake and
writes it in hashcat format — NetNTLMv2 (-m 5600), or NTLMv1 (-m 5500) on
older stacks — ready to crack offline.
Create a session with your own X25519 public key and every callback is sealed to that key before it touches disk. The server keeps ciphertext plus a throwaway ephemeral key; the secret that opens it never leaves your machine, so even a breach of the box hands an attacker nothing readable.
Two ways to run it
The native server (quick, no VPS)
Hugin runs the OOB listeners itself — nothing to deploy. Good for a fast callback host on a box a target can already reach. It answers DNS and HTTP.
hugin oastify native-start --domain oast.local --external-ip 203.0.113.10
# DNS on :53 and HTTP on :80 by default; override with --dns-port / --http-port
hugin oastify native-interactions --format table # watch what comes back
hugin oastify native-stop
For the full protocol set, TLS, and an encrypted database, run the standalone server instead.
The standalone server on your own domain
The hugin-oastify-server binary runs on a VPS under a domain you own, behind
TLS, with the database encrypted at rest and a time-to-live (TTL) on every
payload token. hugin oastify-setup prints a complete deployment guide — DNS
records, config file, nginx, and a systemd unit — with fresh credentials
filled in:
hugin oastify-setup --domain oob.example.com --ip 203.0.113.10
Point the domain at the box with three kinds of DNS record: an A record for the
apex, a wildcard A record so every {token}.oob.example.com resolves, and NS
glue (ns1/ns2 A records) so the server answers queries directly — that is what
makes DNS callbacks fire. Terminate TLS with nginx and certbot over both the
apex and the wildcard.
A public OOB server is internet-facing: it answers DNS on 53, may run SMTP on
25, and logs callbacks from live targets. Keep the admin key and API token
secret, and only catch callbacks from targets you are authorised to test.
Drive it from the command line
Once a server is up, the hugin oastify subcommands talk to it. Interactions
also stream live over Server-Sent Events (SSE).
hugin oastify connect --domain oob.example.com --session my-hunt # attach (optional --token)
hugin oastify generate # mint a tracked payload host
hugin oastify interactions --format table # list what called back
hugin oastify status # connection state and stats
hugin oastify stream-url # print the live SSE feed URL
Let the Scanner confirm with it
Point Hugin at your server and the Scanner's blind checks confirm against it: a check plants a payload, your host logs the callback, and the finding arrives with proof instead of a guess.
OOB confirmation in the Scanner is Pro. The listeners and manual callbacks work on every tier — Pro is the automatic wiring of blind checks to your server.