While building a security tool of his own our Security Consultant Calum Boal discovered a helpful design quirk on the industry’s favourite Pen-Testing tool - Burp Suite.
Calum has always been passionate about sharing his discoveries with fellow Security Researcher’s (particularly ones that save time). So, in this blog, he sets out a step-by-step guide to gaining persistent access to Burp Suite’s Collaborator sessions without the need to write any code or build any infrastructure.
How I gained persistent access to Burp’s Collaborator Sessions
In this write up, I set out an easy way to gain persistent access to Burp Suite’s Collaborator sessions. Previously these were thought to be volatile, and to disappear once the current instance of the Collaborator client is closed. There are other ways of doing this but this approach saves the most time.
What is Burp Suite Collaborator?
The Collaborator client in Burp allows you to generate Collaborator links and monitor DNS, HTTP, and SMTP interactions made by external services. It’s an excellent feature that greatly simplifies testing for vulnerabilities like Server-Side Request Forgery (SSRF), Blind-XSS, and other issues which may cause external service interactions.
How did I come across this?
I was trying to re-create the research pipeline in the whitepaper 'Cracking the lens' by James Kettle, so that I could integrate it into my enumeration/scanning tool ‘Ardent’ which I’ll release on Github soon.
Immediately I was faced with a choice of either rolling my own interaction server, or living with the limitations imposed by Collaborator namely:
- Manually generated links are only usable if the Collaborator client is open, and…
- They don’t survive exiting Burp
But my goal was to scan a large range of targets over an extended period, so I decided to see if I could piggyback off Collaborator in a less obvious way, before taking the plunge and spending time implementing my own solution.
Initially, I found that you can run your own Collaborator server, (which I highly recommend BTW if you want to avoid pissing off PortSwigger). However, even with your own Collaborator server, there is no obvious way to interact with it outside Burp. Which leads me to the following…
What is the work around?
I discovered that in order to maintain a simple, stateful Collaborator implementation, Collaborator subdomains are generated using a key derivation function based on a secret key. This secret key is generated by the Collaborator client as soon as you open it and it’s destroyed as soon as you close it.
When polling for interactions, Collaborator’s server then regenerates the list of Collaborator domains from the secret key, and returns the interactions it has recorded against those subdomains. This opens the possibility of capturing a Collaborator secret key and using it to poll for interactions made against links generated from that secret key.
Step 1: Set Collaborator up to poll over HTTP
Before we can capture any polling requests, we have to set Collaborator up to poll over HTTP, and we do that over in: Project Options->misc
Step 2: Intercept a polling request
Now, as this is a HTTP based protocol, you could just use two instances of Burp to intercept a polling request between Burp and the Collaborator server. However, it’s just easier to use Wireshark.
Once Collaborator is set up and Wireshark is listening on the appropriate interface, go to Burp->Collaborator Client and press ‘Poll now’. Now when you check Wireshark, you should see a HTTP request to
Take note of the secret key value sent as the value of the biid parameter.
Step 3: Generate some links to use in the future
With your secret key in hand, it’s time to create some links to use with it in the future. Generate as many links you think you may need and save them somewhere, along with the secret key.
However, it is worthwhile note that the Collaborator server ignores any data you prepend to the generated link, thus allowing you to store data by inserting it as a subdomain of the Collaborator link. This is similar to how DNS tunnelling functions, in fact, you can even perform DNS tunnelling using collaborate if you like. https://github.com/NetSPI/BurpCollaboratorDNSTunnel
Step 4: Retrieve interactions from the links
That’s it - you can now retrieve interactions with any of these links simply by sending a HTTP GET request to
http://polling.burpcollaborator.net/burpresults?biid=SECRET_KEY_HERE. And, because the Collaborator server generates the links using the secret key, they will never expire. Be careful though, the Collaborator server is ephemeral, so may lose data if it’s left there for prolonged periods. Therefore, I recommend you poll more regularly if you pull your data in real time.
Hopefully Burp will add support for persistent access to the collaborator client in the future, especially for paying users. In the meantime, I hope this workaround helps Security Researchers who struggle with the current limitations of the Collaborator Client. There are of course other ways to achieve similar results, but not with the same level of convenience. For example;
If you’re not familiar with James Kettle’s archive I recommend you start with his fascinating talk 'Cracking the lens' before just diving right into messing about with it yourself. It’s truly bizarre the kinds of interactions you’ll get from services by placing links in weird places. You may find yourself scratching your head trying to figure out why you’ve so many pingbacks for China, even though you never sprayed there ;).
Let me know what interesting stuff you come across, and if you have any questions about any of this guide, drop me an email at email@example.com or get in touch with me on LinkedIn
Finally, I’ll be releasing ‘Ardent’ on Github soon. In the meantime, if you have any ideas for topics you’d like me to cover - I’d love to hear from you.
About Calum Boal
Calum is our Security Consultant at OnSecurity and works out of our Bristol office. He graduated Abertay University with honours in Ethical Hacking and has since obtained CSPA OSCP and CRT. Feel free to connect with him on LinkedIn.