Upgrader un reverse shell, c'est surtout reprendre le contrôle du terminal
Un upgrade de reverse shell corrige PTY, signaux, édition de ligne et job control. Pas besoin d'en faire un numéro de magie.
Le premier reverse shell qui revient est souvent brutal. Les commandes passent, mais le terminal sonne faux. Ctrl-C tue le mauvais processus. Les flèches affichent des caractères bizarres. sudo demande un mot de passe puis se bloque. vim, top ou less se comportent comme si le terminal avait été monté de travers.
Ce n'est pas forcément un problème de payload. C'est un problème de terminal.
Le PTY change presque tout
Un socket brut relié à /bin/sh ne ressemble pas à une session interactive. Il manque un pseudo-terminal, du job control, une taille de terminal correcte et une gestion propre des signaux. Dans un lab autorisé, upgrader le shell sert surtout à rendre la session assez stable pour collecter des preuves sans casser ses propres tests.
Le chemin classique sous Linux utilise Python quand il est disponible :
python3 -c 'import pty; pty.spawn("/bin/bash")'
Ensuite il faut ajuster le mode local et la taille du terminal côté listener. La séquence exacte dépend de l'outil utilisé et du shell obtenu. C'est pour ça que les recettes copiées-collées cassent souvent.
Comprendre la cible avant d'upgrader
Vérifiez d'abord ce qui existe :
which python3 python script socat bash sh
echo $TERM
stty -a
Les conteneurs minimaux n'ont parfois ni Python, ni Bash, ni stty. BusyBox impose d'autres réflexes. Certains environnements empêchent l'allocation d'un PTY. Dans ces cas-là, insister sur un upgrade sophistiqué fait perdre du temps. Un shell limité peut suffire à démontrer l'impact.
La stabilité vaut mieux que la démonstration
Certains traitent l'upgrade comme un passage obligé. Mauvais réflexe. Pendant un assessment, l'objectif n'est pas d'obtenir le terminal le plus confortable possible. L'objectif est de démontrer un risque, éviter les dégâts inutiles et produire une trace compréhensible.
Si la session est instable, documentez-le. Si certaines commandes deviennent risquées via ce canal, arrêtez et utilisez une méthode validée dans le périmètre. Si le listener gère mal l'état du terminal, changez d'outil au lieu de bricoler pendant vingt minutes.
Séparer génération et upgrade
Un générateur ne devrait pas ajouter silencieusement de logique d'upgrade à toutes les payloads. La validation d'un callback et la stabilisation d'une session sont deux étapes différentes.
Générez le plus petit callback qui prouve le chemin. Upgradez seulement quand la connexion existe et que le contexte cible le justifie.