Post

Building a Custom OOB Server

Building a Custom OOB Server

If you’re reading this, you’ve probably used Burp, and you’re probably aware of Burp Collaborator, the out of band detection feature. Basically, it gives you a (sub)domain name and tells you if there has been a DNS/HTTP/STMP lookup/request for it. This allows you to test for blind command injections, blind xss, SSRFs etc. Now, the problem is, if you use Burp’s built in collaborator server, you’ll lose your ability to see interactions if you close Burp. There are some workarounds for this, but they’re mostly cumbersome. Alternatively, I’ll just use the web version of interactsh for quick testing.

These all have a lot of drawbacks, though. Chiefly is that egress from internal networks often blocks traffic related to these beacons. So, you could be getting an interaction, but you have no idea. And that means lost money, and in the case of the interactions we are testing for, they’re usual High or Critical-risk vulns we get paid well for.

But also, if you’re using a third-party service, you’re exporting some very sensitive information to a third-party if you discover a vulnerability. A site like XSS Report will now have access to all your bXSS interaction including URLs, cookies, DOM, etc. That is not a good thing.

There is also limited customization, which is a must for long-term persistence, testing, and engagements.

What Do I Do?

I roll my own OOB server. This allows me to bypass egress filters, create specific client IDs and test IDs to identify the exact spot an injection succeeded on a mass scale. My server supports DNS lookups, HTTP(S) requests, and blind XSS. But not only that. I’ve also set it up to serve files and monitor remote (JS mostly) files for changes. Additionally, I’ve setup a second network interface on the device that I use for a proxy, and I rotate the IP of the interface via an automated script on a regular basis.

The backend server(s) is/are written in Golang. The frontend, which I run locally, is React. There is a bit of setup e.g. setting up your own server to be the authoritative name server for your test domain, but the end result is very impressive. It enables seamless testing and POC hosting and allows me to track interactions on a long-term basis. I’ve received callbacks months later and then not remembered where they were from. This fixes that.

Anyway, here are some screenshots.

dashboard

clients

testIDs

callbacks

files

This post is licensed under CC BY 4.0 by the author.