Subdomain Enumeration com Subfinder e Amass

por União Geek · 4 de maio de 2026

Índice

1 Subdomain Enumeration com Subfinder e Amass

Subdomain Enumeration com Subfinder e Amass

Introdução: No cenário atual de ameaças, descobertas de subdomínios são porta de entrada para vazamentos de dados, subdomain takeover, e movimentos laterais contra infraestruturas críticas. Este artigo detalha, com profundidade técnica e operacional, como usar Subfinder e Amass de forma autorizada para inventariar subdomínios, reduzir superfície de ataque e melhorar detecção. Você aprenderá arquitetura, fluxos, comandos reproduzíveis em Kali Linux, práticas de hardening, playbooks tanto para Red Team quanto para Blue Team, métricas de sucesso e armadilhas comuns a evitar.

Contexto Atual e Relevância Estratégica

O reconhecimento de ativos externos é o primeiro passo em praticamente qualquer campanha de ataque moderna. Em 2024 e 2025, observamos um crescimento significativo na exploração de recursos expostos associados a subdomínios: APIs expostas, endpoints desatualizados, aplicações desativadas e apontamentos DNS negligenciados. Em 2026, com a ampliação do uso de ambientes multi-cloud, pipelines CI/CD automatizados e serviços gerenciados temporários (ex: pages hosting, app platforms), o risco derivado de subdomínios cresceu em diversidade e impacto.

Por que enumerar subdomínios importa para negócios? Para equipes de segurança e risco, um inventário externo de subdomínios fornece insights diretos sobre:

Superfície de ataque exposta ao público – APIs, aplicações web, endpoints de administração.
Possíveis vetores de subdomain takeover para cloud services (ex: S3, Azure Blob, Heroku, GitHub Pages).
Exposição de versões desatualizadas ou endpoints com CVEs conhecidos.
Mapeamento de dependências de terceiros e subcontratadas que apontam para domínios corporativos.

Subdomínios e compliance: reguladores e frameworks (NIST-CSF, ISO-27001, CIS Controls) têm enfatizado a necessidade de inventário de ativos e gestão de vulnerabilidades associadas. Um inventário dinâmico que inclua subdomínios é crucial para: visão de risco, priorização de patching e evidência em auditoria.

Panorama técnico recente: ferramentas como Subfinder (ProjectDiscovery) e Amass (OWASP) consolidaram-se como pilares do reconhecimento de superfície. Em 2024-2025, os vendors de segurança começaram a integrar dados massivos de internet scanning (Shodan, Censys, Rapid7/Project Sonar) com observabilidade de DNS passivo (crt.sh, SecurityTrails, VirusTotal) e fingerprints TLS/HTTP para atribuição de ativos de forma automática. Isso aumentou a eficácia das enumerações, mas também trouxe necessidade de governança forte para evitar uso indevido.

Risco estratégico: subdomain discovery não é apenas etapa técnica; é mapa para risco corporativo. Um atacante que mapeia corretamente subdomínios tem vantagem na economia de ataque: menor tempo para identificar endpoints vulneráveis, maior probabilidade de sucesso em phishing contextualizado, e capacidade de explorar integrações terceiras. Para o defender, isso significa que processos de inventário, monitoração e resposta precisam ser automatizados, auditáveis e alinhados com políticas de autorização.

Ao final desta seção, o leitor deverá entender que enumerar subdomínios com Subfinder e Amass não é um exercício pontual: é uma disciplina de segurança que combina coleta passiva, varredura ativa e validação humana no ciclo contínuo de redução de risco.

Fundamentos Técnicos do Tema

Antes de ir a comandos e playbooks, precisamos alinhar definições e pressupostos técnicos. Subdomain enumeration é a prática de descobrir todos os registros DNS associados a um domínio principal (ex: *.empresa.com). Existem duas grandes estratégias:

Coleta passiva: consulta de fontes públicas sem enviar tráfego diretamente para o alvo – certificados públicos (crt.sh), logs de DNS passivo, feeds de scanners (Shodan, Censys), registries e motores de busca.
Enumeração ativa: envio de queries DNS, bruteforce de nomes, resolução de hosts, e varredura direta de IPs/ports para validar serviços expostos.

Subfinder é uma ferramenta de reconhecimento focada em coleta passiva e algumas integrações ativas por dependência de provedores, criada pelo ProjectDiscovery. Ela agrega resultados de dezenas de fontes: SecurityTrails, VirusTotal, crt.sh, Passive DNS, e outros. Subfinder é rápido e ideal para coleta inicial e contínua com baixo ruído.

Amass (OWASP) é um framework completo para reconhecimento que combina coletores passivos, varredura ativa, bruteforce e mapeamento de relação entre subdomínios. Amass tem módulos para: scraping, passive DNS, enumeration by certificate transparency, bruteforce com wordlists customizáveis, e técnicas para construir grafos de relacionamento entre ativos, incluindo integração com serviços de IP WHOIS e ASN mapping.

Como as ferramentas se complementam: em práticas modernas, usa-se Subfinder para rápido inventário passivo e Amass para aprofundamento, verificação ativa e construção de grafos. Subfinder é menos ruidoso e mais rápido para obtenção de cobertura inicial; Amass faz validação e descoberta por força bruta, revelando subdomínios que não estão em CT logs ou feeds passivos.

