Reverse Shells in Containern: der Netzwerk-Namespace ist die Falle

Container machen Reverse-Shell-Tests seltsamer, als sie aussehen. Der Prozess wirkt wie Linux, aber Netzwerk, Dateisystem, Werkzeuge, Privilegien und Identität sind eingeschränkt. Wenn du das vergisst, debugst du die falsche Maschine.

Die Shell landet in einem Namespace, nicht in deinem mentalen Modell des Hosts.

Minimale Images haben minimale Werkzeuge

Viele Produktionsimages enthalten kein Bash, kein Python, kein netcat, kein curl und manchmal keinen Paketmanager. Das ist gutes Engineering. Es bedeutet aber auch, dass Payloads aus vollständigen Distributionen sofort scheitern.

Prüfe die Grundlagen:

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

BusyBox-Images brauchen andere Erwartungen. Distroless-Images haben möglicherweise gar keine Shell. In einem autorisierten Test ist das selbst ein Befund: Das Workload-Design reduziert interaktive Möglichkeiten nach Code Execution.

Die Quell-IP täuscht

Aus einem Container kann ausgehender Traffic als Node, NAT-Gateway, Service-Mesh-Sidecar oder Egress-Proxy erscheinen. Der Listener sieht den Netzwerkpfad, nicht die Pod-Abstraktion. In Kubernetes beeinflussen NetworkPolicy, DNS Policy, Service Accounts und Sidecars, was ein Callback erreichen kann.

Darum gehören Packet Capture und Cluster-Metadaten zusammen. Ein Callback von einer Node-IP ohne Pod und Namespace hilft einem Analysten wenig.

Container-Shell ist kein Host-Zugriff

Eine Reverse Shell im Container beweist Code Execution in diesem Container. Sie beweist nicht automatisch Host-Kompromittierung. Interessant sind gemountete Secrets, Service-Account-Rechte, schreibbare Volumes, Capabilities, hostPath-Mounts und erreichbare Netzwerke.

Schwache Berichte übertreiben hier schnell. "Wir haben eine Shell" reicht nicht. Welcher Namespace? Welcher User? Welche Mounts? Welche Kubernetes-Rechte? Welche Egress-Pfade?

Der Generator sollte Runtime-Kontext abfragen

Eine gute App kann nach OS, vorhandener Shell, Container-Kontext und erwartetem Listener-Pfad fragen. Sie muss kein Kubernetes-Scanner werden. Sie muss nur aufhören, alle Linux-Ziele gleich zu behandeln.

Container belohnen präzise Annahmen und bestrafen kopierte Payloads.

Der Unterschied zeigt sich schnell: Ein sauber beschriebenes Pod-Problem ist ein Befund. Ein "Linux-Shell ging nicht" ist nur eine schlechte Notiz.