Outbound Interaction & OOB Detection

Purpose

Use this skill for outbound interaction and out-of-band validation when the hypothesis requires callback evidence rather than an immediate in-band response.

Primary use cases:

SSRF callback confirmation
Blind XSS beacons
Blind XXE
Webhook delivery validation
DNS, HTTP, or HTTPS callback correlation
Asynchronous server-side interaction proof
Reverse-shell-adjacent egress testing where the goal is callback validation, not shell handling

Use an in-band validation skill instead when the finding can be confirmed fully in-band.

Operating Rules

Treat OOB validation as evidence collection, not only payload delivery.
Generate a unique correlation token for every test case.
Keep control and test payloads separate.
Correlate events by token, subdomain or path, and timestamp before confirming a finding.
Preserve session state and callback logs on disk.
Keep the listener running long enough for delayed interactions.
Use the minimum protocol set that can validate the hypothesis.
Do not claim confirmation from background traffic or uncorrelated callbacks.
Do not send real secrets in callback payloads.

Activation Triggers (Positive)

Use this skill when the request or observed behavior includes:

ssrf callback
blind xss
webhook abuse
oob
dns interaction
asynchronous callback
xxe out of band
blind xxe
http callback
https callback
egress validation

Handoff Criteria

Hand off to pentest-xss for XSS context, browser sink analysis, and payload construction before OOB callback correlation.
Hand off to pentest-input-protocol-manipulation for parser, XXE, SSRF, or request mutation work.
Hand off to pentest-exploit-execution-payload-control only after deterministic outbound behavior is confirmed.

Validation Standard

Only confirm the finding if all of the following are true:

A unique per-test token was generated before payload delivery.
The payload under test embedded the expected callback identifier.
An interaction was observed in the allowed test window.
The observed interaction matches the token plus path or subdomain plus timestamp.
Control cases do not explain the same signal.

Verdicts:

confirmed: deterministic correlation exists
inconclusive: partial signal without enough correlation
not confirmed: no matching interaction or controls invalidate the claim

Instructions

Generate unique per-test correlation identifiers before sending payloads.
Ensure callback listener scope and retention are sufficient for delayed events.
Correlate callbacks by token, path, and time window before confirmation.
Differentiate noisy background traffic from test-linked interactions.
Use control payloads to reduce false positives.
Pass confirmed primitives to exploit or logic skills with full correlation evidence.

Verification Gate

Treat OOB validation as evidence discipline, not only payload dispatch.
Preserve immutable callback logs for auditability.
Include both positive and negative control outcomes.
Confirm only with deterministic correlation.
Use fresh tokens for unrelated tests.
Keep real secrets out of callback payloads.

Standard Workflow

Define the hypothesis and expected outbound behavior.
Choose the smallest callback mechanism that can validate it.
Start one listener session for the assessment run.
Generate one unique token per probe.
Embed the tokenized callback endpoint into the payload.
Send the payload and record the timestamp and source context.
Monitor for matching interactions during the expected window.
Compare with controls before reaching a verdict.
Pass confirmed primitives to exploit or logic-abuse workflows with full evidence.

Listener Component

Use interactsh-client or an equivalent controlled callback service for DNS, HTTP, and HTTPS callback validation when available.

Reference startup pattern:

RUN_DIR="/tmp/interactsh-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$RUN_DIR"

interactsh-client \
  -json \
  -o "$RUN_DIR/interactions.jsonl" \
  -sf "$RUN_DIR/session.txt" \
  -ps \
  -psf "$RUN_DIR/payloads.txt" \
  -pi 5 \
  >"$RUN_DIR/stdout.log" 2>&1 &

echo $! > "$RUN_DIR/interactsh.pid"
sleep 2
cat "$RUN_DIR/payloads.txt"

Listener handling rules:

Start one background listener per assessment run unless isolation requires a separate session.
Persist interactions.jsonl, session state, generated payload domains, and stdout logs.
Keep the listener active for the full validation window.

Per-Test Token Generation

Generate one unique token for each test case:

TEST_TOKEN="$(tr -dc 'a-z0-9' </dev/urandom | head -c 10)"
BASE_DOMAIN="$(head -n1 "$RUN_DIR/payloads.txt" | tr -d '\r\n')"
CALLBACK_FQDN="${TEST_TOKEN}.${BASE_DOMAIN}"

echo "$TEST_TOKEN $CALLBACK_FQDN $(date -Iseconds)" >> "$RUN_DIR/test_tokens.log"

printf '%s\n' "$CALLBACK_FQDN"

Rules:

Never reuse a token across unrelated tests.
Record token, payload target, source vector, and timestamp.
Use path-based correlation in addition to subdomain-based correlation when useful.

Protocol Selection

Choose the protocol that matches the hypothesis:

DNS: egress proof, resolver behavior, low-friction SSRF or XXE validation
HTTP: webhook delivery, SSRF, application-layer callback verification
HTTPS: when the target is likely to enforce TLS-only egress

Prefer the smallest useful set. Do not spray all protocols unless the test requires it.

Reverse-Shell-Adjacent Egress Checks

Use this skill for reverse-shell-adjacent validation only when the objective is to determine whether the target can reach an external endpoint over common egress channels such as 80 or 443.