Tipos de shell y acceso estable

Hay dos formas de recibir una consola. En la directa, el objetivo abre un puerto y espera a que te conectes a él; en la inversa, el objetivo se conecta de vuelta a un puerto que tú dejaste a la escucha. Parece lo mismo, pero casi todas las redes filtran las conexiones que entran desde fuera y dejan salir las que van hacia dentro. Por eso la shell inversa funciona donde la directa no llega: el objetivo iniciando la conexión de salida atraviesa el cortafuegos que habría bloqueado tu conexión de entrada.

En Arrecife, el objetivo está detrás de un filtrado que bloquea conexiones entrantes. La consola que sirve es la que hace que el objetivo se conecte de vuelta a tu estación, no la que te pide conectarte a él.

La primera consola que se obtiene casi nunca es cómoda: no tiene historial, no completa comandos, se corta si pulsas una combinación de teclas y a veces ni te deja usar un editor. Trabajar así es lento y arriesgado —un comando interactivo que se cuelga puede tirar la sesión entera—. Por eso el primer trabajo tras recibir la shell es estabilizarla: convertirla en una consola interactiva de verdad, con control de terminal, para que el resto del engagement no se pierda por un corte tonto.

En Arrecife, la shell inversa llega cruda. Antes de enumerar o escalar, se estabiliza; saltarse ese paso es trabajar sobre una sesión que se cae sola.

El tipo de shell no es casual: se decide al preparar la carga útil, según lo que el objetivo deja pasar y según qué se quiere. Una carga que abre una conexión inversa por un puerto de salida habitual se mezcla con el tráfico normal y atraviesa el filtrado; una que escucha en un puerto nuevo del objetivo choca con el cortafuegos. También importa el peso: una carga que trae todo de golpe es más ruidosa que una ligera que descarga el resto después. Elegir la carga es parte del criterio, no un detalle técnico.

En Arrecife, con un filtrado que solo deja salir ciertos puertos, la carga correcta es la que se conecta de vuelta por uno de esos puertos permitidos. La que escucha en el objetivo no llegaría a tu estación.

Cuando la shell queda estable, la sesión es parte del informe: con qué usuario se abrió, por qué puerto llegó, qué carga se usó. Ese registro permite al cliente entender cómo entró el atacante y reproducir el paso para confirmar que lo cerró. Una captura suelta de una consola abierta no dice nada reproducible; el registro de la sesión —vector, puerto, privilegio— sí. Se anota en el momento, no de memoria al final.

En Arrecife, al estabilizar la shell se apunta el usuario obtenido y el puerto del manejador que la recibió. Es la misma disciplina de la cadena de explotación: el acceso se documenta con sus datos, no con una foto.

El manejador de la estación de ataque es el que recibe la shell inversa, y escucha en un puerto concreto. Abre el laboratorio y lee el registro del manejador que recibió la sesión del objetivo de Arrecife: ahí queda anotado en qué puerto de tu estación quedó a la escucha. Aísla ese puerto.