Expliquez les reverse shells par rapport aux bind shells et quand vous choisiriez chacun.

Après avoir obtenu l'exécution de code, vous avez besoin d'un canal interactif vers la cible. Les deux modèles classiques diffèrent par quel côté initie la connexion TCP, et ce seul détail décide lequel fonctionne réellement dans les vrais réseaux.

Bind shell

Dans un bind shell, la charge sur la cible ouvre un socket d'écoute sur un port et attend. L'attaquant se connecte ensuite vers ce port pour obtenir un shell.

• Direction : l'attaquant se connecte vers la cible.
• Problème : les connexions entrantes vers la cible sont généralement bloquées par les pare-feux de périmètre et le NAT. Une victime derrière un NAT n'est typiquement pas du tout joignable depuis Internet, et les ports entrants sont la première chose que les pare-feux suppriment.
• Les bind shells sont surtout utiles sur un réseau interne plat où vous avez déjà une accessibilité directe.

Reverse shell

Dans un reverse shell, l'attaquant lance un écouteur, et la charge sur la cible établit une connexion sortante vers lui.

• Direction : la cible se connecte vers l'extérieur vers l'attaquant.
• Avantage : le trafic sortant est bien plus permissif. La plupart des réseaux laissent les hôtes établir des connexions sortantes (surtout sur 80/443), et le NAT gère automatiquement le chemin de retour. C'est pourquoi les reverse shells sont le défaut dans les vrais engagements.
• Pour se fondre dans la masse, les testeurs font souvent transiter le rappel par des ports courants et l'enveloppent même dans du TLS.

Le hic : le filtrage d'égress

Un réseau mature restreint aussi le trafic sortant. Si seul le trafic web par proxy est autorisé à sortir, un reverse shell naïf vers le port 4444 meurt. Les testeurs s'adaptent en rappelant via 443, en tunnelant à travers le proxy, ou en utilisant des canaux C2 DNS/ICMP/HTTPS.

Ce que recherchent les recruteurs

Que vous énonciez correctement qui initie la connexion, que vous optiez par défaut pour les reverse shells à cause des pare-feux et du NAT, et que vous compreniez le filtrage d'égress comme la contrainte du monde réel — points bonus pour avoir mentionné la stabilisation du TTY et le fait de se fondre dans le 443.