pentest-outbound-interaction-oob-detection

name	pentest-outbound-interaction-oob-detection
description	Outbound interaction and OOB validation for SSRF callbacks, blind XSS beacons, webhook abuse, XXE/OOB behavior, DNS/HTTP/HTTPS callback correlation, asynchronous server-side interaction proof, and egress validation.

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:

1. A unique per-test token was generated before payload delivery.
2. The payload under test embedded the expected callback identifier.
3. An interaction was observed in the allowed test window.
4. The observed interaction matches the token plus path or subdomain plus timestamp.
5. 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

1. Generate unique per-test correlation identifiers before sending payloads.
2. Ensure callback listener scope and retention are sufficient for delayed events.
3. Correlate callbacks by token, path, and time window before confirmation.
4. Differentiate noisy background traffic from test-linked interactions.
5. Use control payloads to reduce false positives.
6. 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

1. Define the hypothesis and expected outbound behavior.
2. Choose the smallest callback mechanism that can validate it.
3. Start one listener session for the assessment run.
4. Generate one unique token per probe.
5. Embed the tokenized callback endpoint into the payload.
6. Send the payload and record the timestamp and source context.
7. Monitor for matching interactions during the expected window.
8. Compare with controls before reaching a verdict.
9. 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.

Rules:

• Use this skill for outbound reachability and protocol behavior validation, not shell handling.
• If shell-capable execution is later confirmed, hand off to the exploit execution workflow.

Evidence to Capture

For each test case, record:

• hypothesis
• payload vector
• generated token
• callback endpoint
• request timestamp
• control payloads
• observed callback timestamp
• protocol observed
• source context
• verdict

Output Schema

Return:

• Correlation table with token, payload path or subdomain, timestamp, source context
• Validation verdict: confirmed, not confirmed, or inconclusive
• Follow-on opportunities based only on confirmed outbound behavior
• Reproduction steps with enough detail for another operator to rerun the test

Tooling Notes

• If interactsh-client or an equivalent listener is missing, state that clearly, recommend the missing tool for the next run, and stop short of confirming OOB claims.
• Do not replace deterministic correlation with assumption.
• Preserve logs so callback-based claims remain auditable.