OAST Correlation and Callback Triage
Turn DNS, HTTP, and SMTP interactions into attributable evidence by assigning one token to one request, one field, and one hypothesis.
Every step requires authorization. Review side effects before running commands against a live system.
Define the boundary before the test.
- Preconditions
- Current scope, observed technology, reachable feature, controlled identities or data, and a recovery plan.
- Expected evidence
- One observable response, state, or callback that distinguishes the hypothesis from normal behavior.
- Negative control
- The same action with the security-sensitive variable removed, replaced, or bound to its rightful owner.
- False-positive checks
- Cache, retry, race, reflection, proxy rewriting, stale sessions, and unrelated asynchronous activity.
- Chain gate
- Record the proven primitive and the next missing prerequisite. Do not expand impact until scope and authorization still permit the next step.
Create the callback ledger
Record campaign, case, request, field, variant, generated hostname, submission time, trigger action, expected protocol, and stop condition before sending anything. Reserve one token that will never be submitted as an ambient-noise control.
campaign=acme case=ssrf-014 request=req-88 field=avatar_url variant=https-directUse one token per insertion point
Never reuse a callback hostname across fields or requests. Encode readable correlation in the leftmost label or path while staying within DNS label and URL length limits. Keep the payload free of target secrets and user data.
ssrf014-req88-avatar-https.UNIQUE.oast.example/probeCapture raw interactions
Save raw event time, protocol, query or request line, source address, user agent, and the exact token. Avoid public callback logs. Redact target identifiers before sharing derived evidence.
interactsh-client -server YOUR_PRIVATE_INTERACTSH_SERVER -json -o interactions.jsonl -psClassify what the event proves
DNS can show name resolution, not a completed HTTP fetch. HTTP can show a request reached the listener, not that the response was consumed. Browser-like user agents can be scanners or renderers. SMTP may come from validation or delivery infrastructure. Label each conclusion no stronger than the protocol evidence.
Run confounder controls
Compare the unsubmitted token, a self-generated listener request, a repeated submission with a fresh token, and a version with the suspected trigger removed. Check security scanners, link previewers, mail gateways, retries, caches, and your own browser before assigning the callback to the target sink.
Build the evidence packet
Join the original request, callback ledger row, raw interaction, time delta, negative controls, alternative explanations, and bounded conclusion. Keep listener credentials and unrelated events out of the report.
Common guidance
- A green interaction indicator is not a finding until it is tied to a unique submitted token and a falsifiable hypothesis.
- Poll long enough for the documented asynchronous workflow, but do not keep resubmitting while waiting.
- Unique tokens make delayed callbacks useful. Shared tokens turn them into anecdotes.
- Preserve negative results because they define which protocol, field, or recall action mattered.
Mapped workflow tools
References
- https://portswigger.net/burp/documentation/collaborator ↗
- https://docs.projectdiscovery.io/opensource/interactsh/usage ↗
- https://github.com/projectdiscovery/interactsh ↗
Version history: normalized permanent page created 2026-08-20.