Reverse Shell Generator

Principe d’un reverse shell

Un reverse shell est un interpréteur de commandes dont l’entrée et la sortie sont redirigées vers une connexion réseau ouverte par la machine cible vers la machine de l’opérateur. L’opérateur lance d’abord un listener, un programme qui attend la connexion sur un port donné. Quand le payload s’exécute sur la cible, il se connecte à ce listener, et chaque commande tapée côté opérateur s’exécute sur la cible.

Ce sens de connexion a une raison pratique. La plupart des pare-feu filtrent strictement les connexions entrantes et laissent passer le trafic sortant. Sur un port courant comme 443 ou 53, le reverse shell emprunte un flux que le réseau autorise déjà.

Reverse shell et bind shell

Avec un bind shell, la cible ouvre un port et attend que l’opérateur s’y connecte. La mise en place est simple, mais le port doit être joignable depuis l’extérieur, ce qui est rare derrière un NAT ou un pare-feu entrant. Le reverse shell inverse le sens de la connexion et contourne ce problème. En contrepartie, l’opérateur doit exposer une IP et un port joignables depuis la cible, et le filtrage sortant de la cible doit laisser passer la connexion.

Stabiliser le shell obtenu

Un reverse shell brut n’a ni complétion ni historique, Ctrl+C coupe la session, et les programmes interactifs comme ssh, su ou vim se comportent mal. On le stabilise en lui attachant un pseudo-terminal (PTY). Sous Linux, la séquence habituelle commence par python3 -c 'import pty; pty.spawn("/bin/bash")' ou script -qc /bin/bash /dev/null. On suspend ensuite le shell avec Ctrl+Z, on passe son propre terminal en mode brut avec stty raw -echo; fg, puis on exporte TERM=xterm-256color et on règle la taille avec stty rows 38 cols 116 (valeurs à reprendre de stty size sur votre terminal). socat et pwncat-cs font cette bascule automatiquement.

Détecter et prévenir les reverse shells

Côté défense, un reverse shell signale presque toujours une compromission déjà réussie : une injection de commande, un upload de fichier ou un service vulnérable a permis d’exécuter du code. Deux leviers s’appliquent : empêcher la connexion de sortir, et repérer le comportement quand il se produit.

Filtrage sortant et durcissement

Le filtrage sortant (egress) est la mesure la plus efficace. Un serveur applicatif a rarement besoin d’ouvrir des connexions arbitraires vers Internet. En limitant les flux sortants aux destinations connues (proxy, dépôts de paquets, API partenaires), on coupe le canal de retour même quand l’exploitation réussit.

Le reste du durcissement réduit les options de l’attaquant. Les services tournent sous des comptes dédiés sans shell interactif, dans des conteneurs au système de fichiers en lecture seule. Sous Windows, AMSI et les règles ASR de Defender bloquent une partie des payloads PowerShell. Sous Linux, retirer de la production les interpréteurs et outils inutiles (compilateurs, nc avec -e, socat) limite les variantes utilisables.

Filiation des processus et télémétrie

Le signal le plus fiable est une filiation de processus anormale. Un serveur web ne lance pas de shell en fonctionnement normal. w3wp.exe qui démarre cmd.exe ou powershell.exe sous IIS, ou httpd, nginx ou java qui démarre bash, sh, python ou nc sous Linux justifient une alerte.

Sous Windows, Sysmon fournit les deux événements utiles. L’Event ID 1 (création de processus) donne la ligne de commande complète et le processus parent, y compris les arguments -EncodedCommand de PowerShell, qu’il suffit de décoder. L’Event ID 3 (connexion réseau) rattache une connexion sortante au processus qui l’a ouverte. Un powershell.exe ou un binaire Office qui se connecte à une IP externe inconnue est un cas classique.

Sous Linux, auditd journalise les appels execve et connect. Des règles sur ces appels font apparaître l’usage de /dev/tcp, de nc ou d’un interpréteur avec redirection des descripteurs 0, 1 et 2. La création d’une FIFO avec mkfifo dans /tmp juste avant une connexion sortante correspond à la variante netcat la plus courante.

Pris un par un, ces indicateurs restent faibles. La détection devient fiable quand on corrèle la filiation du processus, sa ligne de commande et la connexion réseau qu’il ouvre, sur la même machine et dans la même fenêtre de temps.