Segurança de Transferência de Zona DNS Active Directory e Atualização Dinâmica Insegura: Detecção e Remediação

A segurança da transferência de zona DNS Active Directory e atualização dinâmica insegura não é uma configuração isolada — são três lacunas separadas, próximas do padrão, na forma como as zonas DNS integradas ao AD são configuradas, e juntas permitem que um atacante mapeie ou reescreva o DNS do seu domínio sem nunca tocar em Kerberos ou LDAP. Uma transferência de zona DNS do Active Directory deixada aberta, uma configuração de atualização dinâmica insegura e uma ACL padrão que permite que Authenticated Users criem registros DNS são três fraquezas separadas e de baixo esforço — e a segurança de DNS na maioria dos ambientes AD ainda é tratada como ruído de fundo, não como superfície de ataque.

Nenhuma das três exige um CVE ou um exploit novo. São configurações próximas do padrão que já vêm "funcionais" de fábrica e raramente são revisitadas depois que o domínio está em produção. Encadeadas, elas permitem que um atacante não autenticado ou com privilégios baixos mapeie a rede interna de graça, injete registros nela, ou ambos.

Transferência de Zona DNS Active Directory e Atualização Dinâmica Insegura: A Superfície de Ataque do DNS Integrado ao AD

Quando uma zona DNS é integrada ao Active Directory, seus registros vivem como objetos dnsNode dentro da partição de diretório (DomainDnsZones ou ForestDnsZones), não em um arquivo de zona simples. A Microsoft documenta esse modelo em Active Directory-Integrated DNS Zones: todo controlador de domínio gravável executando a função DNS Server pode aceitar atualizações da zona, e essas atualizações replicam pela replicação normal do AD, em vez de um mecanismo separado de transferência de zona entre primário e secundários.

Esse design tem duas consequências que importam para a segurança, não apenas para a disponibilidade:

• A própria zona tem uma ACL, exatamente como uma OU ou um grupo. Quem detém direitos de escrita nessa ACL pode criar, modificar ou excluir registros DNS — e os direitos padrão são mais amplos do que a maioria dos administradores espera.
• Duas proteções legadas independentes ainda protegem o perímetro da zona: a transferência de zona clássica (AXFR, para replicar a secundários não-AD ou para reconhecimento) e a atualização dinâmica (o mecanismo que os clientes usam para autorregistrar registros). Ambas são anteriores à integração ao AD e ambas tendem, por padrão, a ser permissivas.

Kerberos, LDAP e abuso de ACL recebem a maior parte da atenção na literatura de segurança de AD. DNS é diferente: pertence à categoria Rede, não à categoria Identidade, e costuma ficar totalmente de fora das checklists de hardening — ao lado de vizinhos como a assinatura LDAP desativada ou o TLS fraco do LDAPS e um Print Spooler que ninguém desativou, cobertos nesta checklist de higiene de rede de controladores de domínio — motivo exato pelo qual um domínio pode passar em uma revisão de Kerberos e ACL e ainda vazar toda a sua topologia via DNS.

Como Funciona: Três Configurações Incorretas Encadeáveis

1. Transferência de zona irrestrita (AXFR)

AXFR é o protocolo original de replicação de zona DNS, e nunca foi projetado com autenticação em mente. Como afirma o advisory da CISA sobre o tema, se um servidor DNS não for explicitamente configurado para restringir transferências, qualquer cliente que consiga alcançá-lo na porta TCP/53 pode solicitar — e receber — uma cópia completa da zona. Para uma zona integrada ao AD, isso significa cada hostname, endereço IP, registro de serviço (incluindo _ldap._tcp, _kerberos._tcp e outros registros SRV que fazem fingerprint de controladores de domínio) e qualquer subdomínio esquecido, entregues em uma única consulta.

Set-DnsServerPrimaryZone expõe a correção diretamente: o parâmetro -SecureSecondaries controla se as transferências são permitidas para qualquer servidor, apenas para os servidores listados na aba Name Servers, ou apenas para uma lista explícita de IPs — NoTransfer é a opção mais rígida quando nenhum secundário externo precisa da zona.

2. Atualização dinâmica insegura

A atualização dinâmica permite que um cliente registre ou atualize seu próprio registro DNS sem que um administrador o faça manualmente — algo normal e necessário para estações de trabalho ingressadas no domínio. O limite de segurança está em qual modo de atualização a zona usa. A própria documentação da Microsoft sobre Dynamic DNS Update in Windows and Windows Server e a orientação legada Allow Only Secure Dynamic Updates são explícitas: a atualização dinâmica segura — disponível apenas em zonas integradas ao AD — restringe as atualizações a computadores autenticados e ingressados no domínio, aplicada através das ACLs da zona. Uma zona deixada em Nonsecure and secure, por outro lado, aceita atualizações de qualquer um que consiga alcançar o serviço DNS, autenticado ou não — o que significa que um host não autenticado no segmento de rede pode criar ou sobrescrever registros à vontade.

