Génération de shellcode côté client : un vrai threat model

génération locale navigateur, limites de confiance WASM, risque presse-papiers, profils séparés et preuves d'audit 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 à croire que le côté client empêche toute fuite alors que les extensions, agents endpoint et captures d'écran existent encore. 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.

shasum -a 256 payload.bin

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 des octets de payload dans des logs partagés, des hashes de retest incohérents, ou une bonne architecture ruinée par les habitudes opérateur. 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.