Shellcode reverse TCP : la checklist de lab que j'utilise vraiment
Un workflow reverse TCP concret pour tests autorisés : listener, vérification des octets et pannes réalistes avant intégration.
payloads reverse TCP, préparation du listener, validation LHOST/LPORT, octets sockaddr et fiabilité du callback ne sont pas des sujets abstraits. Ils apparaissent quand un lab autorisé sort de la démo propre et touche un vrai binaire cible, avec un vrai parser, un vrai chemin réseau et un rapport qui sera relu deux mois plus tard.
L'erreur fréquente consiste à ajuster des encodeurs alors que le vrai problème est une sortie réseau bloquée ou un listener attaché à la mauvaise interface. Elle est banale, donc elle survit. Elle ressemble à une hypothèse non vérifiée dans le builder, une valeur reprise de l'interface VPN d'hier, ou une séquence d'octets copiée à travers un outil qui réécrit du texte.
Pourquoi ça compte dans un vrai lab
Le shellcode se joue à l'octet. L'exploit ne sait pas que l'interface avait l'air correcte. Il exécute les octets arrivés en mémoire. Si le payload traverse un shell, un formulaire web, un corps JSON, le scrollback du terminal ou un ticket, le problème n'est plus seulement le payload. C'est le payload plus chaque parser sur le trajet.
Je préfère les contrôles explicites à la confiance : taille attendue, octets interdits, OS cible, architecture, famille de payload, format d'export et hash final. Quand ça casse, les notes doivent réduire la recherche au lieu de créer un nouveau débat.
Un workflow qui résiste aux outils
Start from the smallest thing that proves the primitive. Then add constraints.
nc -lvnp 4444
Cette commande n'est pas tout le workflow. C'est un point d'ancrage. Autour, conserve un blob connu, son SHA-256, et les réglages exacts du builder. Si tu changes LHOST, LPORT, l'ordre des encodeurs, la liste de bad chars ou le format d'export, considère le résultat comme un nouvel artefact.
Pannes à tester
Le motif de panne à surveiller est un callback qui n'arrive jamais, une connexion qui meurt tout de suite, ou un shell qui fonctionne une fois puis disparaît sous SIGPIPE. Teste-le avant l'intégration si possible. Un payload qui échoue dans un harness minimal coûte moins cher qu'un échec bruyant dans un environnement surveillé. Ne saute pas les contrôles de longueur. Les erreurs de taille sont discrètes : le payload ressemble encore à du shellcode, il ne rentre simplement plus dans la primitive disponible.
Ce que les défenseurs doivent voir
Côté défense, le générateur est rarement le signal principal. Le comportement l'est. Cherche les sorties réseau inattendues, parentés de processus étranges, transitions mémoire exécutables, buffers de taille payload et crashs répétés autour du même offset.
Notes de runbook
Stocke la configuration séparément des octets bruts quand la politique l'impose, mais garde assez de détail pour régénérer exactement. Un runbook utile contient la référence de scope, le contexte cible, les contraintes, le hash et une note courte sur le choix de la famille de payload. Pas de magie. Juste moins d'endroits où cacher les erreurs.