Métodos técnicos usados por ambas:

Crawling de certificate transparency logs (crt.sh, Censys) para encontrar CN/SANs.
Consulta a APIs de terceiros (SecurityTrails, DNSDB, VirusTotal) e parsing de respostas.
DNS zone walking e ENUM quando possível (limitações por RFC e servidores configurados).
Bruteforce híbrido: combinação de wordlists, permutations, e feedback das respostas HTTP/SSL para calibrar listas.
Resolução de DNS recursiva com validação de CNAME, A, AAAA, TXT, MX e registros SRV para identificar delegações e apontamentos para serviços de terceiros.

Ruído e risco legal: enumeração ativa pode gerar logs e alertas em sistemas do alvo. Por isso, em avaliações autorizadas, sempre documente escopo, janela de teste e níveis aceitáveis de ruído. Em ambientes corporativos, um programa de autorização prévia (vulnerability disclosure program, pentest authorization) é obrigatório para evitar problemas legais ou interrupção de serviços.

Fingerprinting e validação: encontrar um subdomínio é apenas o começo. Validar se ele está vivo, qual serviço responde, versão do software e presença de headers e certificados é etapa crítica para priorização. Ferramentas complementares: httpx (ProjectDiscovery) para validação HTTP, nuclei para checks rápidos de vulnerabilidade, e nmap para mapeamento de portas quando autorizado.

Integração com pipelines: para operações de segurança contínuas, ambas as ferramentas podem ser integradas a pipelines CI/CD e SIEM/SOAR para processos automáticos de descoberta, notificação e remediação. Um fluxo típico: (1) coleta passiva diária com Subfinder; (2) cross-check com asset inventory; (3) execução semanal de Amass com bruteforce e validação HTTP; (4) ingestão dos novos ativos no CMDB, ticketing para donos de serviço, e geração de testes adicionais (ex: scan de CVEs).

Limitações técnicas: registros privados, DNS resolver internos, e registros de wildcard podem gerar falsos positivos. Wildcards DNS (ex: *.empresa.com apontando para 1.2.3.4) podem inflar resultados e demandam validação de fingerprinting HTTP/TLS para separar hosts legítimos de páginas 404 genéricas. Além disso, CDNs e load-balancers mascaram endereços reais de origem, dificultando atribuição correta.

Entender esses fundamentos é essencial para operar Subfinder e Amass de forma que os resultados sejam úteis, reproduzíveis e integráveis em processos de segurança e auditoria.

Arquitetura, Fluxos e Superfície de Ataque

Subdomain enumeration deve ser pensado como parte de uma arquitetura de reconhecimento e defesa. Nesta seção, descrevo uma arquitetura operacional recomendada, os fluxos de dados, e como a superfície de ataque relacionada a subdomínios se manifesta em ambientes modernos – on-prem, cloud e híbridos.

Arquitetura operativa recomendada:

Collectors Layer – ferramentas passivas (Subfinder), feeds de CT logs, APIs (SecurityTrails, VirusTotal) e scans periódicos (Project Sonar).
Validation Layer – ferramentas de verificação e fingerprinting (httpx, Amass em modo ativo, nmap quando autorizado).
Enrichment Layer – correlacionadores (WHOIS, ASN mapping, TLS certificate analysis, Wappalyzer fingerprints, Shodan/Censys).
CI/CMDB Integration – atualização automática do inventário de ativos, atribuição de dono, nivelamento de risco e início de workflows de remediação.
Monitoring and Detection – alertas em SIEM/UEBA para mudanças nos registros DNS ou aparição de novos certificados, possivelmente integrando honeypots e Canarytokens para detectar abuso.

Fluxos de dados:

O fluxo básico entre as camadas funciona assim: Subfinder coleta dados passivos e gera um conjunto inicial. Amass aprofunda usando bruteforce e resolução ativa para validar e descobrir novos hosts. Os resultados passam por httpx para verificar respostas HTTP/HTTPS e analisar headers e certificados. Em seguida, os dados são enriquecidos com feeds externos (ASN, WHOIS, Shodan) e importados ao CMDB. Se um novo ativo sensível for detectado, acionam-se tickets automáticos para os responsáveis do negócio. Todo evento relevante é logado e encaminhado ao SIEM para correlação com outras ameaças.

Superfície de ataque típica relacionada a subdomínios:

Endpoints expostos: painéis de admin, API endpoints sem autenticação, endpoints de debug.
Subdomain takeover: apontamentos para serviços desalocados em S3, Azure Blob, GitHub Pages, Heroku, Terraform-erro de destruido recurso.
Endpoints com versões vulneráveis: aplicações com CVEs conhecidos, bibliotecas JS vulneráveis e frameworks desatualizados.
Integrações de terceiros: webhook endpoints, callbacks OAuth mal configurados.
Exposição de chaves e tokens via backups públicos e arquivos em subdomínios esquecidos.

