Reverse shells en contenedores: el namespace de red es la trampa
Las pruebas reverse shell en contenedores fallan por namespaces, imágenes mínimas, herramientas ausentes y políticas Kubernetes.
Los contenedores hacen que las pruebas reverse shell sean más raras de lo que parecen. El proceso se parece a Linux, pero red, filesystem, herramientas, privilegios e identidad están dentro de un contexto limitado. Si lo olvidas, depuras la máquina equivocada.
La shell aterriza en un namespace, no en tu idea mental del host.
Las imágenes mínimas traen pocas herramientas
Muchas imágenes de producción no incluyen Bash, Python, netcat, curl ni gestor de paquetes. Es buena ingeniería. También significa que payloads copiadas de una distribución completa fallan al instante.
Comprueba lo básico:
ls /bin /usr/bin
cat /etc/os-release
which sh bash python3 nc curl wget
BusyBox necesita otras expectativas. Las imágenes distroless pueden no tener shell. En una prueba autorizada, eso ya es un dato útil: el diseño del workload reduce opciones interactivas después de ejecución de código.
La IP origen puede engañar
Desde un contenedor, el tráfico saliente puede aparecer desde el nodo, una gateway NAT, un sidecar de service mesh o un proxy de egreso. El listener ve el camino de red, no la abstracción del pod. NetworkPolicy, DNS policy, service accounts y sidecars cambian lo que el callback puede alcanzar.
Por eso necesitas captura de red y metadatos del cluster. Un callback desde una IP de nodo sin pod ni namespace sirve de poco en una investigación.
Shell en contenedor no es acceso al host
Un reverse shell dentro de un contenedor prueba ejecución de código en ese contenedor. No prueba compromiso del host por sí mismo. Las preguntas importantes son secretos montados, permisos del service account, volúmenes escribibles, capabilities, hostPath y alcance de red desde el pod.
Los informes flojos exageran rápido. "Tenemos shell" no basta. ¿Qué namespace? ¿Qué usuario? ¿Qué mounts? ¿Qué permisos Kubernetes? ¿Qué rutas de egreso?
La herramienta debe preguntar por runtime
Una app reverseshell puede empujar al operador a indicar sistema operativo, shell disponible, contexto de contenedor y ruta esperada hacia el listener. No necesita ser un scanner Kubernetes. Solo debe dejar de fingir que todo Linux es igual.
Los contenedores premian hipótesis precisas y castigan payloads copiadas sin pensar.