Guias de Segurança
Subdomain takeover (DNS pendente): como um registro DNS esquecido deixa atacantes usarem o seu domínio
Apague um recurso na nuvem mas deixe o CNAME para trás e qualquer um pode assumir aquele subdomínio — sem tocar nos seus servidores. Por que os cookies de sessão vazam, por que um certificado não salva você e a ordem de exclusão que evita isso.
Um dia, um subdomínio seu começa a servir conteúdo de um atacante — e ninguém tocou nos seus servidores. Correções de segurança, autenticação e monitoramento não ajudam aqui. A causa não é uma invasão. É algo que você esqueceu de apagar.
O que de fato acontece (três etapas)
1. Criação
Você cria um recurso na nuvem com um nome de domínio totalmente qualificado (app-xxxx.<domínio do provedor>) e adiciona um registro CNAME na sua zona para quesub.example.comaponte para ele.2. Desativação (pela metade)
O recurso é apagado quando deixa de ser necessário. Nesse momento o CNAME desub.example.comtambém deveria ser removido — e não é. Ele continua anunciado como um domínio ativo, apontando para nada: um registro DNS pendente (dangling DNS).3. Tomada de controle
Um agente de ameaça descobre o subdomínio pendente e cria um recurso com o mesmo FQDN que antes era seu. A partir daí, o tráfego parasub.example.comchega ao recurso dele, onde ele decide o conteúdo.
A sua zona DNS (sem alteração)
sub.example.com CNAME→ app-xxxx.provider.example
↓ só o destino foi removido
Recurso na nuvem: apagado
o nome volta a ser disponível para qualquer um
↓ o atacante cria o mesmo nome
Recurso do atacante (a conta dele)
ele decide o que sub.example.com serve. Os seus servidores nunca foram tocados
Os CNAMEs são o ponto fraco porque apontam para um nome
Ao contrário de um registro A, que aponta para um endereço, um CNAME aponta para um nome — e, em muitos serviços de nuvem, esse nome fica disponível para quem o reivindicar primeiro. No momento em que você o solta, outra pessoa pode pegá-lo. A documentação diz que os registros CNAME são "especialmente vulneráveis a essa ameaça". A mesma lógica vale para registros MX, e a consequência é que e-mails endereçados àquele subdomínio podem ser recebidos por outra pessoa.
O dano não é só uma página com aparência falsa
- Perda de controle sobre o subdomínio
- Conteúdo que você não gerencia é servido a partir do seu próprio domínio — dano à marca e perda de confiança
- Coleta de cookies
- É comum os apps web exporem cookies de sessão a subdomínios por meio de um curinga (
*.example.com), e então qualquer subdomínio consegue acessá-los. Uma página convincente no subdomínio sequestrado pode coletá-los dos visitantes — inclusive cookies marcados como Secure - Uso para phishing
- Como o domínio se confirma como legítimo, o phishing a partir dele fica muito mais convincente
O maior equívoco: "é HTTPS, temos certificado"
A documentação aponta isso como um equívoco comum e o rejeita: um agente de ameaça que detém o subdomínio sequestrado pode solicitar e receber um certificado válido para ele. Um certificado validado por domínio verifica que o solicitante controla o nome naquele momento, então não detecta que o controle mudou de mãos.
O resultado é que um certificado válido trabalha a favor do atacante — o cadeado aparece, cookies marcados como Secure continuam sendo enviados e o site falso parece mais legítimo, não menos. Leia um certificado como "quem detém este nome", nunca como "com quem estou falando".
Como evitar: faça da remoção prévia do registro DNS parte do procedimento
A causa não é dificuldade técnica; é a ordem dos passos de desativação. Se você apaga o recurso primeiro e o DNS depois, o subdomínio pode ser tomado no intervalo.
A ordem que gera incidentes
Apagar o recurso → DNS depois → esquecer
Enquanto isso, o DNS continua anunciando um subdomínio ativo e legítimo. O monitoramento não vai avisar que um servidor caiu — porque nada caiu.
A ordem segura
Remover primeiro o registro DNS → depois apagar o recurso
A documentação recomenda aplicar bloqueios de exclusão a recursos que têm uma entrada DNS personalizada, porque o próprio bloqueio sinaliza que o mapeamento precisa ser removido antes de o recurso ser desativado — observando que medidas assim só funcionam combinadas com treinamento interno.
Coloque "remover a entrada DNS" na checklist de desativação
Este é o primeiro passo de prevenção que a documentação indica: colocá-lo na lista de verificações obrigatórias ao desativar um serviço e ensinar os desenvolvedores a remover os registros DNS sempre que apagarem recursos. O ponto é não deixar a ordem dependendo da memória de ninguém.
Ligue o ciclo de vida do registro ao do recurso
Alguns provedores oferecem tipos de registro vinculados ao próprio recurso (registros alias e similares). Apague o recurso e o registro vira um conjunto vazio, então não dá para sobrar um registro apontando para nada. A cobertura se limita a certos serviços, mas use onde se aplicar: evita registros esquecidos pelo design, e não pelo processo.
Exija prova de propriedade
Alguns serviços permitem publicar um registro TXT de verificação de propriedade para um domínio personalizado. Onde ele existe, nenhuma outra assinatura consegue validar esse domínio personalizado nem tomá-lo. Isso não impede alguém de criar um recurso com o mesmo nome, mas, sem poder provar a propriedade, ele não recebe o seu tráfego. Só quem consegue provar a propriedade pode usar o nome, não quem o reivindica primeiro.
Revise as zonas DNS regularmente — existe, e é seu?
A documentação indica duas verificações: o destino existe, e ele é seu? A segunda é a mais importante, porque "responde, então está tudo bem" não é uma verificação — uma resposta vinda do recurso de outra pessoa é justamente este ataque. Mantenha um catálogo de serviços que associe os endpoints FQDN a responsáveis e exporte-o periodicamente como parte do seu inventário de ativos.
Ao encontrar um, não pare em apagar o registro
Os passos de remediação vão além: atualizar referências desatualizadas ao subdomínio no código da aplicação, investigar se houve comprometimento e descobrir por que o registro não foi removido na desativação, para que não se repita. Em especial, se a lógica da sua aplicação enviava segredos como credenciais OAuth, ou informações sensíveis à privacidade, para aquele subdomínio pendente, esses dados podem ter sido expostos a um terceiro.
A visão deste site: a exposição vem mais do que você parou de usar do que do que você construiu
As conversas sobre segurança se concentram no que está sendo construído, enquanto as invasões costumam começar pelo que foi aposentado e deixado para trás. Um subdomínio que ninguém usa, a conta de um colega que saiu, um ambiente de testes criado para um experimento, cadastros de membros mantidos após o cancelamento de uma assinatura — todos têm em comum que "não usamos mais" tira algo, sem alarde, do monitoramento e da revisão. Algo que você parou de usar continua sendo um ativo até ser apagado. Por isso defendemos que o inventário abranja tudo o que você já criou, e não só o que está rodando. As pessoas que se viram afetadas por uma violação no provedor depois de cancelar o serviço são um exemplo do mesmo problema (o que fazer quando o seu provedor de hospedagem é invadido).
Fontes (primárias)
- Microsoft, "Prevent dangling DNS entries and avoid subdomain takeover" (Microsoft Learn / fundamentos de segurança do Azure) — learn.microsoft.com (as três etapas, por que os CNAMEs são especialmente vulneráveis, a coleta de cookies e os registros MX, a rejeição do equívoco sobre o certificado e os passos de prevenção e remediação — bloqueios de exclusão, registros alias, verificação de propriedade, revisão regular — vêm todos deste documento)
Leia a seguir
- Inventário: a checklist de inventário de ativos (estenda-a a tudo o que você já criou)
- Configuração: buckets públicos (o mesmo formato de "vaza pela configuração")
- Glossário: o que é phishing / o que é XSS / o que é CSRF
FAQ
QUm subdomain takeover significa que os meus servidores foram invadidos?
Não, e é isso que torna a situação incômoda. O que é tomado é o destino para onde o DNS aponta, não o seu servidor. Se você apaga um recurso na nuvem mas deixa o registro CNAME na sua zona DNS, um terceiro só precisa criar um recurso com o mesmo nome de domínio totalmente qualificado (FQDN) na assinatura dele, e o tráfego destinado ao seu subdomínio chega ao recurso dele. Correções de segurança, autenticação e monitoramento não ajudam aqui, porque nenhum deles está envolvido.
QO HTTPS não evita isso? Um certificado não deixa tudo seguro?
Não deixa, e a documentação da Microsoft aponta isso diretamente como um equívoco comum: quem detém o subdomínio sequestrado pode solicitar e receber um certificado válido para ele. Um certificado validado por domínio prova só que quem o detém controla aquele nome neste momento — não diz nada sobre quem é essa parte e não detecta que o controle mudou de mãos. Um certificado válido na verdade favorece o atacante, aumentando a aparência de legitimidade do site falso.
QSe só afeta a aparência, o dano não é limitado?
As sessões vazam. É comum os apps web exporem cookies de sessão a subdomínios por meio de um curinga (*.example.com) e, quando é assim, qualquer subdomínio consegue lê-los. Se os usuários puderem ser levados ao subdomínio sequestrado, até cookies marcados como Secure podem acabar com o atacante. E um registro MX pendente significa que e-mails endereçados àquele subdomínio podem ser recebidos por outra pessoa.
QComo evito isso na prática?
Transforme a ordem de exclusão num procedimento e num mecanismo, em vez de algo de que as pessoas se lembram. A documentação recomenda colocar "remover a entrada DNS" na checklist obrigatória de desativação de um serviço, aplicar bloqueios de exclusão a recursos que têm uma entrada DNS personalizada para que o próprio bloqueio sinalize que o DNS precisa sair primeiro, usar tipos de registro cujo ciclo de vida é ligado ao recurso onde disponíveis e revisar as zonas DNS regularmente para confirmar tanto que cada destino existe quanto que ele é seu.