October 20, 2026
Blind OS Command Injection With Out-of-Band Data Exfiltration
Not just proving a command ran, but reading its output through DNS

By Kaustubh Asthana
4 min read
The last lab in this category used an out-of-band DNS lookup to prove a command had executed, a single ping back to Collaborator was all I needed. This one pushes that idea a step further. Proving execution isn't enough here, the goal is to actually read the output of a command on the server, and the only channel available is still that same DNS lookup. The trick isn't a new vulnerability, it's a smarter payload, one that captures the result of a command and smuggles it out inside the very domain name being resolved.
Building the Baseline
I started the same way I always do, by submitting the feedback form with ordinary values to see the normal flow and capture a clean request in Burp.
The lab description pointed to the email field again as the injection point, so from here it was a matter of building the right payload rather than hunting for where to put it.
Generating the Collaborator Domain
Same as the previous lab, I generated a fresh payload domain from Burp's Collaborator client.
Constructing the Payload
This is the part worth slowing down on, because the previous lab only needed the server to visit a fixed domain. This one needed the server to visit a domain that changes depending on what a command returns, and that's a different kind of payload entirely.
I took the email field and appended the test address, then two pipe characters to chain on a second command regardless of what happened with the first. The second command was an nslookup, but instead of pointing it straight at the Collaborator domain, I gave it a hostname built out of two pieces stitched together. The first piece was a whoami command wrapped in backticks. The second piece, straight after it with no space, was the Collaborator domain itself.
Backticks are a shell feature called command substitution. Anything inside them gets executed first, and the shell replaces the backticked expression with whatever that command printed to standard output, before the rest of the line runs. So whoami wrapped in backticks doesn't get passed to nslookup as literal text, the shell runs whoami, gets back the current user's name, and drops that name directly into the string in its place. What nslookup actually ends up resolving is the Collaborator domain, but now with the output of whoami sitting in front of it as an extra subdomain label.
That's the entire mechanism. The DNS query itself becomes the exfiltration channel. The lookup still has to succeed for Collaborator to log it, which means whatever text got prepended has to be a valid subdomain label, but usernames and most short command output qualify without any extra work.
I closed the payload with two more pipe characters and sent the request.
Reading the Exfiltrated Data
I switched to the Collaborator client and polled it.
The domain Collaborator actually received a lookup for wasn't the one I'd generated, it had a username stitched onto the front of it. That username was the real output of whoami running on the lab's backend, carried out through a DNS query and landing in Collaborator's log where I could just read it off.
Submitting the Answer
This lab wanted that username as proof, so I opened the solution dialog and typed in exactly what Collaborator had captured.
Why This Matters
The previous lab's technique answers one question: did my command run? This one answers a much more dangerous question: what did that command return? Once an attacker can route command output through a channel like DNS, blind injection stops being blind in any meaningful sense. Usernames, file contents, environment variables, anything a shell can echo can, in principle, be chunked into subdomain labels and read back one query at a time. The response body was never part of the equation at any point in this attack.
It's also worth noticing how little the payload itself depends on anything exotic. Command substitution with backticks is basic shell syntax, the only real insight is recognizing that a DNS hostname is just a string the attacker gets to construct, and a string built from live command output is still a valid string, as long as it resolves to something that looks like a legitimate label.
Takeaways From This Lab
- Out-of-band confirmation and out-of-band exfiltration are two different goals built from the same channel, one proves execution, the other reads output.
- Command substitution with backticks lets you run a command and drop its result directly into another command's argument before that argument is evaluated, which is exactly how output ends up riding inside a hostname.
- Collaborator doesn't just tell you that an interaction happened, the interaction's full payload is worth reading closely, since that's where the actual leaked data shows up.