Exemplo de vetor de ataque: um subdomínio api-legacy.empresa.com aponta para um bucket S3 que foi removido, porém o registro CNAME ainda aponta para s3-website-us-east-1.amazonaws.com. Um atacante detecta o apontamento pelas listas encontradas por Subfinder e Amass, provisiona um bucket idêntico, resolve o takeover e hospeda conteúdo que rouba cookies de sessão dos usuários ou injeta JS para phishing direcionado. Esse cenário é frequente e pode ser detectado com monitoramento de delegations e interação com serviços de cloud provider quando houver mudança de propriedade de recurso.

Design para minimizar superfície:

Evitar apontamentos públicos a recursos temporários sem automação de cleanup.
Implementar processos de validação de DNS em pipelines IaC (Terraform plan/apply que detecte pointers não resolvidos).
Tagging e inventário de recursos cloud que estejam associados a subdomínios, com alertas de drift.
Políticas de expiração de records e revisão trimestral de registros DNS e certificados TLS.

Observabilidade e detecção: a integração com SIEM deve incluir regras que disparem em eventos como criação de novos certificados para domínios corporativos, alteração de registros NS delegados, CNAMEs para serviços de terceiros e aparição de novos IPs associados a domínios. Exemplo de regra: “alertar se houver um certificado TLS válido para *.empresa.com emitido por CA externa e novo no último dia para um serviço não listado no CMDB”.

Compreender arquitetura e fluxos permite que se transforme dados de enumeração em decisões operacionais: priorização de correção, triagem de incidentes e detecção precoce de atividades de reconhecimento adversário.

Cenários Reais e Estudos de Caso

Estudos de caso reais ajudam a traduzir teoria em prática. Abaixo, reunimos casos públicos relevantes e lições extraídas que moldam as melhores práticas atuais em 2024-2026 para subdomain enumeration e mitigação.

Estudo de Caso 1 – Subdomain Takeover via GitHub Pages (Exemplo público e replicável) – Relato consolidado em 2019 e observações posteriores até 2024:

Descrição: Empresas que removem sites estáticos hospedados em GitHub Pages frequentemente deixam registros CNAME apontando para username.github.io. Bounty hunters e atacantes descobriram múltiplos casos onde usuários maliciosos criaram repositórios com o mesmo nome e reivindicaram o site. Isso permitiu inserção de payloads e phishing. Lição: automatizar verificação de CNAMEs apontando para provedores de hosting que exigem criação de recurso no lado do provedor.

Estudo de Caso 2 – Exposição de API em subdomínio com CVE explorável – Relato público em 2022:

Descrição: Em 2022, um relatório público descreveu uma grande varejista que expôs um endpoint de API legado em api.empresa.com. O endpoint respondia sem autenticação a consultas de dados sensíveis. Pesquisadores descobriram o endpoint através de enumeração passiva usando CT logs e validação com httpx. Resultado: vazamento de dados e multa regulatória leve. Lição: a descoberta post-facto reforça necessidade de gating e controles de acesso estritos para APIs publicadas.

Estudo de Caso 3 – Mudança de infraestrutura cloud e inventário desatualizado – Observações 2023-2025:

Descrição: Durante migração para multi-cloud, uma grande organização não atualizou delegações DNS e deixou CNAMEs para antigos serviços Azure e S3. Em 2023 e 2024, pesquisadores encontraram vários subdomínios apontando para recursos inexistentes, levando a subdomain takeovers e aberturas de phishing. Lição: alinhar pipelines IaC com auditoria DNS e automação de teardown para evitar apontamentos órfãos.

Estudo de Caso 4 – Integração entre Subfinder/Amass e programa de patching – Caso de 2024:

Descrição: Uma organização de médio porte implantou um processo onde Subfinder realizava coleta diária, Amass validava semanalmente e o CMDB era atualizado automaticamente. Em 2024, o processo detectou um subdomínio novo com versão de CMS vulnerável com CVE conhecido. A correção levou a mitigação em 48 horas e evitou exploração. Lição: integração é chave – reconhecimento sem pipeline de correção é apenas relatório.

Estudo de Caso 5 – Erro de terceiros que expôs endpoints sensíveis – 2025 Observações:

Descrição: Em 2025, houve um aumento relatado por firmas de segurança em que subdomínios pertencentes a fornecedores apontavam para endpoints que forneciam callbacks sensíveis para clientes. Atacantes que descobriram subdomínios por meio de amass/subfinder conseguiram construir ataques de abuso via supply chain. Lição: monitoramento de terceiras pontes e contratos que definam acesso e políticas de segurança são essenciais.

Observação: muitos incidentes correlacionados a subdomínios são divulgados em write-ups de bug bounty, blogs técnicos e advisories de fornecedores. Embora nem todos os incidentes listem valores financeiros ou empresas por confidencialidade, a pattern analysis entre 2022-2025 mostra que falhas de inventário e automação são causas recorrentes. Essas lições informam recomendações práticas de detecção e remediação presentadas nas próximas seções.

Implementação Prática Step-by-Step

Esta seção apresenta um fluxo prático, executável e autorizado para realizar subdomain enumeration com Subfinder e Amass em Kali Linux, incluindo comandos, validação de saída, rollback e evidências. Lembre-se: execute apenas em ativos com autorização expressa.