3. Authenticated Users pode criar registros filhos diretamente

Esse é o ponto que a maioria das equipes nunca examinou diretamente. Por padrão, o grupo Authenticated Users detém Create All Child Objects na ACL da zona integrada ao AD — confirmado na própria orientação de comunidade da Microsoft sobre DNS record creation permissions e documentado em pesquisas de segurança ofensiva como a base do abuso de ADIDNS (Active Directory-Integrated DNS). As pesquisas da NetSPI sobre exploiting Active Directory-integrated DNS e ADIDNS Revisited expõem o efeito prático: qualquer conta de domínio, incluindo usuários e contas de computador com poucos privilégios, pode registrar novos registros DNS na zona sem nenhum direito elevado. A página sobre ADIDNS poisoning do The Hacker Recipes e a referência de AD DNS Records do HackTricks documentam isso como uma técnica consolidada e bem conhecida — não um exploit novo. Isso se soma a um padrão mais amplo que merece uma auditoria própria: Authenticated Users e Everyone silenciosamente super-inseridos em escopos privilegiados em todo um domínio, do qual a ACL padrão da zona DNS é uma instância específica e fácil de passar despercebida.

Dois tipos de registro tornam isso imediatamente perigoso:

• Um registro para um nome que ainda não existe — por exemplo, registrar o hostname de um servidor desativado ou um nome que uma aplicação legada ainda consulta, e depois apontá-lo para um IP controlado pelo atacante.
• Um registro curinga (*) — como uma wildcard responde a toda consulta que ainda não tem um registro explícito na zona, um atacante que cria uma se torna o resolvedor de última instância para toda a zona. A própria regra de detecção pronta para wildcard ADIDNS poisoning da Elastic descreve exatamente isso: um atacante se posiciona como adversary-in-the-middle ao resolver nomes arbitrários sem correspondência, o que possibilita interceptação de credenciais ou NTLM relay — conceitualmente semelhante em resultado ao spoofing de LLMNR/NBNS, mas persistente e abrangendo toda a zona em vez de um único broadcast.

A Global Query Block List (GQBL) é a mitigação da Microsoft para o alvo mais infame dessa técnica — WPAD — mas a pesquisa de acompanhamento da NetSPI observa que registros NS ainda a contornam em sistemas totalmente atualizados, então a GQBL é um controle parcial, não um substituto para corrigir a ACL subjacente.

As duas lacunas de apoio: DNSSEC e registros curinga já existentes

DNSSEC_NOT_ENABLED e DNS_WILDCARD_RECORDS agravam as três configurações incorretas acima em vez de constituírem caminhos de ataque independentes por si só:

• Sem DNSSEC, nada sobre a origem de um registro é criptograficamente verificável — uma resposta envenenada ou falsificada não pode ser distinguida de uma legítima. A Microsoft cobre a assinatura de zonas em Sign DNS Zones with DNSSEC on Windows Server e a mecânica subjacente na visão geral do DNSSEC — em uma zona integrada ao AD, as chaves de assinatura de zona replicam automaticamente para os servidores DNS primários pela replicação normal do AD, o que torna o DNSSEC comparativamente pouco custoso de implantar especificamente nesta plataforma.
• Um registro curinga já existente, encontrado durante uma auditoria — em oposição a um que um atacante acabou de criar — geralmente indica que a ACL da zona já foi abusada, ou que uma equipe de aplicação legada o solicitou sem revisão de segurança. De qualquer forma, vale a pena tratá-lo como uma questão de resposta a incidentes, não como um item de limpeza de configuração, até prova em contrário.

A Cadeia de Ataque

Etapa 1 — Reconhecimento via transferência de zona

Um atacante na rede (ou, se a zona for acessível externamente, a partir da internet) solicita uma transferência de zona ao servidor DNS:

dig axfr corp.local @10.10.10.10

Se a zona estiver irrestrita, a resposta é o conjunto completo de registros: controladores de domínio, registros SRV para Kerberos/LDAP, o hostname de cada estação de trabalho e servidor, e qualquer subdomínio que nunca deveria ser público.

Etapa 2 — Escolher um nome-alvo e registrar um registro

Usando nada além de uma conta de domínio padrão, o atacante registra um registro DNS para um nome de interesse — um host desativado, um nome que uma aplicação legada ainda resolve, ou uma wildcard:

# De qualquer máquina ingressada no domínio, como qualquer usuário de domínio autenticado
Add-DnsServerResourceRecordA -ZoneName "corp.local" -Name "legacy-app" -IPv4Address 10.10.10.50 -ComputerName dc01.corp.local

Se a zona ainda permitir atualização dinâmica nonsecure, essa etapa nem sequer exige uma credencial de domínio válida — um host não autenticado no segmento pode enviar a mesma atualização diretamente via o protocolo de atualização dinâmica.

Etapa 3 — Relay ou interceptação

Com o registro ativo, todo o tráfego destinado a esse nome passa a cair no host do atacante. Para resolução de nomes SMB/HTTP, isso é um análogo direto do spoofing de LLMNR/NBNS — exceto que persiste no DNS em vez de exigir que o atacante vença uma corrida a cada consulta de broadcast — e alimenta diretamente ferramentas de NTLM relay (Responder, ntlmrelayx) da mesma forma que uma resposta de broadcast envenenada faria. A técnica é ainda mais confiável quando a assinatura SMB está desativada ou não é exigida, já que nada impede que a sessão retransmitida seja aceita como legítima.

Detecção

O Windows Server traz dois canais de log DNS dedicados, ambos cobertos na documentação da Microsoft Enable DNS Logging and Diagnostics: eventos DNS Audit (habilitados por padrão, baixo overhead), cobrindo ações administrativas — criação/exclusão de zona, alterações de registro e operações de assinatura DNSSEC — e eventos DNS Analytical (desabilitados por padrão, maior volume), cobrindo o próprio tráfego de query/resposta/atualização dinâmica. Ambos ficam em Applications and Services Logs > Microsoft > Windows > DNS-Server no Visualizador de Eventos.

Remediação

1. Restrinja as transferências de zona. Configure as transferências apenas para secundários confiáveis, ou desative-as completamente se nenhum existir:

   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries TransferToSecureServers
   # ou, se nenhum secundário externo precisar desta zona:
   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries NoTransfer
   

2. Force atualização dinâmica apenas segura em cada zona integrada ao AD. Nonsecure and secure não deveria aparecer em uma zona de produção:

   Set-DnsServerPrimaryZone -Name "corp.local" -DynamicUpdate Secure
   

3. Reforce a ACL padrão da zona. Remover totalmente os direitos de create-child de Authenticated Users quebra o autorregistro legítimo de máquinas ingressadas no domínio, então isso precisa ser delimitado, não simplesmente revogado — a própria orientação da Microsoft sobre essa permissão (veja a thread da comunidade sobre o tema) confirma que o padrão é mais amplo do que a maioria das equipes percebe. Revise a aba de segurança da zona (ou dsacls contra CN=<zone>,CN=MicrosoftDNS,DC=DomainDnsZones,DC=...) e delimite os direitos de create-child às contas e grupos que realmente precisam se autorregistrar — tipicamente computadores do domínio via atualização dinâmica segura, não o grupo Authenticated Users completo e incondicional.

4. Exclua registros curinga inesperados encontrados durante a varredura de auditoria, e trate qualquer um que você não tenha provisionado como um possível indicador de comprometimento anterior, não apenas como limpeza.

5. Habilite a Global Query Block List para as clássicas armadilhas de nome de alto valor (WPAD, ISATAP) como uma camada adicional de defesa em profundidade — dnscmd /config /enableglobalqueryblocklist 1 — lembrando da descoberta da NetSPI de que registros NS ainda a contornam, então isso é um complemento à correção da ACL, não um substituto.

6. Habilite o DNSSEC em zonas integradas ao AD conforme o guia de assinatura de zona da Microsoft — as chaves de assinatura replicam automaticamente pelo AD, então, uma vez configurado o Key Master, o rollout nos demais controladores de domínio que hospedam a zona é, em grande parte, automático.

O DNS é apenas um item em uma lista bem mais longa — para um passo a passo completo do que revisar primeiro em exposição Tier 0, abuso de ACL, Kerberos e logging, veja Auditar a Segurança do Active Directory: Checklist Prática.

Como a EtcSec Detecta Isso

A auditoria da categoria Rede da EtcSec verifica zonas DNS integradas ao AD diretamente contra estas cinco lacunas: DNS_ZONE_TRANSFER_UNRESTRICTED e DNS_DYNAMIC_UPDATE_INSECURE sinalizam zonas cujas configurações de transferência ou atualização são mais amplas do que o padrão seguro, DNS_ZONE_AU_CREATE_CHILD sinaliza zonas em que Authenticated Users ainda detém direitos de create-child na ACL da zona, DNSSEC_NOT_ENABLED sinaliza zonas integradas ao AD não assinadas, e DNS_WILDCARD_RECORDS sinaliza registros curinga existentes para revisão manual.