Out-of-Band (OOB) Detection

What is out-of-band (OOB) detection?

Most vulnerability scanners look for proof of a flaw in the HTTP response they receive - an error message, a reflected value, a changed status code. But some of the most dangerous vulnerabilities produce no visible response at all. The server is compromised, data leaks out, or a network request fires outbound - yet the HTTP response looks completely normal.

Out-of-band (OOB) detection solves this by using a second communication channel. Instead of waiting for the vulnerable server to tell us something in the response, Shieldome injects a payload that causes the server to reach out to a Shieldome-controlled probe endpoint. If the probe receives a hit, the vulnerability is confirmed - regardless of what the original HTTP response said.

💡

Why this matters: Blind vulnerabilities are more dangerous than reflected ones, not less. An attacker exploiting blind SSRF or XXE has already won - they just do not announce it in the response. Standard scanners that only read HTTP responses miss these entirely.

What Shieldome detects via OOB

Blind SSRF (Server-Side Request Forgery)

Shieldome injects a Shieldome-owned URL into request parameters that are likely to be fetched by the server - URL fields, webhook endpoints, image import URLs, PDF generators, and similar. If the target server fetches the URL, the probe logs the inbound request and the finding is confirmed.

Classic SSRF tests that only check for 169.254.169.254 (cloud metadata) in the response miss every SSRF variant where the server fetches the URL but does not echo the response back to the browser. Shieldome catches those.

Blind XXE (XML External Entity)

When an application parses XML, a malicious external entity declaration can cause the parser to fetch a remote URL. Shieldome injects XXE payloads into XML upload endpoints and SOAP bodies. If the XML parser fires an outbound request, the probe receives it - confirming the parser processes external entities even when the server returns no visible error.

🛡️

Passive-safe: OOB probes are harmless GET requests to a URL Shieldome owns. No data is exfiltrated, no commands are executed, and no side effects are triggered on the target. The probe URL is unique per scan and contains no sensitive data.

How it works

Shieldome uses Interactsh - an open-standard OAST (Out-of-Band Application Security Testing) protocol - to create a unique, encrypted callback session per scan.

At scan start, a fresh RSA-2048 key pair is generated and registered with the Interactsh server. This produces a unique per-scan subdomain, e.g. a1b2c3d4e5.interact.sh.
This subdomain is embedded into OOB-capable payloads injected during the scan.
After all probes are fired, the engine waits and polls the Interactsh server for any inbound interactions. Interaction data is AES-GCM encrypted on the server and decrypted locally with your session key - the probe server never sees plaintext.
If a callback is received, the finding is confirmed and classified by protocol (HTTP/HTTPS, DNS).

A blind SSRF probe looks like:

example - URL parameter injection

GET /api/preview?url=http://a1b2c3d4e5.interact.sh/ssrf-param-url HTTP/1.1
Host: app.example.com

An XXE probe:

example - XXE OOB payload

<!-- DOCTYPE triggers an outbound fetch if the parser resolves external entities -->
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://a1b2c3d4e5.interact.sh/xxe">
]>
<foo>&xxe;</foo>

When the target fetches any of these URLs, Interactsh receives an HTTP or DNS interaction. Shieldome polls for this interaction, decrypts it, and records the confirmed finding with protocol, source IP, and timestamp as evidence.

How to enable OOB detection

OOB detection is automatic on all plans. There is nothing to configure. Every scan generates a fresh Interactsh session, fires probes, and polls for callbacks before the scan finalises.

💡

If your target server is behind a strict egress firewall that blocks outbound HTTP, OOB probes will not reach the receiver. In that case, no OOB findings will be reported - this is expected behaviour, not a false negative. For internal networks, consider testing from within the same network segment.

What you see in results

When the probe receiver logs a hit for the scan's token, the finding in your scan results is updated:

The severity label shows ⚠️ OOB CONFIRMED
Severity is upgraded from MEDIUM to HIGH
The finding evidence block includes the probe callback timestamp and the source IP that made the inbound request to Shieldome

json - OOB-confirmed finding excerpt

{
  "id":        "ssrf-blind-url-param",
  "title":     "Blind SSRF - URL parameter",
  "severity":  "HIGH",
  "oob": {
    "confirmed":   true,
    "hit_at":      "2026-07-25T14:32:07Z",
    "source_ip":   "203.0.113.42",
    "probe_token": "a1b2c3d4e5f6"
  },
  "evidence":  "Server fetched https://app.shieldome.com/oob/a1b2c3d4e5f6 at 14:32:07 UTC from 203.0.113.42 - confirms server-side URL fetch."
}

Findings that were probed but did not produce a callback are reported at MEDIUM severity (the default for SSRF/XXE candidates) without the OOB CONFIRMED label. This does not mean the server is safe - it may mean the server's outbound traffic is filtered, or the parameter is not actually fetched server-side.

Limitations

HTTP callbacks only. Shieldome's OOB receiver listens for HTTP/HTTPS requests. DNS-level OOB detection (where the server resolves the probe hostname but does not make a full HTTP request) is not supported yet. DNS-level OOB catches a wider class of blind injections and is on the roadmap.
Blind SQL injection uses timing, not OOB. Time-based blind SQLi is detected by measuring response delays against a baseline - not via a database-initiated outbound connection. This is by design: a DNS/HTTP callback from a database server is an active exploitation step, which is outside Shieldome's passive-assessment scope.
60-second probe window. After the scan request phase ends, the probe receiver monitors for callbacks for 60 seconds. Servers that queue URL fetches asynchronously and execute them after a longer delay may not be caught within this window.
Egress filtering. Corporate and cloud environments often block outbound HTTP to unknown hosts. If the target cannot reach app.shieldome.com, OOB probes will not be received. This is not reported as a finding - the scan simply falls back to response-based detection for those checks.