Subdomain takeover: como acontece, como detectar e como corrigir
Um registro DNS órfão apontando para um serviço desprovisionado permite que um atacante reivindique o recurso e sirva conteúdo pelo seu subdomínio.
Severidade típica: Alta · Verificado pelo módulo da NovaPentest: Subdomain Takeover
O que é
O subdomain takeover ocorre quando um registro DNS - geralmente um CNAME - aponta para um serviço externo (GitHub Pages, Heroku, um bucket S3, Azure, Netlify, Fastly, Shopify, Zendesk e semelhantes) que já não hospeda mais nada seu. A entrada DNS continua resolvendo e ainda delega o tráfego do subdomínio para aquele provedor, mas o recurso por trás foi apagado, teve o trial expirado ou nunca foi reivindicado. Como esses provedores alocam recursos por ordem de chegada, qualquer pessoa que registrar o mesmo nome de bucket, de app ou de repositório de Pages passa a controlar o que os visitantes do seu subdomínio veem.
O subdomínio continua carregando o nome da sua organização e, o mais importante, a confiança do seu domínio: muitas vezes é possível obter TLS válido, ler cookies com escopo no domínio pai e subverter fluxos de CSP ou de single sign-on que confiam no host. A causa raiz é uma falha de ciclo de vida - um serviço é desativado, mas o registro DNS fica para trás (fica órfão, ou dangling). O problema se enquadra em OWASP Security Misconfiguration e CWE-350.
Os dois estados perigosos são: (1) o host de destino não resolve mais (NXDOMAIN) enquanto outro registro ainda aponta para ele, e (2) o CNAME aponta para um provedor conhecido cujo recurso está sem dono. Ambos são exploráveis; a diferença é só a rapidez com que um atacante consegue tomar o nome.
Como é explorada
Um atacante enumera os subdomínios de uma organização (logs de certificate transparency, brute force de DNS, bases públicas) e verifica o alvo do CNAME de cada um. Quando o destino aponta para um provedor que devolve uma assinatura de "recurso não encontrado" - por exemplo a mensagem "NoSuchBucket" do S3 ou a página "There isn't a GitHub Pages site here" do GitHub - o nome está livre para ser tomado. O atacante cria uma conta no provedor e registra exatamente o bucket, app ou repositório que o CNAME espera, e então passa a servir o próprio conteúdo.
A partir daí a página maliciosa carrega sob o seu subdomínio e herda a reputação do domínio. Abusos típicos: phishing convincente hospedado em um nome que a vítima já confia; leitura ou gravação de cookies com escopo em *.exemplo.com para sequestrar sessões; bypass de uma Content-Security-Policy que confia no subdomínio; abuso de allowlists de OAuth ou de redirect que confiam no host; ou obtenção de um certificado válido para dar aparência legítima ao site falso. Como o controle é total, o atacante também pode injetar scripts em páginas que embutem ou consomem o subdomínio.
O impacto vai de dano à marca e phishing até sequestro completo de sessão e, quando há confiança de SSO ou de API, account takeover. O ataque não exige código de exploit - basta o registro órfão e a vaga livre no provedor coincidirem.
Como detectar
O módulo de Subdomain Takeover da NovaPentest começa pelo DNS. Ele lê a cadeia real de CNAME do hostname, seguindo até cinco saltos. Se o hostname não tem CNAME e não resolve (NXDOMAIN), gera um achado High, porque qualquer registro em outro lugar que ainda aponte para esse nome está órfão.
Quando existe um CNAME, o módulo verifica se o nome de destino ainda existe. Um CNAME cujo destino retorna NXDOMAIN é a pré-condição clássica de takeover: o módulo reporta como Critical quando o destino pertence a um provedor que permite registrar de novo nomes liberados (por exemplo github.io, herokuapp.com, S3, Azure App Service ou Netlify), e como High nos demais casos.
Se o destino existe e pertence a um desses provedores, o módulo acessa a página e procura a mensagem do próprio provedor dizendo que o recurso não tem dono, como "There isn't a GitHub Pages site here" ou "NoSuchBucket". Só uma mensagem específica assim gera um achado Critical. Texto genérico como "Not Found" não conta como prova, porque aparece em qualquer página 404 comum. Um registro que aponta para um provedor sujeito a takeover, mas sem sinal de estar sem dono, vira um item Low de revisão de propriedade.
O módulo verifica o alvo que você cadastrou, não todos os subdomínios da sua zona; ele não enumera o seu DNS.
Para verificar manualmente, rode `dig CNAME sub.exemplo.com.br +short` para ver para onde o registro aponta e depois `dig A <destino> +short` para confirmar que o destino ainda resolve. Se resolver, abra o hostname no navegador e compare a página com a mensagem documentada pelo provedor para recursos sem dono. Faça isso para todos os CNAMEs da zona, não só para os que você lembra de ter criado.
Como corrigir
Corrija os registros órfãos na origem e previna com processo.
1. Inventarie todos os registros DNS e mapeie cada CNAME/ALIAS para um recurso vivo e de sua propriedade. Qualquer destino que devolva NXDOMAIN ou uma página de "não encontrado" do provedor está órfão - apague o registro DNS imediatamente; só isso já fecha o takeover.
2. Imponha a ordem das operações ao desativar algo: remova ou reaponte o registro DNS primeiro e só depois apague o recurso na nuvem - nunca o contrário. O intervalo entre apagar o recurso e apagar o registro é exatamente a janela explorável.
3. Reivindique antes de apontar: só crie um CNAME para um provedor depois que o bucket, app ou site de Pages já existir e for seu, para que o nome nunca fique livre por um instante.
4. Prefira provedores que vinculam o recurso a um token de verificação ou exigem prova de posse do domínio, o que impede um estranho de reivindicar o nome mesmo que o registro permaneça.
5. Automatize o monitoramento contínuo: agende checagens recorrentes de resolução e de assinatura em todos os subdomínios (as mesmas que um scanner faz) e alerte a cada resposta NXDOMAIN ou de provedor sem dono.
6. Reduza a superfície: aposente subdomínios curinga e obsoletos e revise os logs de certificate transparency em busca de nomes que você não usa mais.
Priorize os casos confirmados e de NXDOMAIN primeiro (exclusão imediata) e depois audite os provedores em risco que ainda servem conteúdo para confirmar a posse.
Verifique o seu próprio site
Comece pelo scan passivo gratuito: não precisa de conta e você recebe uma nota de A a F cobrindo cabeçalhos, TLS, cookies, DNS e outras configurações que qualquer visitante consegue observar. Ele não envia payloads de ataque, então não confirma todas as classes de falha. O scan completo, disponível com uma conta gratuita, executa as verificações ativas, incluindo a descrita nesta página.