Reverse shells dans les conteneurs : le namespace réseau est le piège

Les conteneurs rendent les tests reverse shell plus étranges qu'ils n'en ont l'air. Le processus ressemble à Linux, mais réseau, filesystem, outils, privilèges et identité sont tous placés dans un contexte limité. Si vous oubliez ça, vous déboguez la mauvaise machine.

Le shell arrive dans un namespace, pas dans votre représentation mentale de l'hôte.

Les images minimales ont peu d'outils

Beaucoup d'images de production n'incluent ni Bash, ni Python, ni netcat, ni curl, parfois même aucun package manager. C'est une bonne pratique. C'est aussi la raison pour laquelle des payloads copiées depuis une distribution complète échouent immédiatement.

Vérifiez les bases :

ls /bin /usr/bin
cat /etc/os-release
which sh bash python3 nc curl wget

Les images BusyBox demandent d'autres réflexes. Les images distroless peuvent ne fournir aucun shell. Dans un test autorisé, ce résultat est déjà intéressant : le design du workload réduit les options interactives après exécution de code.

L'IP source peut surprendre

Depuis un conteneur, le trafic sortant peut apparaître comme venant du noeud, d'une gateway NAT, d'un sidecar service mesh ou d'un proxy egress. Le listener voit le chemin réseau, pas l'abstraction Kubernetes. NetworkPolicy, DNS policy, service account et sidecars modifient tous ce qu'un callback peut atteindre.

C'est pour ça qu'il faut corréler capture réseau et métadonnées cluster. Un callback depuis une IP de noeud, sans pod ni namespace, vaut peu dans une investigation.

Un shell conteneur n'est pas un accès hôte

Un reverse shell dans un conteneur prouve l'exécution de code dans ce conteneur. Pas une compromission hôte automatique. Les vraies questions portent sur les secrets montés, les permissions du service account, les volumes écrits, les capabilities, les montages hostPath et les chemins réseau accessibles depuis le pod.

Les rapports imprécis surestiment vite l'impact. "Nous avons un shell" ne suffit pas. Quel namespace ? Quel utilisateur ? Quels mounts ? Quelles permissions Kubernetes ? Quels chemins egress ?

L'app doit demander le contexte runtime

Une app reverseshell utile peut pousser l'opérateur à préciser OS, shell disponible, contexte conteneur et chemin listener attendu. Elle n'a pas besoin de devenir un scanner Kubernetes. Elle doit surtout éviter de prétendre que toutes les cibles Linux se ressemblent.

Les conteneurs récompensent les hypothèses précises et punissent les payloads copiées sans réflexion.