Preparação do ambiente (Kali Linux/Parrot)

sudo apt update && sudo apt install -y git curl jq build-essential
# Instalar Subfinder
GO111MODULE=on go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
# Instalar Amass
sudo snap install amass
# Instalar httpx e nuclei para validação
GO111MODULE=on go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest
GO111MODULE=on go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest

sudo apt update && sudo apt install -y git curl jq build-essential

# Instalar Subfinder

GO111MODULE=on go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

# Instalar Amass

sudo snap install amass

# Instalar httpx e nuclei para validação

GO111MODULE=on go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest

GO111MODULE=on go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest

Validação: verifique as versões instaladas:

subfinder -version
amass -version
httpx -version
nuclei -version

subfinder -version

amass -version

httpx -version

nuclei -version

Configuração de chaves e provedores (Subfinder)

# Arquivo de configuração mkdir -p ~/.config/subfinder nano ~/.config/subfinder/config.yaml # Exemplo de entries: securitytrails: "API_KEY", virustotal: "API_KEY", binaryedge: "API_KEY"
1
2
3
4
5
# Arquivo de configuração
mkdir -p ~/.config/subfinder
nano ~/.config/subfinder/config.yaml
# Exemplo de entries: securitytrails: "API_KEY", virustotal: "API_KEY", binaryedge: "API_KEY"

Validação: rode subfinder com modo passivo e verifique saída:
subfinder -d empresa.com -o subfinder_passive.txt cat subfinder_passive.txt | wc -l
1
2
3
subfinder -d empresa.com -o subfinder_passive.txt
cat subfinder_passive.txt | wc -l
Execução inicial com Subfinder (coleta passiva)

subfinder -d empresa.com -silent -o temp/subfinder_raw.txt # adicionar flag -all para usar todas as fontes configuradas subfinder -d empresa.com -all -silent -o temp/subfinder_all.txt
1
2
3
4
subfinder -d empresa.com -silent -o temp/subfinder_raw.txt
# adicionar flag -all para usar todas as fontes configuradas
subfinder -d empresa.com -all -silent -o temp/subfinder_all.txt

Validação: confira amostras de subdomínios e deduplicate.
sort -u temp/subfinder_all.txt > temp/subfinder_unique.txt head -n 50 temp/subfinder_unique.txt
1
2
3
sort -u temp/subfinder_all.txt > temp/subfinder_unique.txt
head -n 50 temp/subfinder_unique.txt

Deep enumeration com Amass (passivo + ativo)

# modo padrão passivo
amass enum -passive -d empresa.com -o temp/amass_passive.txt
# enumeração completa com bruteforce (pode gerar ruído)
amass enum -d empresa.com -src -ip -brute -w /usr/share/wordlists/dirb/common.txt -o temp/amass_full.txt

# modo padrão passivo

amass enum -passive -d empresa.com -o temp/amass_passive.txt

# enumeração completa com bruteforce (pode gerar ruído)

amass enum -d empresa.com -src -ip -brute -w /usr/share/wordlists/dirb/common.txt -o temp/amass_full.txt

Validação: consolidar resultados:

cat temp/subfinder_unique.txt temp/amass_passive.txt temp/amass_full.txt | sort -u > temp/all_domains.txt
wc -l temp/all_domains.txt

cat temp/subfinder_unique.txt temp/amass_passive.txt temp/amass_full.txt | sort -u > temp/all_domains.txt

wc -l temp/all_domains.txt

Verificação de vida e fingerprinting HTTP/TLS

# valida endpoints HTTP/HTTPS
cat temp/all_domains.txt | httpx -silent -status-code -title -ip -cname -tls-probe -o temp/httpx_results.txt
# extrair hosts que retornaram 200/2xx/3xx
grep -E "200|301|302|403" temp/httpx_results.txt > temp/httpx_alive.txt

# valida endpoints HTTP/HTTPS

cat temp/all_domains.txt | httpx -silent -status-code -title -ip -cname -tls-probe -o temp/httpx_results.txt

# extrair hosts que retornaram 200/2xx/3xx

grep -E "200|301|302|403" temp/httpx_results.txt > temp/httpx_alive.txt

Validação: exemplo de saída:

# cada linha: host | status | title | ip | cname | tls-probe
head -n 20 temp/httpx_alive.txt

head -n 20 temp/httpx_alive.txt

Enriquecimento e priorização

# usar whois, Shodan (se disponível) e crt.sh
while read host; do
  ip=$(echo $host | awk '{print $NF}')
  echo "$host - whois summary" >> temp/enriched.txt
  whois $ip | egrep "OrgName|NetName|Country" >> temp/enriched.txt
done < temp/httpx_alive.txt

# usar whois, Shodan (se disponível) e crt.sh

while read host; do

ip=$(echo $host | awk '{print $NF}')

echo "$host - whois summary" >> temp/enriched.txt

whois $ip | egrep "OrgName|NetName|Country" >> temp/enriched.txt

done < temp/httpx_alive.txt

Validação: analisar top 10 hosts por criticidade e anotar proprietários.

Testes rápidos de vulnerabilidade autorizados

