Choisir la bonne payload reverse shell dépend surtout du runtime cible

Choisir une payload n'est pas une affaire de préférence personnelle. Bash n'est pas "meilleur" que Python. PowerShell n'est pas automatiquement la réponse dès qu'on voit Windows. La bonne payload reverse shell est celle qui colle au runtime, au contexte d'exécution, au chemin réseau et à l'objectif de preuve du test autorisé.

Commencez par les contraintes. Ensuite seulement, choisissez la commande.

Le runtime passe en premier

La payload la plus propre ne sert à rien si l'interpréteur manque. Les images Linux minimales n'ont parfois que sh. Les hôtes Windows ont souvent PowerShell, mais le language mode et les logs changent ce qui est réellement utilisable. Les payloads PHP dépendent de la configuration du serveur web et des fonctions désactivées. Les one-liners Python supposent que Python existe et se trouve dans le chemin d'exécution.

Dans un lab où la vérification est autorisée, commencez par :

which sh bash python3 python perl php nc ncat socat

Sur Windows :

$PSVersionTable
Get-Command powershell, pwsh, curl

Ne déduisez pas trop de choses à partir de l'OS seul. La dérive runtime est réelle.

L'egress gagne contre l'élégance

Une payload élégante qui vise un port bloqué est morte. Host et port listener doivent venir de ce que la cible peut joindre, pas de ce qui rend bien dans une démo. Parfois c'est un port TCP haut en lab. Parfois c'est un chemin proxy approuvé. Parfois les règles d'engagement interdisent tout simplement ce type de callback.

Le réseau décide.

Le quoting peut choisir pour vous

Si la commande doit traverser JSON, YAML, une URL ou un wrapper shell, longueur et escaping deviennent des contraintes pratiques. Les commandes courtes cassent moins souvent. Les commandes encodées traversent mieux certains parseurs mais se relisent moins bien. Les scripts multilignes sont confortables pour les humains et mauvais pour les chemins fragiles.

Cette nuance doit apparaître dans l'interface : variantes brutes, échappées et encodées avec des labels clairs.

Le besoin de preuve compte

Si l'objectif est de prouver une exécution de commande sortante, un callback minimal suffit. Si l'objectif est de tester une détection, une commande lisible avec une lignée processus claire peut être meilleure qu'une version obfusquée. Si l'objectif est de valider la qualité de terminal, payload et listener doivent être choisis ensemble.

Un bon générateur ne classe pas les payloads comme un top 10. Il aide à réduire les options selon les contraintes réelles.