Todo CTO acha que sabe quantos hosts públicos a empresa tem. Quase todo CTO está errado. A conta que ele lembra é api.empresa.com.br, app.empresa.com.br, o site institucional e talvez um staging.

A conta real, quando alguém roda o inventário, aparece com 40 a 200 hosts. Landing pages antigas do marketing, ambiente de treinamento que ninguém desligou, subdomínio da campanha do Natal de 2022, VPN legada, painel de gerenciamento de fornecedor terceirizado apontando para IP da empresa.

Esse é um runbook para você mapear tudo em 1 hora, sozinho, com ferramentas gratuitas. Não substitui asset management contínuo — é a foto inicial que revela o susto.

O que você vai precisar

Um Linux (ou WSL/Mac). As ferramentas abaixo:

# Ferramentas de recon (Go)
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
go install -v github.com/projectdiscovery/dnsx/cmd/dnsx@latest

# Amass (mais lento, mais completo)
sudo snap install amass

Se você não tem Go, apt install golang-go no Ubuntu. Total de instalação: ~10 min.

Você também precisa saber quais domínios raiz são da sua empresa. Não confie na memória — vá no whois.br, na Registro.br, no console do seu registrar. Provavelmente tem 2-5 domínios.

Bloco 1 (10 min): descoberta de subdomínios

Passivo primeiro. Não toca no alvo, consulta bases públicas (CT logs, PassiveDNS, VirusTotal, etc.).

# Cria diretório de trabalho
mkdir -p ~/recon/empresa && cd ~/recon/empresa

# Lista de domínios raiz
cat > roots.txt <<EOF
empresa.com.br
empresa.com
empresa.io
EOF

# Subfinder — rápido, agrega várias fontes
subfinder -dL roots.txt -all -recursive -o subs_passive.txt

# Amass passivo — mais fontes, mais lento
amass enum -passive -df roots.txt -o subs_amass.txt

# Junta e deduplica
cat subs_passive.txt subs_amass.txt | sort -u > all_subs.txt
wc -l all_subs.txt

Resultado típico: 30-200 subdomínios para uma empresa de médio porte com 5-10 anos de história.

Antes de fazer qualquer coisa com esse arquivo, olhe com os olhos. Você vai ver coisas como:

• mail.empresa.com.br (esperado)
• smtp-legacy.empresa.com.br (huh?)
• wp-admin.marketing.empresa.com.br (WordPress antigo?)
• dev-01.empresa.com.br, staging.empresa.com.br (ambientes internos expostos)
• terceirizado-x.empresa.com.br (fornecedor com subdomínio na sua zona DNS)

Bloco 2 (10 min): resolução e triagem

Nem todo subdomínio resolve, nem todo resolvido responde HTTP. Filtra:

# Resolve DNS (só o que existe de verdade)
dnsx -l all_subs.txt -a -resp -silent -o resolved.txt

# Extrai só o hostname
awk '{print $1}' resolved.txt > live_hosts.txt

# Testa HTTP/HTTPS
httpx -l live_hosts.txt \
  -status-code -title -tech-detect -web-server \
  -follow-redirects -threads 50 \
  -o http_alive.txt

# Vê o resultado
cat http_alive.txt | head -30

Saída típica:

https://api.empresa.com.br [200] [API v3] [nginx]
https://app.empresa.com.br [200] [Empresa App] [Vercel]
https://dev-01.empresa.com.br [200] [Login] [Apache/2.4.29] [PHP/7.2]
https://old-panel.empresa.com.br [401] [Zabbix] [nginx]
https://blog.empresa.com.br [200] [Blog] [WordPress 5.4]

Nesse ponto você já vai encontrar 3-8 hosts que fazem seu queixo cair. Anote os que aparecem com versão antiga de framework (WordPress 5.4, PHP 7.2, Apache 2.4.29 são todos EOL ou próximos).

Bloco 3 (15 min): scan de vulnerabilidade rápido

Nuclei é um scanner baseado em templates YAML. Base atualizada da comunidade cobre CVE conhecidas e misconfigurations.

# Atualiza templates
nuclei -update-templates

# Scan com severidade alta e crítica primeiro
nuclei -l live_hosts.txt \
  -severity critical,high \
  -rl 30 \
  -o nuclei_high.txt

