O que é Subdomain Takeover

Subdomain takeover e uma classe de vulnerabilidade em que um atacante consegue assumir o controle de um subdomínio legítimo de uma organização porque o registro DNS desse subdomínio aponta para um serviço externo que já não existe ou não está mais sob controle do dono original do domínio.

O cenário mais comum ocorre quando uma empresa cria um registro CNAME apontando para um serviço de nuvem, como GitHub Pages, Heroku, Netlify, AWS S3, Azure App Service ou Fastly, hospeda algo ali por um tempo e depois encerra o serviço sem remover o registro DNS correspondente. O subdomínio fica ativo no DNS, mas o destino não pertence mais a ninguém.

Nesse momento, qualquer pessoa que cadastre uma conta no mesmo serviço e reivindique aquele endpoint passa a controlar o conteúdo servido sob o subdomínio original da empresa. Do ponto de vista do visitante, a URL parece legítima; o certificado TLS pode até ser válido; mas o conteúdo e totalmente controlado pelo atacante.

Como funciona o ataque

O mecanismo técnico e simples. Imagine que blog.empresa.com.br tem o seguinte registro DNS:

blog.empresa.com.br.  300  IN  CNAME  empresa.GitHub.io.

A empresa usou GitHub Pages para hospedar o blog, depois migrou para outro serviço e deletou o repositório. O registro DNS continua apontando para empresa.GitHub.io. Quando alguém acessa blog.empresa.com.br, o DNS resolve para o endpoint do GitHub Pages, mas a página retorna erro 404 porque nenhum repositório reivindica aquele CNAME.

O atacante percebe isso usando ferramentas de reconhecimento DNS, cria uma conta no GitHub e um repositório com o nome correto para satisfazer o CNAME, e passa a servir qualquer conteúdo sob blog.empresa.com.br. O processo inteiro pode ser realizado em menos de dez minutos.

Alguns serviços são mais vulneráveis do que outros. GitHub Pages, Heroku, Fastly, Shopify, Squarespace, HubSpot, Zendesk, AWS S3 (buckets públicos), Azure App Service e Vercel são os mais frequentemente explorados porque permitem que qualquer usuário reivindique um hostname ou bucket específico sem validação adicional de propriedade do domínio.

Quem foi afetado

Subdomain takeover não e uma vulnerabilidade teorica. Varios casos documentados envolvem organizações de grande porte:

Em 2016, Detectify Security pesquisou os top 10.000 sites da Alexa e encontrou centenas de subdomínios vulneráveis. A própria plataforma HackerOne teve subdomínios vulneráveis relatados via bug bounty por pesquisadores. Starbucks, Snapchat e Microsoft tiveram casos documentados publicamente, todos envolvendo registros CNAME para serviços que haviam sido desativados.

O repositório público can-i-take-over-xyz no GitHub catalogou mais de 120 serviços de nuvem com instruções detalhadas sobre como identificar e testar subdomínios vulneráveis para cada um deles. Esse repositório e atualizado pela comunidade de pesquisa de segurança e serve como referência tanto para defensores quanto para atacantes.

O impacto não se limita a grandes empresas. Startups e pequenas empresas que usam multiplos serviços SaaS e não tem processos formais de gerenciamento de DNS são frequentemente mais expostas porque não tem equipe dedicada para auditar registros pendentes.

Como identificar

A identificação de subdomínios vulneráveis passa por tres etapas:

1. Enumeração de subdomínios: ferramentas como subfinder, amass e certificados CT logs (crt.sh) revelam todos os subdomínios registrados para um domínio. Essa etapa não requer acesso especial, apenas consultas DNS e HTTPS públicas.