# nuclei templates para testes rápidos (apenas se autorizado) nuclei -l temp/httpx_alive.txt -t cves/ -o temp/nuclei_findings.txt
1
2
3
# nuclei templates para testes rápidos (apenas se autorizado)
nuclei -l temp/httpx_alive.txt -t cves/ -o temp/nuclei_findings.txt

Rollback / Mitigação imediata: se um endpoint crítico for comprometedor, abra ticket de emergência com o dono do ativo e, se necessário, alterar DNS para um redirect de manutenção ou remover apontamento até remediação.
Documentação e evidência
Checklist de evidências: capture screenshots, logs de comandos com timestamp, outputs de whois e httpx, e crie um pacote (zip) com metadados: escopo, autorização, janelas de teste. Exemplo de comando para empacotar evidências:
zip -r evidencias_empresa_com_$(date +%F).zip temp/
1
2
zip -r evidencias_empresa_com_$(date +%F).zip temp/

Esse fluxo cobre a coleta inicial, aprofundamento e validação, além de práticas imediatas de mitigação e evidência. Treine os times para rodar esse pipeline de forma regular e integrar resultados ao inventário corporativo.

Hardening, Controles e Melhores Práticas

Descobrir subdomínios é útil apenas se for seguido por ações de remediação e endurecimento. Aqui estão controles técnicos e processuais para reduzir risco associado a subdomínios descobertos por Subfinder e Amass.

Controles técnicos:

Automação IaC para DNS e cleanup – implementar policies em Terraform/CloudFormation que proíbem apontamentos manuais sem registro no CMDB; incluir validações que impedem criação de CNAMEs para provedores externos sem justificativa.
Discovery-as-Code – rotinas automatizadas que rodam Subfinder/Amass em intervalos e comparam com a baseline no CMDB, gerando tickets para discrepâncias.
Proteção contra subdomain takeover – monitorar apontamentos para provedores (S3, Azure Blob, GitHub Pages, Heroku) e criar processos automáticos para registrar recursos quando necessário; prevenir apontamentos estáticos para serviços temporários.
WAF e Rate Limiting – proteger endpoints com firewall de aplicação e limitar requisições a APIs públicas; bloquear patterns de enumeração agressiva.
Certificados e CT log monitoring – integrar monitoramento de certificate transparency para alertar sobre certificados emitidos para domínios corporativos.
Least Privilege para DNS – controle de acesso a provedores DNS com MFA, logging detalhado e separação de duties.

Controles organizacionais:

Política de autorização para avaliações – processos claros de Request/Approval para tests de pentest, com escopo, janelas, e contingência.
Contrato com fornecedores – cláusulas que obrigam terceiros a notificar alterações DNS que afetem domínios corporativos e a manter inventário compartilhado.
Treinamento e playbooks – times de devops e security devem saber reagir a descoberta de subdomínio crítico: steps, owners, e prioridade.
Auditoria periódica – revisões trimestrais de registros DNS e de certificados com relatórios de conformidade.

Política de triagem – estabeleça critérios para priorizar remediação:

Alta prioridade: subdomínios que retornam 200 com endpoints administrativos, APIs sem auth, ou exposição de dados PII.
Média prioridade: subdomínios com serviços antigos/obsoletos, ou apontamentos para provedores externos com risco de takeover.
Baixa prioridade: hosts que retornam 404 genérico, páginas estáticas não sensíveis.

Ferramentas complementares e integrações:

SIEM (Splunk, ELK/Opensearch, Sumo Logic) para ingestão de alerts de CT e DNS.
SOAR (Cortex XSOAR, Demisto, TheHive playbooks) para automação de tickets e remediação.
Asset Management/CMDB (ServiceNow, Jira Service Management) para atribuição de dono e SLA de remediação.

Essas práticas criam um ciclo de descoberta-remediação contínuo, essencial para reduzir a janela de exposição e o risco associado a subdomínios descobertos.

Playbooks Operacionais para Blue Team e Red Team

Playbooks são scripts operacionais que detalham ações a serem tomadas por equipes em diferentes papéis. Abaixo estão playbooks concisos, mas técnicos, para Blue Team (detecção, contenção e remediação) e Red Team (recon autorizado e verificação de controles).

Playbook Blue Team – Detecção e Resposta

Entrada: alerta de novo certificado para domínio corporativo ou novo subdomínio detectado pelo pipeline.
Step 1 – Triagem automática:
- Correlacionar host com CMDB. Se não encontrado, marcar como novo.
- Executar httpx para validação rápida de response code, headers, TLS.
Step 2 – Classificação de criticidade: usar heurísticas: status code 200 + path /admin ou presença de cookies de sessão = crítico; endpoints API returns JSON = alto.
Step 3 – Contenção imediata: se crítico e sem owner, notificar donos via processo de emergência; aplicar WAF bloqueios por URL/URI; se possível, apontar DNS para página de manutenção temporária via change control aprovado.
Step 4 – Investigação: capturar headers, certs, snapshot do site, logs do SIEM correlative para IPs que acessaram em 24h, consultar WHOIS e ASN.
Step 5 – Remediação: abrir ticket para downtime ou remoção do apontamento, aplicar patch quando aplicável, ou alterar configuração de serviço que permitiu takeover.
Step 6 – Pós-morte: atualizar CMDB, lições aprendidas, e ajustar policy para prevenir reinserção (IaC checks, alerts CT).

