Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Collaborator server catching specific ports

Simko, | Last updated: Jul 17, 2021 09:56AM UTC

Hi, I'm not sure if it would be technically feasible, but would it be possible for the Collaborator server capture which port (UDP/TCP) was tried to be used? I mean if I simply do ssh XXX.burpcollaborator.net I receive only the DNS resolution, because the protocol is not supported. I think there might be quite a few interactions which would not only be using DNS, but tried to communicate on some specific port of the application, which might not get the "attention it deservers" from the pentester. Or implementing some "Collaborator 2.0", which would take some time to spin up (much like Academy host), but then pentester could see what exactly is going on? E.g. wireshark dump; or seeing those specific ports. The usecase would be, if I see DNS interaction I would use the "Dedicated Collaborator" instance to observe what exactly is going on and investigate further. Thanks for the consideration:)

Michelle, PortSwigger Agent | Last updated: Jul 19, 2021 09:29AM UTC

Thanks for the feedback. Can you tell us a bit more about what you have in mind? Are there any specific protocols you have in mind? If it's easier to explain with the aid of pictures feel free to send us an email :)

Simko, | Last updated: Jul 27, 2021 09:17AM UTC

Hi Michelle, well the problem is, that many times I get DNS resolution with Collaborator but I have no idea, if only DNS resolution is performed, or some specific port interaction is attempted. For example, if there was a hardcoded port 8081, to which a server would send some traffic/try to parse the response, I would not know that with current Collaborator. Whereas, with having a dedicated "special instance" of collaborator server which I could use, and see which port was attempted to be opened, it would be a great help. Not necessarily supporting different protocols (e.g. SSH), but having the information "DNS resolution was performed, followed by attempting to open port 22" would help a lot. Or even obtaining a .pcap Wireshark file with the traffic would be nice. Is it more clear now? Thanks, Andrej

Michelle, PortSwigger Agent | Last updated: Jul 28, 2021 08:08AM UTC

Thanks for the update. To capture requests that are sent to the Collaborator IP on random ports where the Collaborator server has not been set to listen would really be something best done at the OS level or using external network monitoring, I'm afraid. The timestamps on the requests could then potentially be used to match up the DNS requests with any connections where the OS has sent a reset (and so won't have reached the Collaborator software). I hope that makes sense. If you've got any questions, let me know :-)

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.