The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Coverage differences between public and private Collaborator instances

Nicolas | Last updated: Apr 06, 2016 09:03PM UTC

I recently tested Collaborator using different injection scenarios. I noticed that the vectors used are different, depending if Collbaorator is defined by its DNS name (public or private instance) or its IP address (private only). Given the injection point "http://_HERE_:31337/yolo", only a private instance defined by its IP address will trigger a "Out-of-band resource load (HTTP)" event. Other ones will only trigger "External service load (DNS)". That's because, in the first case, a vector uses "[PRIVATE_COLLAB_IP]/[DYNAMIC_BURP_TOKEN]" and the target will connect to port TCP/80 and not TCP/31337. Why not add this check to other Collaborator modes?

PortSwigger Agent | Last updated: Apr 08, 2016 12:28PM UTC

If a user configures a private Collaborator server only by IP address, without a DNS domain assigned to it, then we can't use any DNS-based techniques to trigger or detect interactions. We can only use actual services (like HTTP) to connect to the IP address. For this reason, it is more effective to use a dedicated domain or subdomain for private Collaborator servers.

Burp User | Last updated: Apr 11, 2016 09:03PM UTC

I understand the limitations of an IP-based private Collaborator server, thanks ;-) My point is that, depending on the injection point, an IP-based instance may trigger additional connections (here "HTTP" vs "only DNS") than a DNS-based instance (public or not). So, in this scenario, the IP-based instance _is_ more effective than DNS ones.

PortSwigger Agent | Last updated: Apr 12, 2016 07:50AM UTC