Choisir un listener reverse shell : netcat suffit, jusqu'au moment où il ne suffit plus

Le listener est la partie la moins spectaculaire d'un reverse shell. C'est aussi l'endroit où beaucoup de tests échouent. On passe dix minutes à choisir une variante de payload, puis on lance le premier nc trouvé sur la machine en supposant que toutes les versions de netcat se ressemblent.

Elles ne se ressemblent pas.

Commencer avec l'outil le plus simple

Pour un callback unique dans un lab autorisé, netcat suffit souvent :

nc -lvnp 4444

Cette commande est utile parce qu'elle ajoute très peu d'incertitude. Si le callback arrive, le chemin réseau, le port et la payload sont cohérents. S'il n'arrive pas, vous pouvez déboguer sans vous demander si un handler plus complexe a masqué l'erreur.

Le piège, c'est la portabilité. OpenBSD netcat, GNU netcat, BusyBox netcat et ncat de Nmap diffèrent sur les options, TLS, les proxys et parfois la gestion de stdin. Quand une doc dit "utilisez nc", elle cache souvent cette réalité.

Ncat comme défaut plus prévisible

ncat devient intéressant quand vous voulez un comportement plus homogène ou du TLS dans un lab qui l'exige explicitement. Ce n'est pas de la furtivité. Ce n'est pas magique. C'est juste moins surprenant.

ncat -lvnp 4444

Pour tester des chemins avec proxy ou segmentation réseau, ncat permet aussi de se rapprocher de certaines contraintes de production. Mais commencez simple. Ajoutez la complexité de transport après avoir prouvé que la route de base fonctionne.

Socat quand le terminal compte

socat est puissant et franchement peu lisible, comme beaucoup de bons outils Unix. Il peut allouer un PTY, régler le mode raw et améliorer des sessions où netcat donne un shell à moitié cassé.

Le coût, c'est l'erreur opérateur. Les commandes socat deviennent longues, et les longues commandes finissent avec une virgule oubliée, une option inversée ou une IP périmée dans les notes. Utilisez-le quand la qualité de session compte. Pas comme premier réflexe.

Ne pas confondre listener et C2

Un listener accepte un callback. Un C2 gère agents, tâches, identité, chiffrement, persistance, logs et workflow opérateur. Ce sont deux problèmes différents. Pour valider un chemin d'exécution dans un lab contrôlé, un framework lourd ajoute parfois plus d'ambiguïté que de valeur.

Le bon workflow reste plat : générer, écouter, observer, documenter, arrêter.