Reconhecimento (recon): a fase mais importante do pentest

Antes de qualquer exploração, o pentester precisa entender o alvo. O reconhecimento (ou recon) é a etapa em que você coleta informações sobre a organização, seus sistemas e sua superfície de ataque. É a fase que mais influencia o resultado de um teste: quanto melhor o mapeamento, mais precisos e eficazes serão os ataques seguintes.

Neste guia, vamos cobrir a diferença entre recon passivo e ativo, técnicas de OSINT, enumeração de serviços, recon de aplicações web e nuvem, e como organizar tudo isso dentro de um processo profissional. Se você está começando, vale ler antes a Metodologia de pentest: as fases de um teste de invasão para entender onde o recon se encaixa.

Por que o recon é a fase mais importante

A maioria dos iniciantes quer pular direto para a exploração. O problema é que exploits não nascem do nada: eles dependem de saber qual software, qual versão e qual configuração está exposta. Sem essa base, você atira no escuro.

O reconhecimento bem feito traz três vantagens diretas:

O Penetration Testing Execution Standard descreve a coleta de inteligência como uma fase própria, anterior à modelagem de ameaças e à análise de vulnerabilidades, justamente porque tudo depende dela (PTES Team, 2014).

Há ainda um efeito menos óbvio: o recon define o orçamento de tempo do engajamento. Um teste de duas semanas com um escopo amplo exige que você priorize. Se você gastar três dias mapeando e descobrir 40 subdomínios, mas só dois deles forem realmente exploráveis, foi o recon que evitou que você desperdiçasse a janela inteira em alvos mortos. Pentest profissional é tanto sobre onde não olhar quanto sobre onde atacar.

O conceito de superfície de ataque

Superfície de ataque é o conjunto de todos os pontos pelos quais um atacante pode tentar entrar ou extrair dados: portas, endpoints HTTP, formulários, APIs, subdomínios, integrações com terceiros, contas de e-mail, repositórios públicos e até funcionários. Cada um desses pontos é um vetor potencial. O objetivo do recon é enumerar essa superfície de forma o mais completa possível — porque o atacante real precisa de apenas uma falha, enquanto o defensor precisa cobrir todas.

Pense na diferença entre superfície conhecida (o site institucional, a API documentada) e superfície desconhecida (o jenkins.empresa.com que o time de infra subiu há dois anos e esqueceu). É essa segunda categoria, a shadow IT, que rende os achados mais valiosos de um pentest.

Recon passivo vs. recon ativo

A distinção fundamental do reconhecimento é o nível de interação com o alvo.

Reconhecimento passivo

No recon passivo, você não toca diretamente na infraestrutura do alvo. Você consulta fontes públicas e terceiros. Isso o torna praticamente indetectável.

Exemplos de fontes passivas:

Reconhecimento ativo

No recon ativo, você interage diretamente com os sistemas do alvo: faz consultas DNS contra os servidores da empresa, envia pacotes para descobrir portas abertas, acessa páginas e APIs. É mais rico em dados, mas também mais ruidoso e detectável.

A transição do passivo para o ativo costuma começar com varredura de portas, que aprofundamos no guia Scanning com Nmap: descobrindo portas e serviços.

Regra de ouro: comece sempre pelo passivo. Quando esgotar o que dá para descobrir sem tocar no alvo, passe ao ativo, ciente de que cada pacote enviado pode ser registrado.

Existe uma zona cinzenta importante: consultar um subdomínio resolvido via DNS público é passivo, mas fazer uma requisição HTTP a esse subdomínio já é ativo, porque seu IP aparece nos logs do servidor de destino. Tenha clareza de onde está a fronteira, pois ela tem implicações tanto de detecção quanto legais.

OSINT: inteligência de fontes abertas

OSINT (Open Source Intelligence) é a disciplina de extrair informação útil de fontes públicas. No pentest, ela alimenta tanto o ataque técnico quanto a engenharia social.

O que buscar em uma fase de OSINT:

Google Dorking na prática

Operadores de busca refinam resultados e revelam páginas que não deveriam estar indexadas:

site:empresa.com.br ext:pdf
site:empresa.com.br inurl:admin
site:empresa.com.br intitle:"index of"
"empresa" filetype:env

Esses dorks podem expor painéis de login, listagens de diretório e arquivos de configuração. Use sempre dentro do escopo autorizado.

Vale conhecer os operadores mais úteis e combiná-los:

A combinação site:empresa.com.br -www inurl:login é um clássico para encontrar painéis secundários. O Google Hacking Database (GHDB), mantido pela Offensive Security, cataloga milhares desses padrões prontos.

Coleta de e-mails e identidades

Descobrir o padrão de e-mail da empresa é estratégico: ele alimenta tanto password spraying quanto campanhas de phishing simuladas. Ferramentas como theHarvester agregam e-mails, subdomínios e nomes a partir de buscadores e fontes públicas:

theHarvester -d empresa.com.br -b google,bing,crtsh

