O que é Subdomain Takeover

Subdomain takeover e uma vulnerabilidade que ocorre quando um subdomínio de uma organização aponta, via registro DNS, para um serviço externo que não está mais ativo ou não foi reivindicado. O resultado e que qualquer pessoa pode registrar aquele serviço e passar a controlar o conteúdo veiculado sob o domínio oficial da vitima.

O cenário mais comum e o seguinte: uma empresa cria o subdomínio app.empresa.com e aponta para um recurso na nuvem, como um bucket do Amazon S3, uma página do GitHub Pages, um endpoint do Heroku ou um app do Netlify. Com o tempo, aquele recurso e desativado, mas o registro CNAME no DNS permanece intacto, apontando para um destino inexistente. Um atacante detecta isso, registra o mesmo recurso no provedor e passa a controlar tudo que é servido sob app.empresa.com.

Para o visitante, a URL parece completamente legítima, pois o subdomínio pertence a organização alvo. Esse e o ponto crítico da vulnerabilidade: não ha nenhum sinal visual de que algo está errado.

Como Funciona

O mecanismo e técnico, mas direto. O DNS (Domain Name System) usa registros do tipo CNAME (Canonical Name) para mapear um alias para um nome canonico. Por exemplo:

app.empresa.com.  IN CNAME  empresa.GitHub.io.

Quando o projeto no GitHub Pages e deletado, o registro CNAME ainda existe, mas o destino (empresa.GitHub.io) retorna uma página de erro ou simplesmente não existe mais. Nesse momento, qualquer pessoa pode criar um repositório no GitHub com o mesmo nome (empresa) e habilitar o GitHub Pages, passando a controlar o conteúdo servido em app.empresa.com.

O processo e similar para outros provedores:

  • Amazon S3: bucket deletado mas CNAME ainda aponta para o endpoint do S3. Atacante cria bucket com o mesmo nome na mesma regiao.
  • Heroku: app removido mas DNS ainda aponta para o subdomínio .herokuapp.com. Atacante registra um novo app com o mesmo nome.
  • Azure/Google Cloud: mesma logica para endpoints de App Service, Cloud Run, etc.
  • Zendesk, Freshdesk, Intercom: portais de suporte abandonados cujos subdomínios continuam no DNS.

Alguns provedores exigem verificação de domínio antes de permitir o mapeamento, o que dificulta o takeover. Outros não fazem essa checagem, tornando o ataque trivial.

Quem Foi Afetado

Subdomain takeover e uma das vulnerabilidades mais comuns encontradas em programas de bug bounty. Pesquisadores de segurança relatam dezenas de casos em grandes empresas a cada ano. Organizações de todos os tamanhos são afetadas porque o problema surge naturalmente do ciclo de vida de projetos: recursos são criados para campanhas, testes ou projetos temporarios e depois desativados sem que o DNS seja limpo.

Exemplos documentados publicamente incluem subdomínios de empresas de tecnologia, bancos, varejo e governo. Em varios casos, os atacantes conseguiram servir páginas de phishing convincentes, interceptar cookies de autenticação (quando o domínio está incluído em políticas de cookie muito amplas) e coletar credenciais de usuários que confiaram na URL por ser um subdomínio oficial.

Além do phishing direto, subdomain takeover pode ser usado para contornar políticas de CORS (Cross-Origin Resource Sharing), abusar de tokens de autenticação vinculados ao domínio pai e danificar a reputação da organização junto a provedores de e-mail e listas de reputação.

Como Identificar e Detectar

A detecção de subdomain takeover requer monitoramento continuo do inventario de DNS. Os passos práticos são:

  1. Enumerar subdomínios: use ferramentas como subfinder, amass, assetfinder ou consulte o Certificate Transparency Log (crt.sh) para listar todos os subdomínios conhecidos de um domínio.
  2. Verificar CNAME orfaos: para cada subdomínio, resolva o registro CNAME final e verifique se o destino existe. Um CNAME apontando para um endpoint inexistente e um sinal de alerta.
  3. Checar resposta HTTP: acesse o subdomínio e observe a mensagem de erro. Mensagens como 'There isn\'t a GitHub Pages site here', 'NoSuchBucket', 'No such app' ou '404 Not Found' específicas do provedor indicam vulnerabilidade potencial.
  4. Usar ferramentas especializadas: ferramentas como subjack, subzy e takeover automatizam a verificação cruzando a resposta HTTP com fingerprints conhecidas de mais de 100 provedores.
  5. Monitorar continuamente: o DNS muda com frequência. Um subdomínio seguro hoje pode se tornar vulnerável amanha, quando um serviço e desativado. Monitoramento automatizado e essencial.

O indicador primario de comprometimento (IoC) e um CNAME que resolve para um hostname que não tem entrada DNS válida (NXDOMAIN) ou que aponta para um recurso que retorna uma página de erro caracteristica do provedor.

Como se Proteger e Mitigar

A mitigação envolve tres frentes: remediação imediata, processo de descomissionamento e monitoramento continuo.

Remediação imediata: ao identificar um subdomínio vulnerável, a ação mais rapida e remover o registro DNS. Se o subdomínio ainda e necessário, registre novamente o recurso no provedor antes de qualquer outro agente o faca.

Processo de descomissionamento: toda vez que um recurso externo for desativado (bucket, app, portal de suporte), o registro DNS correspondente deve ser removido no mesmo workflow. Crie um checklist de offboarding que inclua a limpeza de DNS como etapa obrigatória.

Auditoria periodica: execute ferramentas de detecção de subdomain takeover regularmente (semanalmente ou em cada release de infraestrutura). Integre a verificação ao pipeline de CI/CD quando possível.

