Quando uma empresa cancela um serviço mas não remove o registro DNS, qualquer pessoa pode reivindicar aquele destino e usar o subdomínio legítimo para phishing com TLS válido, roubo de cookies de sessão e comprometimento de fluxos OAuth.
Empresas criam subdomínios para cada projeto: blog.empresa.com.br vai para o Heroku, status.empresa.com.br vai para o Statuspage, cdn.empresa.com.br vai para um bucket S3. Esses apontamentos são feitos via registro CNAME: um apelido DNS que redireciona um nome para outro.
O problema é um descasamento de ciclo de vida: recursos de nuvem são temporários; registros DNS são persistentes. Quando a empresa cancela o plano no Heroku mas esquece de remover o CNAME, o subdomínio continua existindo e apontando para um destino que qualquer pessoa pode agora reivindicar.
Isso é consistentemente um dos achados mais reportados em programas de bug bounty, e o motivo é simples: exige disciplina operacional entre equipes diferentes (quem cria recursos de nuvem vs. quem gerencia DNS), e quase ninguém tem esse processo automatizado.
A maioria das discussões foca em CNAME, mas existem três tipos com impactos diferentes:
CNAME aponta para serviço que foi cancelado. Atacante cria conta no mesmo serviço com o mesmo nome e assume o subdomínio.
Subdomínio delega toda sua resolução DNS para um provedor externo cujo account foi encerrado. Atacante assume o provedor e controla toda a resolução do subdomínio.
Registro MX aponta para serviço inexistente. Atacante recebe e-mails endereçados ao subdomínio: incluindo e-mails de validação de domínio de CAs.
O NS takeover é especialmente crítico: ao controlar o servidor DNS autoritativo de um subdomínio, o atacante pode criar qualquer tipo de registro (A, CNAME, TXT, MX): não fica limitado ao que o serviço terceiro permite. Isso inclui criar registros TXT para validação de domínio e emitir certificados TLS.
Cria staging.empresa.com.br com CNAME para empresa-staging.herokuapp.com e implanta a aplicação.
A empresa deleta o app no Heroku, mas não remove o CNAME do DNS. staging.empresa.com.br continua resolvendo para empresa-staging.herokuapp.com, que agora retorna "No such app".
Ferramentas como nuclei com templates de takeover, subfinder + verificação de fingerprints, e enumeração de CT logs revelam subdomínios respondendo com mensagens de erro de "app não encontrado".
Cria conta no Heroku e registra app com o mesmo nome empresa-staging. O CNAME da empresa agora aponta para um app que ele controla. Tempo total: minutos.
staging.empresa.com.br serve o conteúdo que o atacante quiser, com certificado TLS válido emitido automaticamente pela plataforma, sob o domínio legítimo da empresa.
Controlar um subdomínio de uma empresa vai muito além de hospedar uma página de phishing visualmente convincente:
Se a aplicação principal define cookies com Domain=.empresa.com.br (domínio pai), todos os subdomínios (incluindo o comprometido) recebem esses cookies. O subdomínio controlado pelo atacante pode ler tokens de sessão ativos.
CSPs que usam *.empresa.com.br como origem confiável para scripts e frames confiam automaticamente no subdomínio comprometido. Scripts carregados do subdomínio atacante passam pela CSP.
Fluxos OAuth que usam correspondência de padrão em redirect URIs (ex.: *.empresa.com.br) aceitarão o subdomínio comprometido como destino de redirect pós-autenticação: entregando tokens de acesso ao atacante.
Let's Encrypt e outras CAs emitem certificados para qualquer domínio que passe na validação HTTP ou DNS. O atacante obtém um cert TLS válido para staging.empresa.com.br: o cadeado verde aparece no browser.
Para takeovers de MX: e-mails de validação de domínio, notificações de sistema e confirmações de conta endereçadas ao subdomínio chegam ao atacante: incluindo e-mails usados por CAs para validação de domínio (DV).
Cada serviço responde de forma distinta quando o recurso alvo não existe mais. Essas mensagens de erro são o que ferramentas de detecção buscam automaticamente:
Para NS takeover, a assinatura não é uma página de erro, mas um status SERVFAIL ou REFUSED na resolução DNS do subdomínio. Ferramentas como nuclei com o template servfail-refused-hosts detectam isso automaticamente ao consultar os nameservers autoritativos.
O erro mais comum é cancelar o serviço e só depois (ou nunca) remover o DNS. A ordem correta de decommissioning é:
1. Identifique todos os registros DNS que apontam para o recurso (CNAME, A, MX, NS, TXT). 2. Remova ou redirecione os registros DNS. 3. Aguarde a propagação (TTL do registro). 4. Somente então cancele o serviço externo. Manter o CNAME ativo mesmo por horas após o cancelamento já cria a janela de takeover.
Varredura periódica: ferramentas como nuclei com templates de takeover verificam fingerprints de dezenas de serviços em lotes de subdomínios. A análise do WS Vicentin inclui detecção automática de CNAMEs pendentes para os principais serviços.
Certificate Transparency logs: crt.sh e certspotter publicam novos certificados TLS em tempo real. Monitorar novos certs emitidos para subdomínios do seu domínio é uma forma de detectar takeover já consumado: o atacante precisará emitir um certificado para o subdomínio comprometido.
Infrastructure-as-Code: usar Terraform ou Pulumi para gerenciar DNS cria uma fonte única de verdade onde a existência de um registro DNS é vinculada ao código que gerencia o recurso alvo. Quando o recurso é destruído (terraform destroy), o registro DNS some junto.