# Scan de exposição de arquivos comuns
nuclei -l live_hosts.txt \
  -t http/exposures/ \
  -rl 30 \
  -o nuclei_exposures.txt

Achados frequentes em primeira execução:

• .env exposto em /
• .git/config exposto em /
• Painel de admin sem autenticação (Grafana, Prometheus, phpMyAdmin, PgAdmin)
• Swagger/OpenAPI públicos em API que devia ser privada
• Backups .sql, .bak, .zip acessíveis
• Storybook público em produção

Cada um desses é problema real. Nenhum precisou de exploit sofisticado. Só de você não saber que o host existia.

Bloco 4 (10 min): portas e serviços

Muita coisa não responde HTTP mas roda serviço. Redis exposto, MongoDB sem auth, Elasticsearch aberto:

# Extrai IPs únicos dos hosts vivos
cat resolved.txt | awk '{print $NF}' | tr -d '[]' | sort -u > ips.txt

# Scan de portas comuns com naabu (ProjectDiscovery)
naabu -list ips.txt -top-ports 1000 -o open_ports.txt

# Ou nmap se preferir
nmap -iL ips.txt --top-ports 100 -oG nmap_scan.txt

Portas problemáticas típicas de encontrar aberta na internet pública:

• 3306 (MySQL)
• 5432 (PostgreSQL)
• 27017 (MongoDB)
• 6379 (Redis)
• 9200 (Elasticsearch)
• 5984 (CouchDB)
• 8080, 8081 (dashboards diversos)
• 3389 (RDP)
• 5900 (VNC)

Se qualquer uma dessas aparece em IP público seu, é abertura crítica. Feche via security group ou firewall antes de fazer qualquer outra coisa.

Bloco 5 (10 min): cloud storage exposto

Buckets S3, Azure Blob e GCS públicos são o campeão de vazamento de dado no Brasil dos últimos 5 anos. Vale checar padrões óbvios:

# Padrões comuns de nome de bucket
for company in empresa empresabr empresa-prod empresa-staging empresa-backup empresa-uploads empresa-media; do
  for suffix in "" "-br" "-prod" "-dev" "-backup"; do
    name="${company}${suffix}"
    # Testa S3
    aws s3 ls "s3://${name}" --no-sign-request 2>/dev/null && echo "OPEN: $name"
    # Testa via URL pública
    curl -sI "https://${name}.s3.amazonaws.com" | grep -q "200\|403" && echo "EXISTS: $name"
  done
done

Ferramentas específicas: s3scanner, cloudenum, bbot. Mais completas, mas para uma primeira passada, o loop acima já pega os óbvios.

Bloco 6 (5 min): sumário e priorização

Você agora tem cinco arquivos:

• all_subs.txt — inventário bruto
• http_alive.txt — hosts respondendo HTTP
• nuclei_high.txt — vulnerabilidades severity alta/crítica
• nuclei_exposures.txt — arquivos/configs expostos
• open_ports.txt — portas TCP abertas

Junte em uma planilha ou markdown simples. Priorize:

1. Bloqueio imediato (hoje): dados sensíveis expostos, credencial vazada, RCE conhecido, banco na internet.
2. Correção esta semana: painel admin sem MFA, subdomain takeover possível, versão de software com CVE crítico.
3. Backlog do mês: hosts abandonados a desligar, ambiente de treinamento a proteger, WordPress a atualizar.

Uma auditoria de 60 min em SaaS BR médio tipicamente devolve:

• 3-6 achados críticos
• 15-30 achados de severidade alta
• Dezenas de subdomínios abandonados

Nada disso precisou de pentest de R$ 40 mil. Precisou de 1 hora e ferramentas gratuitas.

O que vem depois

Fazer isso uma vez é bom. Fazer sozinho toda semana não funciona — você vai esquecer. É aqui que entra varredura contínua: um scanner externo rodando esse fluxo automaticamente, comparando snapshot com snapshot, alertando quando aparece host novo ou vulnerabilidade nova.

Se está começando a levar segurança a sério, encaixe também o checklist LGPD de 15 pontos e o checklist de MVP LGPD-ready.

---

A Varredura roda todo esse fluxo (asset discovery + nuclei + testes de aplicação) toda semana, sem você precisar rodar comando. Rode agora.