Sequestro de Subdomínio: como agentes maliciosos exploram registros DNS esquecidos na AWS

O que é um registro DNS “dangling” e por que isso importa

Imagine que sua equipe configurou um subdomínio amigável — como api.suaempresa.com — apontando para um bucket do Amazon S3 via registro CNAME (Nome Canônico). Em algum momento, o bucket é deletado, mas ninguém lembrou de remover o registro DNS. Esse registro que ficou para trás, apontando para um recurso que não existe mais, é chamado de dangling record (registro pendente ou órfão).

O problema real começa quando um agente malicioso percebe esse estado. Como certos recursos da AWS utilizam namespaces globais — ou seja, qualquer conta pode reivindicar o mesmo nome de recurso após ele ser deletado — o atacante pode simplesmente recriar o recurso com o mesmo nome e passar a servir conteúdo malicioso para qualquer usuário que ainda acesse aquele subdomínio.

Essa técnica é classificada pelo MITRE ATT&CK como T1584.001: Comprometimento de Infraestrutura – Domínios. Vale reforçar: não se trata de uma vulnerabilidade nos serviços da AWS em si, mas de uma má configuração operacional que pode ser explorada.

Quais recursos AWS são afetados

Nem todo recurso da AWS é suscetível a esse tipo de ataque. O risco existe apenas nos serviços que operam em namespaces globalmente compartilhados, onde qualquer conta pode reivindicar o nome após a exclusão. Os principais são:

• Amazon S3 (namespace global): nomes de buckets como meubucket.s3.amazonaws.com são globalmente únicos e podem ser reclamados por qualquer conta após a exclusão. Importante: buckets criados com namespaces regionais por conta (lançados em março de 2026) ficam restritos à conta do proprietário e não são afetados por esse problema.
• Amazon CloudFront: os nomes de distribuição como d111111abcdef8.cloudfront.net são atribuídos pela AWS e não podem ser escolhidos por um atacante. Porém, se uma distribuição for deletada e outra conta receber o mesmo nome gerado automaticamente, um CNAME pendente pode acabar resolvendo para o conteúdo de terceiros.
• AWS Elastic Beanstalk: nomes de ambiente como meuapp.elasticbeanstalk.com são globalmente únicos e podem ser reivindicados por qualquer conta após o encerramento do ambiente.

Recursos como Amazon VPC, instâncias Amazon EC2 ou zonas hospedadas privadas não são afetados, pois não expõem namespaces DNS globalmente reivindicáveis.

Como o ataque acontece na prática

O time AWS CIRT publicou um cenário ilustrativo que ajuda a entender o problema de ponta a ponta. Considere o seguinte fluxo:

1. Uma equipe cria um bucket S3 com nome global único — por exemplo, subdomain.example — e o configura para hospedar um site estático.
2. Um registro CNAME no Amazon Route 53 é criado para que subdomain.example.com resolva para subdomain.example.s3-website-us-east-1.amazonaws.com, dando um endereço amigável aos usuários.

Até aqui, tudo normal. O problema surge quando o administrador decide desativar o site e deleta o bucket S3 — mas esquece de remover o registro CNAME no Route 53.

Com o bucket deletado e o CNAME ainda ativo, o registro fica “dangling”. Um agente malicioso que identifica esse estado pode criar um novo bucket S3 com exatamente o mesmo nome global — subdomain.example — em uma conta que ele controla, e passar a servir qualquer conteúdo a partir daí. Os usuários finais continuam acessando subdomain.example.com sem perceber que o destino mudou.

Impactos potenciais para sua organização

Os riscos não são teóricos. O AWS CIRT lista os principais impactos observados:

