Explica las reverse shells frente a las bind shells y cuándo elegirías cada una.
Respuesta breve
Una bind shell abre un puerto de escucha en el objetivo y espera a que te conectes a él. Una reverse shell hace que el objetivo se conecte hacia fuera a un listener que tú controlas. Las reverse shells suelen ganar porque el tráfico saliente esquiva las reglas de cortafuegos entrantes y el NAT.
Tras conseguir ejecución de código, necesitas un canal interactivo de vuelta al objetivo. Los dos modelos clásicos difieren en qué lado inicia la conexión TCP, y ese único detalle decide cuál funciona de verdad en redes reales.
Bind shell
En una bind shell, la carga en el objetivo abre un socket de escucha en un puerto y espera. El atacante luego se conecta hacia ese puerto para obtener una shell.
- Dirección: el atacante se conecta hacia el objetivo.
- Problema: las conexiones entrantes hacia el objetivo suelen estar bloqueadas por los cortafuegos perimetrales y el NAT. Una víctima detrás de NAT normalmente no es alcanzable desde Internet en absoluto, y los puertos entrantes son lo primero que descartan los cortafuegos.
- Las bind shells son útiles sobre todo en una red interna plana donde ya tienes alcanzabilidad directa.
Reverse shell
En una reverse shell, el atacante ejecuta un listener, y la carga en el objetivo establece una conexión saliente de vuelta a él.
- Dirección: el objetivo se conecta hacia fuera al atacante.
- Ventaja: el tráfico saliente es mucho más permisivo. La mayoría de las redes dejan que los hosts establezcan conexiones salientes (especialmente en 80/443), y el NAT gestiona automáticamente la ruta de retorno. Por eso las reverse shells son la opción por defecto en compromisos reales.
- Para mimetizarse, los testers suelen hacer que el callback circule por puertos comunes e incluso lo envuelven en TLS.
La pega: el filtrado de salida
Una red madura también restringe el tráfico saliente. Si solo se permite salir el tráfico web a través de proxy, una reverse shell ingenua al puerto 4444 muere. Los testers se adaptan llamando de vuelta por el 443, tunelizando a través del proxy o usando canales C2 de DNS/ICMP/HTTPS.
Qué buscan los entrevistadores
Que indiques correctamente quién inicia la conexión, que optes por defecto por las reverse shells a causa de los cortafuegos y el NAT, y que entiendas el filtrado de salida como la restricción del mundo real — puntos extra por mencionar la estabilización del TTY y mimetizarse en el 443.
Posibles preguntas de seguimiento
- ¿Por qué el filtrado de salida a veces sigue rompiendo una reverse shell, y cómo te adaptas?
- ¿Cómo estabilizarías y mejorarías una reverse shell en crudo a un TTY plenamente interactivo?
- ¿Cuál es el mejor punto de detección para un defensor en cada tipo?