Subdomain takeover: o risco dos DNS esquecidos

1. O que é Subdomain Takeover e por que devs devem se importar

Subdomain takeover é um ataque no qual um invasor assume o controle de um subdomínio que não está mais vinculado a um serviço ativo, mas cujo registro DNS ainda existe. O cenário clássico envolve um registro CNAME que aponta para um serviço externo desativado, como um bucket S3 da AWS, uma aplicação no Heroku ou um site no GitHub Pages.

Quando o serviço original é desativado sem remover o registro DNS, o subdomínio fica "órfão". Qualquer pessoa pode registrar aquele recurso externo (por exemplo, criar um bucket S3 com o mesmo nome) e, assim, assumir o controle do subdomínio legítimo.

Os impactos são graves: o invasor pode hospedar páginas de phishing, roubar cookies de sessão, distribuir malware ou realizar ataques de engenharia social usando um domínio aparentemente confiável. Para uma empresa, isso significa perda de reputação, violação de dados e possíveis ações regulatórias.

2. Anatomia de um ataque: como o invasor age

Passo 1: Enumeração de subdomínios

O invasor utiliza ferramentas como Sublist3r, Amass ou subfinder para descobrir subdomínios do alvo.

# Exemplo de enumeração com subfinder
subfinder -d exemplo.com -o subdominios.txt

Passo 2: Identificação de registros DNS órfãos

Com a lista de subdomínios, o invasor verifica quais apontam para serviços externos que não existem mais.

# Verificação manual com dig
dig subdominio.exemplo.com CNAME

# Resposta esperada em caso de vulnerabilidade:
# subdominio.exemplo.com. 300 IN CNAME meusite.s3.amazonaws.com.

Passo 3: Registro do serviço externo

O invasor tenta registrar o recurso no serviço de nuvem. Se o nome estiver disponível, ele o cria e ganha controle sobre o que o subdomínio entrega.

# Exemplo: criar bucket S3 com o mesmo nome do CNAME órfão
aws s3 mb s3://meusite
aws s3 website s3://meusite --index-document index.html
aws s3 cp index.html s3://meusite/

Passo 4: Validação do controle

Após configurar o serviço, o invasor verifica se o conteúdo malicioso está sendo servido no subdomínio legítimo.

# Verificação com curl
curl -I http://subdominio.exemplo.com
# Resposta 200 OK com conteúdo controlado pelo invasor

3. Por que subdomínios ficam órfãos? Causas comuns em projetos reais

Migração de infraestrutura

Equipes trocam de cloud provider ou migram serviços, mas esquecem de atualizar os registros DNS. Um CNAME antigo continua apontando para um serviço que não existe mais.

Descontinuação de serviços de terceiros

CDNs, ferramentas de CI/CD, plataformas de hospedagem estática — todos podem ser desativados sem que o time de desenvolvimento remova os apontamentos DNS.

Deleção sem limpeza

Um desenvolvedor deleta um bucket S3 ou um repositório GitHub Pages, mas ninguém atualiza o DNS. O subdomínio fica órfão imediatamente.

Falta de governança

Times de desenvolvimento não mantêm um inventário atualizado de subdomínios e serviços associados. Sem documentação, registros DNS esquecidos se acumulam.

4. Técnicas de descoberta e exploração (para defesa e teste)

Enumeração passiva e ativa

Ferramentas como dnsrecon e subfinder ajudam a mapear subdomínios. A verificação manual com dig confirma se o registro aponta para um serviço externo.

# Enumeração com dnsrecon
dnsrecon -d exemplo.com -t brt -D wordlist.txt

Verificação de respostas DNS

Subdomínios vulneráveis geralmente retornam respostas como:

# CNAME existente, mas serviço não responde
subdominio.exemplo.com. 300 IN CNAME meusite.herokuapp.com.
# Ao acessar: "No such app" ou "404 Not Found"

Casos especiais: wildcard DNS e registros NS delegados

Wildcard DNS (*.exemplo.com) pode mascarar subdomínios órfãos. Registros NS delegados permitem que um invasor assuma todo um subdomínio ao configurar servidores DNS próprios.

Exemplo prático de confirmação

# 1. Descobrir CNAME
dig app.exemplo.com CNAME
# Resposta: app.exemplo.com. 300 IN CNAME meuapp.s3.amazonaws.com.

# 2. Verificar se o bucket existe
aws s3 ls s3://meuapp
# Erro: "NoSuchBucket" - bucket não existe, subdomínio vulnerável

5. Estratégias de prevenção para equipes de desenvolvimento

Política de inventário contínuo

Documente todos os subdomínios e os serviços aos quais eles apontam. Mantenha essa documentação atualizada em um repositório acessível ao time.

Monitoramento automatizado

Configure scripts ou ferramentas como Detectify ou HackerTarget para verificar periodicamente se registros DNS apontam para serviços ativos.

# Script simples de verificação com dig e curl
for sub in $(cat subdominios.txt); do
  target=$(dig +short $sub CNAME)
  if [ -n "$target" ]; then
    status=$(curl -s -o /dev/null -w "%{http_code}" http://$sub)
    if [ "$status" -eq 404 ] || [ "$status" -eq 0 ]; then
      echo "ALERTA: $sub pode estar vulnerável ($target)"
    fi
  fi
done

Uso de validação de propriedade

Ao configurar serviços externos, utilize registros TXT de verificação. A maioria dos provedores de nuvem permite validar a propriedade do domínio antes de associar recursos.

Remoção imediata de registros DNS

Crie um procedimento obrigatório: antes de desativar qualquer recurso, remova ou atualize o registro DNS correspondente.

6. Mitigação em ambientes críticos e resposta a incidentes

Detecção de takeover em andamento

Monitore o conteúdo servido pelos subdomínios críticos. Mudanças inesperadas no certificado SSL ou no conteúdo HTML podem indicar um takeover.

# Verificar certificado SSL
echo | openssl s_client -connect subdominio.exemplo.com:443 2>/dev/null | openssl x509 -noout -subject -dates

Ações de contenção

Ao detectar um takeover, remova ou altere imediatamente o registro DNS. Configure o subdomínio para apontar para um servidor controlado ou para uma página de erro.

Recuperação

Registre novamente o serviço externo no mesmo nome, se possível. Caso contrário, redirecione o subdomínio para um domínio seguro até que a situação seja normalizada.

Comunicação com provedores de nuvem

Se o invasor registrou o recurso, entre em contato com o provedor (AWS, Heroku, GitHub) para relatar o abuso. Forneça evidências de que o subdomínio pertence à sua organização.

7. Checklist prático de segurança para devs

  • [ ] Antes de deletar recursos, verifique dependências de DNS e remova registros primeiro
  • [ ] Ao criar novos subdomínios, utilize registros TXT de verificação
  • [ ] Nunca aponte subdomínios para serviços que você não controla diretamente
  • [ ] Agende varreduras de subdomínios órfãos a cada sprint
  • [ ] Mantenha um inventário atualizado de todos os subdomínios e serviços associados
  • [ ] Configure alertas para mudanças inesperadas em registros DNS
  • [ ] Teste periodicamente seus próprios subdomínios com ferramentas como subjack ou tko-subs
# Exemplo de verificação com subjack
subjack -d exemplo.com -w wordlist.txt -t 100 -timeout 30 -o resultados.txt

Referências