Elegir el payload reverse shell correcto depende sobre todo del runtime
La elección del payload debe seguir runtime, shell disponible, ruta de egreso, quoting y necesidad de evidencia.
Elegir payload no es una cuestión de gusto. Bash no es mejor que Python. PowerShell no es automáticamente la respuesta porque el sistema sea Windows. El payload correcto es el que encaja con runtime, contexto de ejecución, ruta de red y objetivo de evidencia de la prueba autorizada.
Empieza por restricciones. Después elige comando.
Runtime primero
El payload más limpio no sirve si falta el intérprete. Imágenes Linux mínimas pueden traer solo sh. Hosts Windows suelen tener PowerShell, pero language mode y logging cambian lo que funciona. Payloads PHP dependen de configuración del servidor web y funciones deshabilitadas. One-liners Python asumen que Python existe y está en el path usado por la ejecución.
En un laboratorio donde puedas comprobarlo:
which sh bash python3 python perl php nc ncat socat
En Windows:
$PSVersionTable
Get-Command powershell, pwsh, curl
No deduzcas demasiado solo por el sistema operativo. La deriva de runtime existe.
Egreso gana a elegancia
Un payload elegante apuntando a un puerto bloqueado está muerto. Host y puerto del listener deben salir de lo que el objetivo puede alcanzar, no de lo que queda bonito en una demo. A veces será un puerto alto en laboratorio. A veces un proxy aprobado. A veces las reglas de engagement prohíben ese patrón de callback.
La red manda.
El quoting puede decidir por ti
Si la orden atraviesa JSON, YAML, una URL o un wrapper shell, longitud y escaping importan. Comandos cortos fallan menos. Comandos codificados sobreviven más parsers, pero se revisan peor. Scripts multilínea son cómodos para humanos y malos para rutas frágiles.
La interfaz debería mostrar variantes raw, escapadas y codificadas con etiquetas claras.
La evidencia importa
Si el objetivo es probar ejecución saliente de comandos, un callback mínimo basta. Si el objetivo es probar detección, una orden legible con árbol de procesos claro puede ser mejor que una ofuscada. Si el objetivo es evaluar terminal interactivo, payload y listener se eligen juntos.
Un buen generador no ordena payloads como un ranking. Ayuda a reducir opciones según restricciones reales.