docs

Oastify

Hugin's built-in out-of-band server — six protocols parsed for real, a unique correlated host per test, and a payload shaped for the channel each bug class reaches out on.

Oastify is Hugin's out-of-band (OOB) interaction server. It hands you a unique host carrying a correlation token and logs anything that touches it. When a target reaches out to that host — a DNS lookup, an HTTP fetch, an LDAP bind, an SMB connection — you have proof of a bug the response never showed you.

The Oastify view listing out-of-band interactions by protocol
A unique correlated host that logs every callback — the proof for a blind bug the response never showed you.

Which channel fires for which bug

The point of six listeners is that bugs leak on different protocols. DNS escapes networks that block everything else; LDAP is the Log4Shell path; SMB drags Windows credentials back. Reach for the channel the bug class actually uses:

DNS — the universal signal

The most reliable callback. A target with no outbound HTTP at all usually still resolves a hostname. This is your channel for blind SQL injection (MSSQL xp_dirtree, Oracle UTL_INADDR, MySQL LOAD_FILE over UNC), blind OS command injection (nslookup, dig, ping your host), XXE parameter entities, and SSRF where only the resolver leaks. A bare resolution proves reach.

HTTP / HTTPS — full request capture

When the target actually fetches your URL you get the whole request — method, path, every header, body. This is SSRF that follows the redirect, XXE pulling a SYSTEM URL, blind or stored XSS beaconing home, and SSTI that runs curl. The headers often name the internal client (User-Agent, cloud metadata tokens).

LDAP — JNDI and Log4Shell

The listener BER-parses the LDAP conversation, so a ${jndi:ldap://…} lands as a real bind/search with its base DN and filter captured — not just an open socket. This is the channel for Log4Shell, JNDI injection, and LDAP injection.

SMB — UNC coercion and NTLM theft

Drop a UNC path (\\host\share) into a path, link, or file field and Windows authenticates to you. The standalone server captures the NetNTLMv2 handshake in hashcat format — a callback that doubles as a crackable credential.

SMTP — mail and header injection

Real RFC 5321 verb handling: EHLO/HELO host, MAIL FROM, RCPT TO, and the subject on DATA. For email/SMTP header injection and SSRF aimed at a mail port.

FTP — awkward SSRF chains

Handles FTP commands and captures the username and verbs. For SSRF and XXE that accept an ftp:// URL.

Pick the right payload shape

Each channel needs the payload in its own shape. generate mints one per protocol against your domain — plant the one the sink expects:

ChannelPayload to plant
DNS{token}.oob.example.com
HTTPhttp://{token}.oob.example.com/
HTTPShttps://{token}.oob.example.com/
LDAP (JNDI)ldap://{token}.oob.example.com/dc={token}
SMTPsmtp://{token}@{token}.oob.example.com
FTPftp://{token}.oob.example.com/
SMB (UNC)\\{token}.oob.example.com\share

HTTP and HTTPS also come in a path variant (http://oob.example.com/{token}) for sinks that won't take an arbitrary subdomain.

Correlation: every callback names one test

The {token} in each payload is a correlation id minted from the operating system's CSPRNG (getrandom — not a userspace PRNG), so it is unguessable and collision-free. Length is configurable (12–256 characters; alphanumeric, hex, or base64), with an optional fixed prefix.

Every token is bound to the request and project that planted it, so an interaction maps back to the exact test — no guessing which payload of fifty fired. Interactions are logged live and optionally persisted; attach a context label when you generate to tag what you were testing.

More protocols, infrastructure you own

The in-app server runs the six above. Running your own standalone server adds RMI (:1099 for JNDI→RMI gadget chains), gopher (SSRF protocol-smuggling), TFTP (UDP egress from appliances), and a raw-TCP catch-all (JDBC, IIOP, anything custom) — and keeps every callback on a box you control, encrypted at rest, with NTLM capture.

Let the Scanner confirm with it

The Scanner wires Oastify into its blind checks (a Pro feature) — SSRF, XXE, blind SQLi, blind command injection, Log4Shell, deserialization and more plant a correlated payload and poll for the callback, so the finding arrives backed by a real interaction instead of a guess. Manual payload generation and callback capture work on every tier.

Last updated 2026-06-20.