Pesquisadores divulgaram uma técnica prática de abuso de registros DNS CNAME que expande a superfície de ataques de relay contra ambientes Active Directory. A prova de conceito (PoC) publicada permite forçar clientes Windows a solicitar tickets Kerberos para destinos controlados pelo atacante, viabilizando relays entre protocolos e movimentos laterais.
Como o abuso funciona
O comportamento explorado é simples: quando um cliente Windows recebe um registro CNAME, ele segue o alias e monta o pedido de Ticket Granting Service (TGS) usando o nome canônico (CNAME) como Service Principal Name (SPN). Um atacante com capacidade on-path DNS pode responder com um CNAME apontando para um hostname de propriedade do atacante e um A record resolvendo para seu IP. O cliente, então, solicita o ticket Kerberos destinado ao SPN fornecido — mas a autenticação acaba sendo realizada contra a infraestrutura do atacante.
Capacidades e impacto
- Relay cross‑protocol: a técnica permite relays HTTP→SMB e HTTP→LDAP, entre outros, ampliando vetores de abuso tradicionais.
- RCE via ADCS: cenários confirmados incluem possibilidade de execução remota (RCE) via ADCS Web Enrollment (ESC8), quando configurações padrão estão vulneráveis.
- Lateral movement e impersonation: ataques permitem movimentação lateral sem necessidade de credenciais em texto e podem resultar em impersonação de usuários e serviços.
PoC e ferramentas
Pesquisadores modificaram a ferramenta MITM6 e publicaram um repositório no GitHub com capacidades de envenenamento CNAME, incluindo modo DNS-only e integração com ARP poisoning. A PoC requer Python 3.x e Linux para execução direcionada por domínio ou para todos os queries DNS.
Resposta do fornecedor e limites da mitigação
A Microsoft respondeu implementando suporte a Channel Binding Tokens (CBT) para HTTP.sys e publicou patches em janeiro de 2026 (rastreado como CVE-2026-20929) que mitigam ataques via HTTP. No entanto, essa correção cobre apenas cenários HTTP; o primitivo de coerção por CNAME permanece e deixa outros protocolos (SMB, LDAP) suscetíveis quando assinaturas e CBT não estão impostas.
Controles recomendados
- Exigir SMB signing em todos os servidores relevantes além de controladores de domínio.
- Forçar LDAP signing/LDAPS e aplicar Channel Binding Tokens quando suportado.
- Mandatar HTTPS com CBT para serviços HTTP internos e validar binding entre canais.
- Hardenizar infraestrutura DNS e considerar DoH/DoT para reduzir possibilidade de envenenamento em redes internas.
- Monitorar pedidos TGS incomuns e alertar sobre SPNs que não condizem com a topologia da organização.
O que falta e avaliação para equipes de segurança
Os documentos públicos não indicam exploração em massa no mundo real até a data da divulgação, mas a existência de PoC e a ampla base instalada de sistemas Windows — incluindo Windows 10/11 e versões Server citadas pelos pesquisadores — elevam o risco operacional. Equipes devem priorizar avaliação de exposição interna (possibilidade de ARP/DHCPv6 poisoning), endurecimento de serviços e verificação de patches, além de implementar monitoramento de autenticações Kerberos anômalas.
Fonte: Cymulate Research Labs; PoC publicado no GitHub.