Políticas de cookies restritivas: evite definir cookies com o atributo Domain=.empresa.com (com ponto na frente), pois isso os compartilha com todos os subdomínios. Prefira definir cookies sem o atributo Domain ou com o hostname exato.

CORS estrito: não use Access-Control-Allow-Origin com wildcards de subdomínio. Liste origens permitidas explicitamente para evitar que um subdomínio comprometido possa fazer requisições autenticadas.

Comparação com Casos e Técnicas Anteriores

Subdomain takeover e conceitualmente similar ao DNS hijacking clássico, mas difere em um ponto fundamental: não requer acesso ao servidor DNS da vitima. O atacante explora uma inconsistencia entre o DNS da vitima e um serviço de terceiros. O DNS da empresa está correto do ponto de vista técnico; o problema e que o destino não existe mais.

Comparado ao typosquatting (registrar um domínio parecido, como empresa-suporte.com), o subdomain takeover e mais perigoso porque o subdomínio atacado pertence de fato a organização. Não ha diferença visual no navegador e nenhuma barra de endereco vermelha.

Historicamente, o problema ganhou visibilidade a partir de 2016 com relatos em programas de bug bounty de empresas como Uber, Twitter e Shopify. Desde então, a maioria dos grandes provedores de nuvem implementou mecanismos de verificação de domínio. Porém, provedores menores, ferramentas de SaaS de nicho e recursos legados frequentemente carecem dessa proteção.

Análise Técnica

Do ponto de vista técnico, a raiz do problema está na separação entre o ciclo de vida do registro DNS e o ciclo de vida do recurso apontado. O DNS e gerenciado por uma equipe (infra, DevOps), enquanto o recurso pode ser criado e destruido por desenvolvedores ou times de produto sem comunicação com quem gerência o DNS.

A fingerprint de cada provedor e fundamental para a detecção automatizada. Por exemplo:

  • GitHub Pages: retorna a mensagem 'There isn\'t a GitHub Pages site here.' com status 404
  • Amazon S3: retorna XML com o código NoSuchBucket, com status 404 ou 403
  • Heroku: retorna a mensagem 'No such app' com status 404
  • Netlify: retorna uma mensagem de Not Found com request ID, com status 404

Ferramentas como subzy mantem uma base de dados de fingerprints atualizada pela comunidade. Para cada subdomínio enumerado, a ferramenta faz uma requisição HTTP e compara o corpo da resposta com as fingerprints conhecidas para determinar se o takeover e possível.

A severidade de um subdomain takeover em programas de bug bounty varia de media a crítica, dependendo da sensibilidade do subdomínio, da presença em políticas de cookies e das possibilidades de abuso de CORS. Subdomínios de autenticação ou pagamento são classificados como críticos.

Impacto e Consequencias

As consequencias de um subdomain takeover variam conforme o uso que o atacante faz do subdomínio comprometido:

  • Phishing: servir uma página de login falsa sob um subdomínio oficial aumenta drasticamente a taxa de sucesso do ataque, pois o domínio e reconhecido e confiável para o usuário.
  • Roubo de cookies: dependendo da política de cookies do domínio pai, o atacante pode receber cookies de sessao enviados pelo navegador da vitima ao acessar o subdomínio.
  • Abuso de CORS: se a API principal aceita requisições de qualquer subdomínio da empresa, o atacante pode usar o subdomínio comprometido para fazer chamadas autenticadas a API.
  • Dano reputacional: qualquer conteúdo malicioso, ofensivo ou enganoso publicado no subdomínio será associado a marca da organização.
  • Impacto em SEO: conteúdo de spam ou malicioso no subdomínio pode contaminar a reputação de domínio nos motores de busca.

Dicas Práticas e Boas Práticas

Para reduzir o risco de subdomain takeover na sua organização:

  • Mantenha um inventario atualizado de todos os subdomínios e seus respectivos destinos
  • Use ferramentas de monitoramento de DNS (como dnstwist, subfinder ou plataformas de ASM - Attack Surface Management) para detectar alterações e subdomínios orfaos
  • Estabeleca um processo formal de offboarding para recursos cloud: ao desativar um serviço, inclua a remoção do registro DNS no ticket ou pull request
  • Não defina cookies com o atributo Domain com ponto na frente (ex: .empresa.com) sem necessidade real
  • Configure CORS de forma granular, listando origens explicitas
  • Participe de programas de bug bounty: pesquisadores frequentemente identificam subdomínios vulneráveis antes dos atacantes
  • Realize varreduras periodicas usando subjack ou subzy com a lista de subdomínios atualizada
  • Documente quem e responsável pelo gerenciamento de DNS e crie um canal claro para reportar subdomínios suspeitos internamente

Conclusao: o que Fazer Agora

Subdomain takeover e uma vulnerabilidade silenciosa: ela não gera alertas, não aparece em logs e não exige sofisticação técnica do atacante. O único requisito e identificar um subdomínio orfao antes que a equipe de segurança o faca.

A boa noticia e que a remediação e simples: remova registros DNS de recursos desativados. O desafio e organizacional, não técnico. Criar um processo que vincule o descomissionamento de recursos ao gerenciamento de DNS e a medida mais eficaz e duradoura.

Se você não tem visibilidade sobre todos os subdomínios da sua organização, comece agora: consulte o Certificate Transparency Log em crt.sh, execute uma enumeração com subfinder ou amass e verifique cada CNAME com subzy. Documente o resultado e repita mensalmente. Esse ciclo simples e suficiente para eliminar a grande maioria dos casos de subdomain takeover antes que sejam explorados.