SSRF — server-side request forgery
Point a URL parameter at your payload. If the server fetches it, the HTTP (and a preceding DNS) interaction confirms the SSRF — even when the response body is never shown.
oob.boo · documentation
A practical guide to out-of-band application security testing (OAST) and how to use oob.boo — a free Burp Collaborator / interactsh alternative — to prove blind vulnerabilities across eight protocols.
Many high-impact web vulnerabilities are blind: the application is exploitable, but the result never appears in the HTTP response you can see. Server-side request forgery, blind XXE, many injection flaws and unsafe deserialization all fall into this category.
Out-of-band application security testing (OAST) solves this by giving you a server the target can talk to over a side channel. You plant a unique payload that points at <token>.c.oob.boo; if the target is vulnerable it reaches out to that host, and the interaction lands in your dashboard — tagged with the source IP and network. The callback is the proof.
Every payload you generate is keyed to a random, unguessable <token> — a 16-character subdomain of c.oob.boo. That token is both the address and the secret: only a browser holding it can read its interactions, and the token never leaves your browser.
oob.boo's authoritative DNS owns the whole c.oob.boo zone, so any lookup or connection to <token>.c.oob.boo is routed to a listener we run. Each listener — DNS, HTTP/S, SMTP/S, LDAP, FTP, SMB — records the interaction, attributes it to your token, and resolves the source IP to its owning network (ASN).
One token, eight listeners. Each protocol below shows the payload form and what a callback proves. In every diagram, <token> is your unique collaborator id.
A DNS lookup happens before almost any other protocol, so it's the most reliable signal. It's the channel of choice for blind SQL injection, command injection and data exfiltration — attacker-controlled data can be smuggled inside the subdomain labels.
A full request (method, path, headers, body) is captured. This is the classic SSRF signal and also fires from blind XXE, webhook misconfigurations, PDF/image renderers and link-preview fetchers. HTTPS serves valid TLS, so strict clients still connect.
Any local-part works; the token is taken from the domain. Mail delivered to the address is captured on ports 25, 587 (STARTTLS) and 465 (implicit TLS), with envelope, headers and body. Useful for finding email-injection, password-reset host poisoning and open-relay style flows.
The token is repeated in the path so the bind/search can be attributed (LDAP carries no hostname). It's a detection sink, not an exploit — it never serves a JNDI reference — making it safe for confirming ${jndi:ldap://…} injection.
A directory-form payload makes the client issue CWD <token> on the control channel, which is captured and attributed. Fires from XXE and SSRF against parsers that follow ftp:// URLs.
A UNC payload coerces a Windows client to authenticate, and the NTLMv2 response is captured (hashcat -m 5600). This is the signal for forced-authentication / NTLM-relay exposure.
Five common blind-vulnerability classes and how a oob.boo callback confirms each.
Point a URL parameter at your payload. If the server fetches it, the HTTP (and a preceding DNS) interaction confirms the SSRF — even when the response body is never shown.
Define an external entity that resolves your payload. A vulnerable XML parser dereferences it, producing a DNS/HTTP (or FTP) callback that confirms the XXE.
Put a JNDI lookup in any value that gets logged (a header, username, search field). A vulnerable Log4j performs an LDAP lookup of your host — the LDAP interaction confirms it, no exploitation required.
Where the DB can trigger a network lookup, you can both confirm the injection and exfiltrate data by encoding it into the subdomain. The DNS query name carries the stolen value straight to your dashboard.
Coerce a Windows host to open a UNC path (e.g. via an injected image/stylesheet path or a vulnerable parser). It authenticates to your SMB listener and the NTLMv2 response is captured for offline cracking or relay assessment.
| Free | Pro (coming soon) | |
|---|---|---|
| Protocols | All 8 | All 8 |
| Payload lifetime | 3 hours | Extended |
| Active collaborators at once | 3 | More |
| Source IP + network (ASN) | Yes | Yes |
| Captured NTLMv2 / credentials | Redacted | Revealed & exportable |
| Account required | No | No |