• Risco reputacional: sua organização perde o controle sobre o conteúdo servido a partir de um domínio que carrega sua marca.
• Exposição a campanhas de phishing: usuários que têm o subdomínio salvo nos favoritos podem ser direcionados para páginas que capturam credenciais ou distribuem malware sem nenhum sinal de alerta visível.
• Bloqueio por fornecedores de segurança: se o domínio for sinalizado como malicioso, isso pode impactar diretamente suas operações de negócio.
• Perda financeira: além do dano direto, há custos associados à resposta ao incidente e à interrupção de serviços.

Detecção proativa com AWS Config

A abordagem recomendada pela AWS para detectar registros CNAME órfãos é usar o AWS Config para monitorar continuamente as zonas hospedadas do Route 53 e verificar se os recursos-alvo ainda existem na sua conta.

Um ponto importante que o artigo destaca: verificar se um CNAME resolve para um endpoint válido não é suficiente. Se um atacante já reivindicou o recurso, a resolução DNS vai funcionar — mas para o recurso do atacante, não o seu. Você não teria como saber a diferença apenas pela resolução. A abordagem correta é consultar o inventário do AWS Config para confirmar se o recurso existe na sua conta.

A ideia central é criar uma regra personalizada no AWS Config que consulta as zonas hospedadas do Route 53, identifica registros CNAME que apontam para padrões conhecidos de recursos AWS (S3, CloudFront, Elastic Beanstalk) e cruza cada alvo com o inventário do Config. Se o recurso não for encontrado, o CNAME é marcado como NON_COMPLIANT.

Os padrões monitorados incluem:

• S3: *.s3.amazonaws.com, *.s3-website-<região>.amazonaws.com
• CloudFront: *.cloudfront.net
• Elastic Beanstalk: *.elasticbeanstalk.com

Pré-requisito: o gravador do AWS Config precisa estar habilitado para os tipos de recurso que você deseja monitorar. Para mais informações, consulte a documentação oficial sobre como configurar o AWS Config pelo console.

Escopo: conta única vs. organização

A implementação de referência opera no escopo de uma única conta. Isso significa que se um CNAME na Conta A aponta para um recurso que legitimamente existe na Conta B (dentro da mesma organização AWS), a regra vai sinalizá-lo como NON_COMPLIANT. Para ambientes com compartilhamento de recursos entre contas, é possível adaptar a solução usando um AWS Config Aggregator, que consulta o inventário de todas as contas da organização.

Diagrama da solução de detecção

As ocorrências NON_COMPLIANT podem ser encaminhadas ao AWS Security Hub para visibilidade centralizada ou acionar notificações via Amazon SNS para alertar o time de segurança.

Implementação de referência

A AWS publicou uma solução completa e open source para esse caso de uso. Ela implanta uma função Lambda que varre os registros CNAME de todas as zonas hospedadas do Route 53, usa correspondência de padrões para identificar alvos que apontam para S3, CloudFront e Elastic Beanstalk, e consulta o inventário do AWS Config para verificar se cada recurso ainda existe na conta. Quando um registro órfão é detectado, a solução gera uma ocorrência de severidade ALTA no Security Hub e pode enviar notificações via SNS. Um painel no CloudWatch também é incluído para acompanhamento contínuo.

O deploy pode ser feito com os seguintes comandos:

# Clone the repository
git clone https://github.com/aws-samples/sample-dangling-dns-detection
cd sample-dangling-dns-detection

# Build the Lambda deployment package
./scripts/package.sh

# Upload to S3
aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/

# Deploy the CloudFormation stack
aws cloudformation deploy \
  --template-file infrastructure/template.yaml \
  --stack-name dangling-dns-detection \
  --parameter-overrides \
    LambdaCodeS3Bucket=YOUR_BUCKET \
    EvaluationFrequency=TwentyFour_Hours \
  --capabilities CAPABILITY_NAMED_IAM

A stack cria uma regra personalizada no AWS Config que roda no intervalo configurado (padrão: a cada 24 horas), avaliando todos os registros CNAME e reportando o status de conformidade.

Como mitigar: prevenção e resposta

Procedimento operacional padrão