Playbook Red Team – Recon Autorizado e Prova de Controle

Entrada: escopo e autorização assinada; janela e limites incluem subdomain enumeration com ferramentas passivas e ativas.
Step 1 – Coleta passiva: executar Subfinder com todas as fontes configuradas; consolidar resultados e documentar fontes para cada host.
Step 2 – Validação ativa segura: executar Amass em modo passivo+ativo com throttle e rate limits; evitar bruteforce fora de janelas autorizadas; anotar times e IPs de origem das queries.
Step 3 – Fingerprinting: usar httpx para capturar status, titles, headers e certs; identificar endpoints sensíveis.
Step 4 – Exploração controlada (se autorizado): executar checks com nuclei para CVEs de alto impacto; apenas PoC não destrutivas e com rollback; documentar efeitos.
Step 5 – Evidence and Reporting: juntar evidências com timestamp, pedir validação do cliente, e propor correções com prioridade e mitigação temporária.

Notas operacionais: para ambos os playbooks, monitore a reputação de IPs que realizam varreduras (evite IPs com blacklist), use proxies se apropriado, e mantenha logs detalhados. Todas as ações devem respeitar acordos de confidencialidade e legalidade.

Métricas, KPIs e Auditoria Técnica

Para medir eficácia do programa de descoberta e remediação, definimos métricas operacionais e KPIs que ajudam a quantificar progresso e identificar gaps.

KPI recomendados:

Time to Discover (TTD) – tempo médio entre publicação/recebimento de um subdomínio novo e sua detecção pelo pipeline (meta: < 24h para passivo, < 72h para ativos).
Time to Remediate (TTR) – tempo médio desde a descoberta até remediação efetiva (meta: < 7 dias para alto impacto).
False Positive Rate – percentual de subdomínios reportados que não exigem ação (meta: reduzir por auto-validation com httpx).
Subdomain Takeover Count – número de takeovers detectados por período (meta: 0 com controles automatizados).
Coverage Rate – porcentagem de subdomínios descobertos que estão no CMDB (meta: 95%+).
Scan Noise Level – eventos gerados por varreduras em SIEM (meta: manter dentro de janela autorizada e reduzir ruído por throttling).

Métricas de qualidade de dados:

Proporção de hosts com metadata enriquecida (ASN, owner, environment).
Porcentagem de subdomínios validados por httpx (ativos vs. passivos).

Auditoria técnica:

Auditorias trimestrais: rodar pipeline completo simulado e comparar com baseline CMDB; gerar relatório com gaps e timeline de correção.
Pen-tests anuais: validar controles de DNS, WAF, e processos de remediação com testadores independentes.
Evidence retention: armazenar resultados de runs com hashes e logs no repositório de auditoria por pelo menos 12 meses.

Métricas para dashboards – visualize TTD, TTR, e Coverage em dashboards SIEM/BI. Alarmes configurados para thresholds críticos e relatórios executivos mensais para CISO.

Erros Comuns, Armadilhas e Correções

Mesmo equipes experientes cometem erros ao executar enumeração de subdomínios. Abaixo relaciono as armadilhas mais comuns e como corrigi-las.

Erro 1 – Executar bruteforce sem autorização

Descrição: ataques de força bruta para subdomínio podem causar tráfego excessivo, trigger de WAF e resultar em interrupção do serviço. Correção: sempre obter escopo explícito e implementar rate-limiting e janelas de execução; usar wordlists calibradas e throttling em Amass.

Erro 2 – Ignorar registros wildcard

Descrição: wildcards inflacionam resultados e causam falso-positivos. Correção: identificar padrões de wildcard (ex: resolve vários subdomínios inexistentes para mesmo IP) e filtrar com validação HTTP/TLS. Ferramentas como httpx podem ajudar a diferenciar entre páginas genéricas e aplicações reais.

Erro 3 – Não validar resultados passivos

Descrição: fontes passivas muitas vezes contêm dados históricos ou incorretos. Correção: validar com resolução DNS ativa e httpx; marcar resultados passivos como “historical” até que verificados.

Erro 4 – Falta de integração com CMDB

Descrição: descoberta sem integração gera relatórios isolados que não resultam em correção. Correção: automatizar ingestão em CMDB, gerar tickets e medir TTR.

Erro 5 – Confundir Ownership

Descrição: resultados de enumeration podem incluir subdomínios de parceiros ou ambientes de teste. Correção: adicionar campo “proveniência” e “owner” no pipeline e validar com WHOIS/ASN e contratos de fornecedores.

Erro 6 – Relatar dados sensíveis sem masking

Descrição: resultados de enumeração podem conter endpoints sensíveis; vazá-los em relatórios sem proteção cria risco. Correção: criptografar pacotes de evidência e aplicar necessidade-de-saber para compartilhamento.

Erro 7 – Falta de monitoramento de CT logs

Descrição: certificados emitidos para domínios corporativos podem indicar que novo subdomínio foi criado. Correção: integrar monitoramento de CT logs como fonte de alerta automatizada.

