OutBandit: Investigating Out-of-Band Application Behaviour

What OutBandit is and why I built it

I built OutBandit to help with out-of-band testing in Burp Suite. Some application behavior never appears in the response to my request. An application might resolve a hostname, fetch a resource, or process a value asynchronously. A callback can make that behavior visible.

OutBandit is a Java extension for Burp Suite. My original release describes testing across Windows and Linux applications, including applications written in Python, Java, .NET, PHP, and Node.js. That describes the intended range of tests, rather than a promise that every application or injection context is supported.

The important distinction is between an interaction and an exploit. An unexpected DNS lookup is worth investigating. It does not, by itself, prove command execution or data theft.

Install and setup

I distribute the extension through the OutBandit releases page. The repository links the original installation and usage notes.

For a repeatable setup, I record the release, Burp version, and extension load messages. I load the release JAR through Burp's extension interface using the Java extension type. Interface labels can vary by Burp version.

Before testing an application, I need a callback destination that the test environment can reach. An intranet application may not be able to reach a public collector. Conversely, using an internal collector requires a DNS and network path that the application can actually use.

I check that path with a harmless baseline interaction before interpreting a missing callback as a negative result.

What I use callback tests to investigate

The original release lists several test families:

These categories need different payloads and different evidence. SMTP is a protocol, not a vulnerability category by itself. An open redirect can cause a browser callback without any server-side execution.

Basic usage

My workflow starts with an ordinary request that the application accepts. I identify one input and one hypothesis before adding a callback marker.

1. Capture the baseline request and response in Burp.
2. Select a test appropriate to that input's expected parser or interpreter.
3. Give the attempt a unique, non-sensitive identifier.
4. Send one test request and record its time.
5. Review the collector for a matching HTTP or DNS interaction.
6. Repeat with a control that should not trigger the suspected behavior.

I keep the first proof small. A unique marker is usually enough to establish a correlation. I do not need to send application secrets to a collector to show that an interaction occurred.

A real example needs both sides

For the original demonstration, the useful evidence would be the request I changed and the interaction that followed it. Those details were missing from the old article.

When documenting that result, I record the destination, interaction type, and source visible to the collector. A DNS source can be a recursive resolver rather than the application host. An HTTP source can belong to a proxy or an inspection service.

I also check whether Burp, a browser, a mail gateway, or another tool could have followed the supplied value. A callback that arrives after a test is a correlation to explain, not an automatic attribution to the vulnerable code path.

Tips and gotchas

Asynchronous processing can delay callbacks. DNS caching can reduce repeated lookups. Egress filtering can block a valid test. A protocol mismatch can make the collector look broken even when the application attempted a connection.

I give each attempt a fresh identifier and keep the observation window with the request. That makes retries and delayed events easier to separate.

Detection and defence

For defenders, I correlate application activity with DNS and outbound connection logs. I investigate why a request-controlled value became a network destination and which service account initiated the action.

The fix belongs at that boundary: remove unsafe evaluation, constrain parser behavior, and limit outbound access to what the application needs. Filtering a callback domain can contain a test without correcting the underlying flaw.

I want the final evidence to answer one narrow question clearly: which application behavior caused this interaction, and can I reproduce it with a harmless marker?