Skip to content
OPS // KITitspentest.sh

E-BUR

Burp Collaborator

Out-of-band interaction service built into Burp Suite Pro/Enterprise for confirming blind SSRF, XXE, and command injection.

Official siteBack to catalog

OVERVIEW

Burp Collaborator generates unique, per-payload subdomains (or uses PortSwigger's public Collaborator server) and then polls for any DNS lookup, HTTP request, or SMTP connection back to that subdomain. When a manual test or an automated scan inserts a Collaborator payload into a request and the target server later resolves or connects to it, that interaction is the proof a vulnerability exists even though the HTTP response itself looked completely normal.

It plugs directly into the rest of Burp Suite — see the separate Burp Suite entry on this site for the base proxy/Repeater workflow — through a right-click 'Insert Collaborator payload' action in Repeater and Intruder, and Burp's automated scanner uses it under the hood to flag blind SSRF, blind XXE, and out-of-band command injection that active-response testing alone would miss. It ships only with Burp Suite Professional and Enterprise; Community Edition does not include it.

USE CASES

Practical use cases

  • 01

    Confirming blind SSRF by placing a Collaborator payload in a URL parameter and watching for an inbound DNS/HTTP callback.

  • 02

    Detecting blind XXE by embedding a Collaborator URL in an external entity and checking for a resulting out-of-band request.

  • 03

    Proving out-of-band command injection or blind code execution when the response gives no direct feedback.

  • 04

    Letting Burp's automated scanner surface OAST-based findings during a full crawl without manual payload placement.

QUICK START

When a payload might trigger a blind SSRF, XXE, or command injection with no visible response, to get out-of-band proof via a DNS/HTTP callback.

  1. Confirm the engagement authorizes out-of-band testing and that using PortSwigger's public Collaborator server (rather than a private one) doesn't violate a data-residency requirement.
  2. Open the Collaborator client (Burp menu > Collaborator client) and generate a payload.
  3. Insert the generated payload into the suspect parameter via Repeater or Intruder and send the request.
  4. Poll the Collaborator client for interactions and correlate any DNS/HTTP hit back to the exact request that triggered it.

BEFORE YOU RUN IT

What to check before running it

Only available in Burp Suite Professional and Enterprise — Community Edition has no Collaborator client at all.

The default public Collaborator server sends interaction data through PortSwigger's infrastructure; on engagements with strict data-residency or confidentiality requirements, use a private Collaborator server instead.

A missing interaction after a reasonable wait doesn't prove the app is safe — egress filtering or a slow backend job can suppress the callback without meaning the vulnerability isn't there.

KEEP EXPLORING

View the whole phase →