A mitigação mais eficaz é um procedimento operacional claro para o descomissionamento de recursos. A ordem correta é sempre:

1. Remova o registro CNAME da zona DNS antes de desprovisionar o recurso.
2. Aguarde o TTL (Tempo de Vida — Time to Live) do registro expirar. Resolvedores DNS armazenam registros em cache pelo tempo do TTL (por exemplo, um TTL de 3600 significa que resolvedores podem servir o registro antigo por até uma hora). Deletar o recurso antes da expiração do TTL abre uma janela de vulnerabilidade.
3. Desprovi­sione o recurso.
4. Execute uma verificação DNS para confirmar que o CNAME não está mais resolvendo.

Princípio-chave: sempre delete o DNS primeiro, espere o TTL expirar e só então delete o recurso.

Namespaces regionais por conta no S3

Em março de 2026, a AWS introduziu os namespaces regionais por conta para buckets S3 de uso geral. Trata-se de um avanço relevante para mitigar o vetor específico do S3, mas há limitações operacionais importantes:

• Buckets existentes não são migrados: buckets já criados no namespace global permanecem globalmente únicos e reivindicáveis por qualquer conta após a exclusão.
• O namespace global ainda é o padrão: ao criar um novo bucket pelo console, CLI ou SDK, o namespace global continua sendo a seleção padrão.
• Templates de IaC precisam ser atualizados: templates existentes de infraestrutura como código (CloudFormation, CDK, Terraform) que não optarem explicitamente pelo namespace regional de conta continuarão provisionando buckets no namespace global. No CloudFormation, isso exige configurar a propriedade BucketNamespace como account-regional.

Por essas razões, a abordagem de detecção via AWS Config continua sendo essencial — especialmente para organizações com infraestrutura S3 existente e para recursos como CloudFront e Elastic Beanstalk, onde não existe equivalente de escopo por namespace.

Notificação e remediação

Quando um registro DNS órfão é detectado, a solução de referência cria automaticamente uma ocorrência de severidade ALTA no AWS Security Hub e marca o CNAME como NON_COMPLIANT no AWS Config. Se um ARN (Nome de Recurso da Amazon — Amazon Resource Name) de tópico SNS for fornecido durante o deploy, a solução também envia notificações para o time de segurança via e-mail, Slack ou outros canais.

Para ambientes de produção, é recomendável adotar um fluxo com revisão humana antes de qualquer deleção automática de registro DNS. Remediação totalmente automatizada carrega risco: um falso positivo pode interromper serviços legítimos. O ponto de partida ideal é detecção e notificação; automação pode ser avaliada conforme a maturidade operacional do time.

Conclusão

O sequestro de subdomínio é uma misconfigura­ção evitável, mas com impacto potencialmente significativo. A defesa em camadas recomendada pela AWS combina:

• Prevenção: procedimento operacional padrão que garante a remoção do DNS antes do descomissionamento do recurso.
• Detecção: regras personalizadas no AWS Config para identificar proativamente CNAMEs que apontam para recursos inexistentes.
• Resposta: notificações via SNS ou Security Hub para que o time reaja rapidamente quando registros órfãos forem detectados.
• Monitoramento: visibilidade contínua via painéis no CloudWatch para acompanhar a saúde do DNS e o status de conformidade.

A boa higiene de DNS — saber quando seus registros CNAME apontam para recursos inexistentes — é a primeira linha de defesa. A detecção automatizada via AWS Config funciona como rede de segurança quando os procedimentos operacionais falham. E ter um playbook pronto para resposta reduz o tempo médio de recuperação quando um incidente é identificado.

Para entender melhor suas responsabilidades dentro do modelo de responsabilidade compartilhada e aprofundar as práticas de segurança, a AWS disponibiliza o Pilar de Segurança do Well-Architected Framework como referência.

Fonte

Threat tactic spotlight: Subdomain takeover (https://aws.amazon.com/blogs/security/threat-tactic-spotlight-subdomain-takeover/)