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:

• Reduz tempo perdido: você ataca apenas o que existe e é alcançável.
• Aumenta a cobertura: descobre ativos esquecidos (subdomínios, ambientes de teste, painéis administrativos).
• Melhora o relatório: documenta a superfície de ataque real, não suposições.

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:

• Registros WHOIS e DNS públicos.
• Mecanismos de busca (Google, Bing) com operadores avançados (Google Dorking).
• Repositórios de código público (GitHub, GitLab).
• Vazamentos de credenciais e bancos de dados expostos.
• Certificados TLS publicados em Certificate Transparency logs.
• Serviços de motor de busca de dispositivos (Shodan, Censys) que indexam a internet exposta.

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:

• Pessoas: nomes, cargos, e-mails e padrões de nomenclatura (nome.sobrenome@empresa.com).
• Tecnologias: stack usada pela empresa (vagas de emprego revelam muito).
• Infraestrutura: faixas de IP, provedores de nuvem, subdomínios.
• Documentos: PDFs e planilhas indexados que vazam metadados.

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:

• site: restringe a um domínio ou subdomínio.
• inurl: busca um termo dentro da URL (útil para admin, login, api).
• intitle: busca no título da página.
• filetype: / ext: filtra por extensão (sql, bak, log, env, xls).
• - exclui termos (site:empresa.com -www para fugir do site principal).

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:

• Consulta direta: registros A, AAAA, MX, TXT, NS.
• Tentativa de transferência de zona (AXFR), que em servidores mal configurados despeja toda a zona.
• Força bruta de subdomínios com listas de palavras.
• Certificate Transparency, onde certificados emitidos revelam nomes de host.

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:

• Quais portas estão abertas?
• Qual software e versão atende cada porta?
• Há banners reveladores (servidor web, versão de SSH, sistema operacional)?

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:

• Estrutura de diretórios e endpoints (força bruta de paths).
• Tecnologias de frontend e backend (frameworks, versões de CMS).
• Parâmetros e formulários que recebem entrada do usuário.
• APIs e suas rotas.

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:

• Buckets de armazenamento com nomes previsíveis (empresa-backups, empresa-prod) podem estar públicos.
• Registros DNS apontando para serviços de nuvem revelam o provedor.
• Certificados e cabeçalhos denunciam CDNs e balanceadores.

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:

• Mantenha um diretório por alvo, com subpastas para DNS, hosts, web e OSINT.
• Salve a saída bruta das ferramentas (você vai querer revisitar).
• Use uma planilha ou banco simples para rastrear host → porta → serviço → versão.
• Marque achados promissores para a fase de análise de vulnerabilidades.

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:

• Pular o passivo e ir direto ao scan agressivo: você queima furtividade e perde achados que só aparecem em fontes públicas.
• Sair do escopo sem perceber: um subdomínio que resolve para um IP de terceiro (CDN, SaaS) não está autorizado só porque carrega a marca. Confirme a propriedade do IP antes de tocar.
• Não salvar a saída bruta: refazer um scan de -p- em uma rede grande custa horas.
• Confiar em uma única fonte: subdomínios encontrados por força bruta e por Certificate Transparency raramente coincidem 100%. Combine.
• Ignorar o fator humano: a parte de OSINT sobre pessoas costuma ser o caminho mais curto para o objetivo final.

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:

1. OSINT inicial: identifique a organização, faixas de IP registradas (WHOIS/ASN), provedores de nuvem e padrões de e-mail. Levante a stack pelas vagas de emprego e pelo perfil técnico público.
2. Enumeração de subdomínios: combine coleta passiva (Certificate Transparency, subfinder) com força bruta, depois resolva e filtre os hosts vivos.
3. Triagem de hosts vivos: faça capturas de tela em massa dos subdomínios web para identificar rapidamente painéis, ambientes de teste e telas de login interessantes.
4. Scanning: rode o Nmap nos hosts no escopo para mapear portas, serviços e versões, como detalhado em Scanning com Nmap: descobrindo portas e serviços.
5. Recon web aprofundado: para cada aplicação relevante, faça fingerprinting da stack, descoberta de conteúdo e mapeamento de parâmetros e APIs com um proxy.
6. Consolidação: registre tudo na matriz host → porta → serviço → versão e marque os achados promissores para a análise de vulnerabilidades.

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:

• Plataformas de CTF, que misturam recon com desafios práticos — veja O que é um CTF? Aprenda hacking jogando.
• Laboratórios próprios em máquinas virtuais.
• Programas de bug bounty com escopo claramente definido.

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#

• PTES Team (2014). Penetration Testing Execution Standard. PTES.
• Gordon Fyodor Lyon (2009). Nmap Network Scanning: The Official Nmap Project Guide. Insecure.Com LLC.
• OWASP Foundation (2020). OWASP Web Security Testing Guide v4.2. OWASP.
• Bazzell, M. (2021). Open Source Intelligence Techniques (8th ed.). IntelTechniques.