2. Resolução DNS e verificação de CNAME: para cada subdomínio encontrado, verificar se existe um CNAME dangling, ou seja, um CNAME cujo destino retorna 404, NXDOMAIN ou erro de 'recurso não encontrado' específico do serviço (como a mensagem 'There isn't a GitHub Pages site here' do GitHub).

3. Fingerprint do serviço vulnerável: cada serviço tem mensagens de erro distintas para endpoints não reivindicados. A ferramenta subjack mantem uma lista de fingerprints para mais de 50 serviços. O scanner nuclei tem templates específicos para subdomain takeover no diretório takeovers. O projeto tko-subs automatiza a verificação e permite testar reivindicação real do subdomínio em modo seguro.

Como se proteger

A proteção contra subdomain takeover e essencialmente um problema de higiene de DNS e governanca de serviços. As medidas mais eficazes são:

Auditoria periodica de DNS: revisar todos os registros CNAME, A e ALIAS pelo menos mensalmente. Qualquer CNAME apontando para um endpoint externo que retorne 404 ou não esteja ativo deve ser removido imediatamente.

Processo formal de desativação de serviço: antes de cancelar qualquer serviço SaaS, plataforma de hospedagem ou remover um bucket S3, o primeiro passo deve ser remover o registro DNS correspondente, não o último. A ordem correta e: (1) remover DNS; (2) aguardar TTL expirar; (3) desativar o serviço.

Monitoramento continuo: ferramentas como o TrustSiteMonitor, Detectify e SubdomainRadar monitoram continuamente o DNS e alertam quando um subdomínio passa a retornar respostas suspeitas de takeover. Alertas em tempo real permitem resposta rapida antes que um atacante reivindique o recurso.

CAA records e Certificate Transparency: configurar registros CAA no DNS limita quais autoridades certificadoras podem emitir certificados para o domínio. Monitorar Certificate Transparency logs detecta quando um certificado e emitido para um subdomínio não autorizado, o que pode indicar takeover bem-sucedido.

Comparação com outros ataques de DNS

Subdomain takeover difere de outros ataques DNS por não exigir comprometimento dos servidores autoritativos. Enquanto DNS hijacking modifica registros nos servidores DNS da vitima (exigindo acesso ao painel do registrador ou comprometimento da conta), o subdomain takeover explora um comportamento legítimo: o atacante apenas reivindica um recurso de nuvem que está publicamente disponível para qualquer usuário cadastrado.

DNS cache poisoning injeta respostas falsas nos resolvers recursivos para redirecionar usuários. Subdomain takeover não precisa disso: o DNS responde corretamente, o CNAME resolve para o endpoint certo, e o endpoint agora pertence ao atacante.

Isso torna o subdomain takeover mais fácil de executar e mais difícil de detectar por ferramentas tradicionais de monitoramento DNS que apenas verificam se o registro existe.

Análise técnica

Do ponto de vista técnico, a vulnerabilidade existe em tres categorias de registros DNS:

CNAME dangling: o caso mais comum. O registro CNAME existe e resolve, mas o host de destino retorna erro específico do serviço indicando que o recurso não está reivindicado. Exemplo: GitHub Pages retorna 'There isn't a GitHub Pages site here'; Heroku retorna 'No such app'; AWS S3 retorna 'NoSuchBucket'.

A/ALIAS para IP desalocado: menos comum, ocorre quando um registro A aponta para um IP que foi liberado pelo provedor de nuvem e realocado para outro cliente. Mais difícil de explorar porque exige que o atacante obtenha exatamente aquele IP na nuvem.

NS delegation para zona inexistente: quando um registro NS delega uma zona para servidores que não respondem mais por ela, um atacante pode criar a zona nesses servidores e passar a responder por todos os registros da subzona.

A severidade varia de media a crítica dependendo do uso do subdomínio. Um subdomínio de blog tem impacto reputacional. Um subdomínio de autenticação SSO ou subdomínio que recebe cookies com flag Domain=.empresa.com tem impacto crítico, pois um atacante pode capturar cookies de sessao válidos dos usuários.

Impacto e consequencias

Os impactos potenciais de um subdomain takeover bem-sucedido incluem:

Phishing de alta confianca: a URL parece legítima. Usuários e até filtros de email corporativos tendem a confiar em emails com links para subdomínios conhecidos da empresa.

Roubo de cookies: se o cookie de sessao foi configurado com Domain=.empresa.com sem o atributo SameSite=Strict, um subdomínio comprometido pode receber esses cookies em requisições cross-site, permitindo roubo de sessao.

Contornar CSP e CORS: policies de Content Security Policy e CORS frequentemente incluem *.empresa.com como origem confiável. Um subdomínio tomado pelo atacante herda essa confianca.

Distribuição de malware: o subdomínio pode ser usado para hospedar payloads maliciosos que passam por filtros de reputação de URL porque o domínio pai tem boa reputação.

Dicas práticas e boas práticas

Checklist de segurança para proteção contra subdomain takeover:

  • Executar enumeração completa de subdomínios pelo menos uma vez por mes usando subfinder ou amass.
  • Para cada CNAME encontrado, verificar se o destino está ativo e pertence a organização.
  • Remover imediatamente qualquer CNAME cujo destino retorne erro de recurso não reivindicado.
  • Documentar todos os serviços SaaS ativos e os subdomínios associados a eles em um inventario de ativos.
  • Incluir remoção do registro DNS como primeiro passo no checklist de desativação de qualquer serviço.
  • Configurar alertas de Certificate Transparency para o domínio principal e todos os subdomínios conhecidos.
  • Revisar configurações de Domain= em cookies de sessao; preferir SameSite=Strict ou Lax.
  • Usar um scanner de subdomínio automatizado integrado ao pipeline de CI/CD para detectar novos CNAMEs pendentes antes do deploy.

Conclusao: o que fazer agora

Subdomain takeover e uma das vulnerabilidades mais simples de explorar e uma das mais negligenciadas em programas de segurança corporativa. Não requer conhecimento avancado; requer apenas um atacante paciente e uma organização que não monitore seu DNS.

O primeiro passo e executar hoje mesmo uma enumeração completa dos subdomínios da organização e verificar cada CNAME ativo. Ferramentas gratuitas como subjack e nuclei automatizam essa verificação em minutos. O segundo passo e estabelecer um processo formal para garantir que nenhum serviço seja desativado sem que o registro DNS correspondente seja removido primeiro.

Monitoramento continuo e a camada final de defesa: mesmo organizações com processos maduros cometem erros. Ter um sistema que alerta quando um subdomínio começa a se comportar de maneira suspeita permite remediar o problema antes que seja explorado.