Cruze os e-mails com bases de vazamentos conhecidas para identificar credenciais já comprometidas — sempre dentro do escopo e da legislação aplicável.

Metadados em documentos

Arquivos públicos (PDF, DOCX, XLSX) frequentemente carregam metadados: nome de usuário do autor, versão de software, caminho interno de rede e até o nome da impressora. Esses dados revelam convenções de nomenclatura de contas e a stack de software usada internamente.

# Extrai metadados de um PDF baixado
exiftool relatorio-anual.pdf

Enumeração de DNS e subdomínios

O DNS é uma mina de ouro. A enumeração de subdomínios frequentemente revela ambientes esquecidos como dev.empresa.com, staging.empresa.com ou vpn.empresa.com — alvos com proteção mais fraca que a produção.

Técnicas comuns:

Exemplo de consulta DNS e tentativa de transferência de zona:

# Registros básicos
dig empresa.com.br ANY +noall +answer

# Servidores de nome
dig empresa.com.br NS +short

# Tentativa de transferência de zona (geralmente bloqueada)
dig AXFR empresa.com.br @ns1.empresa.com.br

Quando você encontra uma faixa de subdomínios, cada host vira um novo alvo a enumerar.

Força bruta e fontes passivas combinadas

A enumeração moderna de subdomínios combina duas abordagens. A força bruta testa uma lista de nomes prováveis contra o DNS; a coleta passiva consulta fontes que já catalogaram subdomínios sem tocar no alvo. Ferramentas atuais fazem as duas coisas:

# Coleta passiva a partir de dezenas de fontes
subfinder -d empresa.com.br -silent

# Resolve e filtra apenas os que estão vivos
subfinder -d empresa.com.br -silent | dnsx -silent -a -resp

Os registros TXT merecem atenção especial: eles revelam configurações de SPF, DKIM e DMARC (que listam provedores de e-mail e serviços terceiros autorizados) e, às vezes, validações de domínio de SaaS que entregam quais ferramentas a empresa usa.

Certificate Transparency na prática

Toda autoridade certificadora pública registra os certificados que emite em logs auditáveis. Isso significa que, quando a empresa cria painel-interno.empresa.com e gera um certificado, esse nome vaza publicamente — mesmo que o host nunca apareça no DNS público. Consultar crt.sh é um dos passos passivos mais produtivos:

curl -s "https://crt.sh/?q=%25.empresa.com.br&output=json" \
  | jq -r '.[].name_value' | sort -u

Enumeração de serviços

Depois de saber quais hosts existem, é hora de descobrir quais serviços rodam neles. Essa é a ponte natural entre recon e a fase de varredura.

A enumeração de serviços responde a perguntas como:

A ferramenta padrão para isso é o Nmap, que detecta serviços e versões com a flag -sV. A própria documentação oficial trata a detecção de versão como peça central da enumeração (Lyon, 2009):

nmap -sV -p- alvo.empresa.com.br

Cada serviço identificado abre uma frente: um servidor web leva você a testar a aplicação; um SMB exposto leva à enumeração de compartilhamentos; um banco de dados acessível pode indicar configuração fraca.

Uma boa prática é montar uma matriz de serviços: para cada par host:porta, registre o produto, a versão e a próxima ação de enumeração. Um SMTP aberto pede teste de relay e enumeração de usuários (VRFY); um SNMP em UDP/161 com community string public despeja a topologia inteira de um equipamento de rede; um Redis sem senha em 6379 pode dar leitura/escrita direta.

Recon de aplicações web

Quando o alvo é uma aplicação web, o reconhecimento ganha camadas próprias. Você precisa mapear:

Um proxy de interceptação é indispensável aqui. Ele captura todas as requisições do navegador e revela endpoints ocultos, cabeçalhos e fluxos. Explicamos essa ferramenta no guia Burp Suite: o canivete suíço do pentester web.

Mapear bem os parâmetros é o que torna possível, mais tarde, testar falhas como as demonstradas em Explorando SQL Injection na prática (ético).

Fingerprinting de tecnologias

Identificar a stack reduz drasticamente o espaço de testes. Cabeçalhos de resposta HTTP (Server, X-Powered-By, Set-Cookie), comentários no HTML, caminhos de arquivos estáticos e ícones de favicon revelam frameworks e CMS:

# Cabeçalhos da resposta
curl -sI https://alvo.empresa.com.br

# Identificação automatizada da stack
whatweb https://alvo.empresa.com.br

Saber que o alvo roda um CMS conhecido em uma versão específica permite consultar imediatamente CVEs daquela versão e plugins associados.

Descoberta de conteúdo e diretórios

A força bruta de caminhos revela endpoints não linkados: backups, painéis, arquivos .git expostos e rotas de API. O segredo está em escolher boas wordlists e filtrar pelos códigos de status relevantes:

# Descobre diretórios e arquivos comuns
ffuf -u https://alvo.empresa.com.br/FUZZ \
  -w wordlist.txt -mc 200,204,301,302,401,403

