Em CTF, muita gente pula direto para nmap -A, copia a saída e fica esperando que a exploração apareça sozinha. Às vezes funciona. Na maioria das vezes, vira ruído.
Esta aula é o caminho anterior: entender o básico de redes o suficiente para ler uma máquina. A base segue o jeito clássico de redes apresentado em livros como o Kurose: aplicação, transporte, rede, enlace, pacotes, atraso, perda e serviços rodando na borda da rede. Aqui a tradução é prática: o que isso muda quando você recebe um IP na VPN.
No fim, a maior parte do que fazemos em enumeração é responder a uma pergunta simples: qual processo está aceitando conversa nesse alvo?
Um navegador conversando com HTTP, um cliente SSH tentando login, um cliente FTP pedindo listagem, um resolver consultando DNS. São programas trocando mensagens. A rede só transporta essas mensagens em pedaços.
Isso ajuda a parar de pensar em porta como número aleatório. Porta é ponto de entrada para um processo. Se a porta está aberta, algo está escutando. Se algo está escutando, existe um protocolo. Se existe um protocolo, dá para conversar, pedir banner, mandar requisição, errar de propósito e observar a resposta.
Em laboratório, o alvo costuma aparecer como 10.30.0.18, 172.16.1.20 ou algo parecido. Esse endereço não diz “quem” é o alvo. Ele diz para onde o pacote deve ser enviado.
Uma mesma máquina pode ter mais de um IP. Um container pode ter IP em uma rede Docker. Sua máquina pode ter IP no Wi-Fi e outro na VPN. Por isso, quando algo não responde, a primeira pergunta não é “qual exploit eu uso?”. É: eu chego nesse endereço pela interface certa?
Se você está fora da VPN, o alvo privado não existe para você. O pacote nem chega perto dele.
Quando você roda curl http://10.30.0.18, o sistema consulta a tabela de rotas. Ele não “tenta tudo”. Ele escolhe uma interface.
Se a rota para 10.30.0.0/24 aponta para a VPN, o pacote sai pelo túnel. Se não existe rota, ele tenta sair pelo gateway padrão da sua rede normal. Aí o alvo privado não responde.
Esse é um dos bugs mais comuns em laboratório: a pessoa está logada no site, mas não está conectada na VPN certa. O alvo parece morto, mas o problema está do lado do atacante.
ARP aparece pouco em CTF iniciante, mas explica muita coisa quando estamos em redes internas.
Se o destino está na mesma rede local, sua máquina pergunta: “quem tem este IP?”. O host dono responde com o MAC. Se o destino está em outra rede, sua máquina não procura o MAC do destino final. Ela procura o MAC do gateway.
Em VPN e Docker, esse detalhe ajuda a entender por que o alvo pode aparecer como IP privado e ainda assim estar isolado em uma rede controlada.
Porta não é vulnerabilidade. Porta é exposição. O que importa é o serviço por trás dela.
22/tcp open ssh diz que existe SSH. Ainda não diz que você tem credencial. 80/tcp open http diz que há aplicação web. Ainda não diz que tem SQLi. O trabalho de enumeração começa depois do “open”.
Também não confie cegamente na porta padrão. Um HTTP pode rodar em 8080. Um serviço customizado pode usar 31337. O Nmap tenta identificar versão, mas serviço estranho exige interação manual.
TCP tem handshake. Antes de trocar dados, cliente e servidor combinam a conexão. Isso torna o scan mais fácil de interpretar: aberto, fechado, filtrado.
UDP não tem handshake. Se você manda um pacote e nada volta, pode ser porque a porta está filtrada, porque o serviço ficou quieto ou porque o payload não fez sentido. Por isso, UDP demora mais e pede mais contexto.
Para CTF iniciante, comece por TCP. Só vá para UDP quando o enunciado, o scan ou a máquina indicarem algo nessa direção.
Quando você acessa http://10.30.0.18:80, sua máquina abre uma conexão de uma porta local aleatória para 10.30.0.18:80/tcp.
O servidor responde para essa conexão. Esse par de pontas permite que muitas conexões aconteçam ao mesmo tempo sem se misturar.
Em debug, isso importa quando você vê logs do tipo 10.30.0.2:54704. Esse número alto não é porta do serviço. É a porta temporária do cliente.
DNS não é só “internet”. Em CTF web, nome muda comportamento.
Um servidor pode responder uma página genérica quando acessado por IP e outra aplicação quando acessado por domínio. Isso acontece por virtual hosts. O IP é o mesmo, mas o cabeçalho Host muda.
Se o desafio der um domínio interno, adicione no /etc/hosts. Se o Nmap mostrar HTTP e a página parecer vazia, teste robots.txt, código fonte e vhosts antes de concluir que não tem nada.
HTTP é onde enumeração começa a ficar visível. A resposta carrega status code, tamanho, headers, cookies, HTML, JS e comentários.
404 não é sempre inútil. 403 não é sempre bloqueio final. 301 e 302 podem mostrar caminhos. Um robots.txt pode entregar o próximo arquivo. Um HTML simples pode carregar um script com endpoint escondido.
Não use só navegador. Use curl. Ele mostra o que o navegador esconde.
Não precisa decorar o modelo OSI para resolver CTF. Precisa saber separar problemas.
Se ping não responde, pode ser bloqueio de ICMP. Não prova que o host está morto. Se TCP não conecta, pode ser porta fechada, firewall, rota errada ou serviço parado. Se HTTP responde, mas o site está “vazio”, a rede está funcionando; o problema agora é enumeração de aplicação.
Essa separação evita perder tempo no lugar errado.
| Sintoma | Pergunta certa | Teste útil |
|---|---|---|
No route to host | Tenho rota para essa rede? | ip route get IP |
Connection refused | A porta está fechada? | nmap -p PORTA IP |
Connection timed out | Filtro, rota ou serviço mudo? | nmap -Pn -p PORTA IP |
| HTTP 403 | Existe recurso, mas estou bloqueado? | curl -i URL |
O fluxo que funciona bem em CTF é em duas etapas.
Primeiro, ache portas. Depois, aprofunde só nelas. Rodar tudo em todas as portas desde o começo é lento e bagunça a leitura.
Depois do scan, escreva um mapa pequeno. Não precisa bonito. Precisa ser útil.
A diferença entre enumeração e tentativa aleatória é evidência.
Se o FTP aceita anonymous, liste. Se listou arquivos, baixe. Se o arquivo parece backup, leia offline. Se apareceu usuário, procure serviço que aceite usuário. Se apareceu HTTP, veja headers, paths e comportamento. Cada passo precisa ter um motivo.
Esse é o ponto onde esta aula encaixa com a aula de Enumeração e Fuzzing: redes te dizem como chegar e com o que conversar; enumeração web te ajuda a descobrir o que está escondido depois que HTTP aparece.
Quando isso estiver confortável, o próximo passo natural é enumeração específica: web fuzzing, FTP, SMB, SSH, bancos de dados, banners customizados e leitura de arquivos vazados.
A ordem continua a mesma: achar superfície, conversar com o serviço, registrar evidência, escolher o próximo teste.