Evitar essas armadilhas aumenta a qualidade dos resultados e reduz risco operacional durante exames de superfície de ataque.

FAQ Técnico para Busca Orgânica

Esta seção responde dúvidas reais que profissionais buscam sobre Subfinder e Amass, com respostas objetivas e formatadas para snippets.

1. O que é Subfinder e para que serve?

Subfinder é uma ferramenta de reconhecimento passivo que agrupa resultados de múltiplas fontes públicas para descobrir subdomínios de um domínio-alvo. É ideal para coleta inicial com baixo ruído.

2. Quando usar Amass em vez de Subfinder?

Use Amass quando precisar de enumeração profunda, validação ativa e construção de grafos de relacionamento entre ativos; Amass também oferece funcionalidades de brute-force e integração com diversos módulos de enriquecimento.

3. Subfinder e Amass são legais para uso externo?

Ambas as ferramentas são legais, mas seu uso em ativos de terceiros requer autorização. Em avaliações internas, verifique políticas de TI e termos de serviço do provedor DNS e cloud.

4. Como evitar falsos-positivos em resultados?

Valide os resultados com resolução DNS ativa e fingerprinting HTTP/TLS (ex: httpx), filtre registros wildcard e compare com a baseline do CMDB.

5. Qual a diferença entre coleta passiva e ativa?

Coleta passiva consulta fontes públicas sem tocar o servidor alvo; coleta ativa envia queries DNS/HTTP diretamente ao alvo, gerando tráfego que pode ser detectado.

6. Como detectar subdomain takeover?

Procure CNAMEs apontando para serviços gerenciados sem recurso correspondente (ex: apontamento para um bucket inexistente). Automatize validação e monitore serviços externos com alerts.

7. Posso integrar Subfinder/Amass com SIEM?

Sim. Exporte resultados em JSON/CSV e injete no SIEM para correlação com logs, ou use webhooks e SOAR para automação de tickets.

8. Quais bibliotecas/wordlists são recomendadas para bruteforce?

Use wordlists atualizadas e calibreadas como SecLists e listas customizadas que reflitam convenções internas. Evite listas gigantes sem priorização para não gerar ruído.

9. Como priorizar subdomínios achados?

Priorize por exposição (HTTP 200/2xx), presença de endpoints administrativos, dados sensíveis retornados e relação com ambientes de produção. Use regras em nuclei para identificar CVEs relevantes.

10. Quantas vezes devo rodar enumeração?

Recomenda-se coleta passiva diária e uma rodada completa com validação ativa semanal; ajuste frequência conforme mudanças na organização ou risco de negócio.

11. Como documentar autorização para pentest?

Mantenha um documento assinado (scope authorization) com escopo, datas, endereços IPs permitidos, limites e contatos de emergência. Inclua requisitos de evidência e cláusulas legais.

12. Subfinder ou Amass detectam endpoints internos expostos por erro?

Sim. Se endpoints internos estiverem erroneamente publicados enquanto apontam para DNS público, ferramentas de enumeração poderão detectá-los. Isso evidencia necessidade de revisão de boundary e autenticação.

Considerações Finais

Enumerar subdomínios com Subfinder e Amass é uma disciplina que mistura ciência de dados de internet, engenharia de segurança e processos organizacionais. As ferramentas, por si só, não resolvem o problema: o valor real vem da integração dos resultados com inventário, processos de correção e monitoração contínua. Em 2024-2026, o desafio aumentou: ambientes multi-cloud, infra ephemeral e supply chain complexas ampliam superfície. A resposta é pragmática: automação com governança, detecção com contexto e remediação com SLA.

Minha sugestão prática: comece com um pipeline simples – Subfinder diário + Amass semanal + httpx para validação + integração CMDB. Depois, evolua para automação de remediação e regras de detecção baseadas em CT logs. Com isso, você transforma reconhecimento em vantagem defensiva. Segurança não é um relatório; é uma rotina.

Recursos Visuais Sugeridos

Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.

MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
NIST Cybersecurity Framework – figuras oficiais e referências de controles.
ENISA – relatórios anuais com gráficos e mapas de ameaça.
Kali Linux – documentação oficial com fluxos práticos.
Parrot Security – documentação oficial com arquitetura modular.

Referências

https://github.com/projectdiscovery/subfinder
https://owasp.org/www-project-amass/
https://docs.projectdiscovery.io/
https://crt.sh/
https://securitytrails.com/
https://www.censys.io/
https://www.shodan.io/
https://www.virusbulletin.com/ (para pesquisas sobre CT e segurança TLS)
https://nvd.nist.gov/
https://attack.mitre.org/ (MITRE ATT&CK)
https://www.cisecurity.org/controls/ (CIS Controls)
https://www.iso.org/isoiec-27001-information-security.html
https://docs.rapid7.com/insightvm/project-sonar/
https://snyk.io/blog/ (posts técnicos sobre exposição e dependências)