Preste atenção aos 403 (existe, mas proibido) e 401 (existe, exige autenticação): eles confirmam que o recurso está lá, mesmo que você ainda não consiga acessá-lo.

Recon de APIs

APIs modernas (REST e GraphQL) têm sua própria superfície. Procure por arquivos de documentação expostos (/swagger.json, /openapi.json, /api-docs), que listam todos os endpoints, parâmetros e modelos de dados de bandeja. Em GraphQL, a introspection, quando habilitada, entrega o schema inteiro. Mapear a API bem feito conversa diretamente com as defesas descritas em Segurança de APIs: protegendo seus endpoints.

Recon de infraestrutura em nuvem

A maioria das empresas hoje vive em nuvem, e isso muda o mapa. Em vez de um datacenter com IPs fixos, você lida com faixas de provedores, buckets de armazenamento e serviços gerenciados. Pontos de atenção:

Subdomínios apontando para serviços de nuvem desativados abrem espaço para subdomain takeover: se loja.empresa.com aponta via CNAME para um serviço que a empresa não usa mais, um atacante pode reivindicar aquele recurso e servir conteúdo no domínio da vítima. Sempre verifique CNAMEs órfãos durante a enumeração.

Organizando e documentando os achados

Recon gera muitos dados. Sem organização, você perde achados importantes. Boas práticas:

A estrutura sugerida pelo PTES ajuda a transformar coleta solta em inteligência acionável (PTES Team, 2014). Documentar bem também acelera o relatório final, que é o entregável de valor para o cliente.

Uma estrutura de diretórios simples e disciplinada paga dividendos:

alvo-empresa/
├── osint/        # e-mails, vazamentos, metadados
├── dns/          # subdomínios, registros, AXFR
├── hosts/        # saídas de nmap, matriz de serviços
├── web/          # ffuf, whatweb, capturas de tela
└── notas.md      # achados e hipóteses, com timestamp

Registre timestamps em cada ação ativa. Se algo quebrar no ambiente do cliente durante o teste, você precisa poder provar exatamente o que enviou e quando.

Erros comuns no recon

Evitar armadilhas economiza horas e protege sua reputação profissional:

Perguntas frequentes

Recon passivo é sempre legal? A coleta em si costuma ser legal, mas usar os dados para atacar sistemas sem autorização não é. Além disso, acessar bases de vazamento pode ter restrições conforme a jurisdição. Mantenha-se no escopo contratado.

Quanto tempo devo gastar em recon? Depende do engajamento, mas é comum dedicar de 20% a 40% do tempo total. Em alvos grandes, o recon nunca "termina": você revisita conforme novos achados surgem.

Posso automatizar tudo? Boa parte sim, com pipelines que encadeiam coleta de subdomínios, resolução, scan e fingerprinting. Mas a interpretação dos resultados e a escolha do que priorizar continuam sendo trabalho humano.

Qual a diferença entre recon e OSINT? OSINT é um subconjunto do recon, focado em fontes abertas e públicas. O recon engloba também a interação ativa com o alvo (scanning, enumeração de serviços).

Um fluxo de recon do início ao fim

Para amarrar tudo, veja como as fases se encadeiam em um engajamento típico de aplicação web com domínio próprio:

Cada etapa alimenta a seguinte. Um subdomínio descoberto no passo 2 vira alvo de scan no passo 4; um serviço identificado no passo 4 vira foco de enumeração no passo 5. É essa disciplina encadeada que distingue um recon profissional de uma coleta solta de comandos.

Recon contínuo e monitoramento

Em programas de bug bounty e em testes de longa duração, o recon não é um evento único: a superfície de ataque do alvo muda com o tempo. Novos subdomínios sobem, serviços são publicados, versões são atualizadas (e às vezes regredidas). Pesquisadores experientes mantêm pipelines que reexecutam a coleta periodicamente e alertam sobre mudanças — um subdomínio novo que apareceu ontem é, com frequência, o ativo menos testado e mais vulnerável.

Praticando recon de forma legal

Você não deve fazer recon ativo em sistemas sem autorização escrita. Mesmo OSINT passivo, se usado para atacar, é ilegal sem escopo. Felizmente, há ambientes legais para treinar:

Treinar em ambiente controlado constrói o reflexo de sempre começar pelo mapeamento antes de atacar.

Conclusão

O reconhecimento não é uma formalidade: é o alicerce de todo o pentest. Recon passivo evita ruído, OSINT revela o fator humano e técnico, a enumeração de DNS descobre a superfície esquecida e a enumeração de serviços transforma hosts em alvos concretos com versões identificadas. Some a isso o recon de aplicações web e de nuvem, e você terá um mapa fiel da superfície de ataque real. Quanto mais disciplinado for o seu mapeamento — e quanto melhor você documentar cada achado —, mais certeiros serão os passos seguintes e melhor será o relatório entregue. Invista tempo nessa fase; ela paga dividendos em todas as outras.

Referências