Abordagem	Risco	Custo Operacional	Esforço	Maturidade Recomendada
Subfinder – Passivo	Baixo (false-positives históricos)	Baixo	Baixo	Inicial a Avançado
Amass – Passivo + Ativo	Moderado (ruído se ativo)	Médio	Médio-Alto	Intermediário a Avançado
Bruteforce de subdomínios	Alto (detectável, pode gerar incidentes)	Médio	Alto	Apenas com autorização
CT logs monitoring	Baixo	Baixo	Baixo	Recomendado
Integração CMDB + SOAR	Baixo	Alto (inicial)	Alto	Organizações maduras


ASCII DIAGRAMA - Fluxo de Enumeração e Remediação

+------------------+       +---------------+       +-----------------+
|  Collectors      |  ---> |  Validator    |  ---> | Enrichment      |
|  (Subfinder, CT) |       |  (Amass,HTTP) |       | (WHOIS, ASN, SI)|
+------------------+       +---------------+       +-----------------+
        |                       |                         |
        v                       v                         v
   Daily runs              Weekly deep scan           CMDB/CM/Soar
        |                       |                         |
        +-----> Ticketing/Automated Remediation <---------+
                         (Change Control, WAF rules)

ASCII DIAGRAMA - Fluxo de Enumeração e Remediação

+------------------+ +---------------+ +-----------------+

| Collectors | ---> | Validator | ---> | Enrichment |

+------------------+ +---------------+ +-----------------+

| | |

v v v

Daily runs Weekly deep scan CMDB/CM/Soar

| | |

+-----> Ticketing/Automated Remediation <---------+

(Change Control, WAF rules)

Cenário prático passo a passo (autorizado): Inventário, detecção, remediação e rollback
Escopo: domínio autorizado empresa.com, janela 02:00-05:00 UTC, IPs de teste 10.0.0.0/24

Comandos (Kali Linux):

# Passivo rápido
subfinder -d empresa.com -all -silent -o runs/empresa_subfinder.txt

# Consolida e remove duplicados
sort -u runs/empresa_subfinder.txt > runs/empresa_unique.txt

# Deep scan com Amass (brute desativado se sem permissão)
amass enum -d empresa.com -passive -o runs/empresa_amass_passive.txt

# Consolidar
cat runs/empresa_unique.txt runs/empresa_amass_passive.txt | sort -u > runs/empresa_all.txt

# Verificar quem está vivo
cat runs/empresa_all.txt | httpx -silent -status-code -title -ip -o runs/empresa_httpx.txt

# Aplicar templates nuclei autorizados
nuclei -l runs/empresa_httpx.txt -t cves/ -o runs/empresa_nuclei.txt

# Passivo rápido

subfinder -d empresa.com -all -silent -o runs/empresa_subfinder.txt

# Consolida e remove duplicados

sort -u runs/empresa_subfinder.txt > runs/empresa_unique.txt

# Deep scan com Amass (brute desativado se sem permissão)

amass enum -d empresa.com -passive -o runs/empresa_amass_passive.txt

# Consolidar

cat runs/empresa_unique.txt runs/empresa_amass_passive.txt | sort -u > runs/empresa_all.txt

# Verificar quem está vivo

cat runs/empresa_all.txt | httpx -silent -status-code -title -ip -o runs/empresa_httpx.txt

# Aplicar templates nuclei autorizados

nuclei -l runs/empresa_httpx.txt -t cves/ -o runs/empresa_nuclei.txt

Validação de saída: revisar runs/empresa_httpx.txt, runs/empresa_nuclei.txt; coletar screenshots via wget/curl e salvar logs com timestamps.
Remediação imediata: se endpoint crítico detectado, abrir Change Request em ITSM, aplicar WAF rules temporárias e coordenação com devteam.
Rollback: se remediação causar regressão, reverter DNS ou deploy via CI/CD para estado anterior e reabrir task com prioridade média; registrar incidente.
Evidência: zip runs com metadados e enviar de forma cifrada ao responsável.

Checklist Blue Team

Confirmar autorização para execução do pipeline
Executar Subfinder diário e consolidar resultados
Executar Amass semanal com validação ativa
Validar hosts com httpx e capturar headers e certificados
Verificar apontamentos para provedores de terceiros e possíveis takeovers
Gerar tickets automáticos para novos hosts não inventoried
Aplicar WAF/Rate Limiting se endpoint crítico aparecer
Atualizar CMDB e métricas (TTD, TTR)
Armazenar evidências criptografadas

Checklist Red Team

Obter autorização assinada com escopo e janelas
Executar Subfinder para levantamento passivo inicial
Executar Amass com throttling e sem brute force sem permissão
Validar resultado com httpx e salvar evidências
Executar checks não destrutivos (nuclei) somente se explicitamente autorizado
Documentar fontes e métodos para cada descoberta
Apresentar PoC e recomendações de remediação

Recursos Visuais Sugeridos

https://github.com/projectdiscovery/subfinder – repositório oficial Subfinder
https://github.com/OWASP/Amass – repositório oficial Amass
https://crt.sh – certificate transparency search
https://securitytrails.com – dados DNS e históricos
https://censys.io – internet-wide scanning and certificates
https://www.shodan.io – internet-connected assets search
https://projectdiscovery.io – documentação e ferramentas complementares (httpx, nuclei)
https://docs.rapid7.com/insightvm/ – dados e scanners massivos (Project Sonar)