Active Directory Domain Services Elevation of Privilege Vulnerability

Falha de elevação de privilégio em Active Directory Domain Services que, combinada com Active Directory Certificate Services (AD CS), permite que um usuário de domínio autenticado — sem privilégios elevados — escale até Domain Admin ou SYSTEM. Ficou conhecida como "Certifried" e é crítica porque explora uma configuração padrão do AD (a quota que permite usuários comuns criarem contas de computador), não uma configuração exótica.

A raiz do problema é como o AD CS mapeia um certificado emitido para uma conta do Active Directory (CWE-295, validação de certificado insuficiente). Quando um certificado é emitido para autenticação de uma conta de computador, o mapeamento usado historicamente dependia do atributo dNSHostName do objeto de computador, e não de um identificador criptograficamente vinculado e imutável da conta. Qualquer usuário que tenha permissão de gravação sobre esse atributo em uma conta de computador que controla pode alterá-lo para o nome de um Domain Controller.

O ponto que destrava o ataque é o atributo de domínio ms-DS-MachineAccountQuota, que por padrão permite que qualquer usuário autenticado crie até um certo número de contas de computador no domínio (o padrão de fábrica é 10). Isso dá ao atacante uma conta de computador sob seu controle total — inclusive controle sobre o dNSHostName dela — sem precisar de nenhuma permissão administrativa prévia.

Com o dNSHostName da conta de computador controlada alterado para apontar para um Domain Controller, o atacante solicita ao AD CS um certificado de autenticação usando essa conta. O CA emite o certificado (o template usado para autenticação de máquina normalmente não valida se o solicitante é de fato o DC), e o certificado resultante fica mapeado, na prática, à identidade do Domain Controller. Isso permite autenticar-se ao domínio como se fosse o próprio DC, o que na prática equivale a controle total do domínio.

O CVSS 8.8 reflete PR:L (precisa de autenticação, mas de baixo privilégio) e AC:L — a complexidade de execução é baixa depois que o pré-requisito de ambiente (AD CS presente e template vulnerável, MachineAccountQuota > 0 ou permissão equivalente) está satisfeito.

Pré-requisito real, e o mais importante da página: o ambiente precisa ter Active Directory Certificate Services instalado com um template de certificado que permita autenticação de conta de computador, e o atacante precisa conseguir controlar (criar ou já ser proprietário de) uma conta de computador — o que a maioria dos domínios permite por padrão via MachineAccountQuota. Sem AD CS no ambiente, a cadeia de exploração simplesmente não existe, mesmo que a parte de AD DS (manipulação de dNSHostName) seja tecnicamente possível.

Na prática, o fluxo é: obter credenciais de usuário de domínio comum (phishing, credencial reutilizada, acesso já obtido em outra etapa de intrusão), criar ou usar uma conta de computador sob controle próprio, alterar o atributo de nome dessa conta para o de um Domain Controller do domínio, solicitar um certificado de autenticação via AD CS usando essa conta renomeada, e usar o certificado resultante para autenticar-se como o DC (via Kerberos PKINIT, por exemplo). O resultado final é controle administrativo completo do domínio a partir de uma conta de usuário comum.

A CISA incluiu a CVE no catálogo KEV confirmando exploração ativa. Existem PoC pública e módulo Metasploit, além de ferramentas de red team (como Certipy) amplamente usadas para automatizar a cadeia. A baixa complexidade técnica após satisfeitas as pré-condições, somada à combinação comum de MachineAccountQuota padrão + AD CS presente em muitos domínios corporativos, explica por que essa CVE se tornou um dos vetores de escalonamento mais usados em pentests e ataques reais contra Active Directory a partir de 2022.

A correção definitiva exige aplicar as atualizações de segurança da Microsoft do Patch Tuesday de maio de 2022 para AD DS/AD CS. Essas atualizações trocaram o mecanismo de mapeamento certificado-conta para usar um identificador de segurança forte, mudança implantada em fases: a partir de maio de 2022 os DCs passaram a registrar (modo compatível/auditoria) mapeamentos fracos sem bloqueá-los, e o enforcement completo — quando mapeamentos fracos passam a ser rejeitados por padrão — foi ativado em atualização posterior (KB5014754 documenta esse ciclo de compatibilidade e enforcement de certificate mapping). Ambientes que aplicaram apenas o primeiro patch e não avançaram para o modo de enforcement completo continuam expostos ao vetor.

Controles compensatórios reais quando a atualização não pode ser aplicada de imediato: reduzir ms-DS-MachineAccountQuota para 0 no domínio, removendo a capacidade padrão de usuários comuns criarem contas de computador; auditar e restringir templates de certificado do AD CS que permitem autenticação de máquina, retirando permissão de Enroll de usuários que não precisam dela; e revisar ACLs de objetos de computador para impedir que usuários não administrativos escrevam no atributo dNSHostName de contas que não são deles.

Não funciona como mitigação apenas monitorar sem corrigir o mapeamento: como o problema é estrutural no mecanismo de vinculação certificado-conta, detecção não substitui a correção do enforcement. Da mesma forma, desabilitar AD CS temporariamente resolve o vetor específico dessa CVE, mas não corrige a causa raiz em AD DS caso o CA volte a operar sem o enforcement de mapeamento forte.

Sinais a procurar: criação anômala de contas de computador por usuários que normalmente não administram máquinas (picos de eventos 4741 no log de segurança do DC); alterações no atributo dNSHostName de objetos de computador fora de processos de provisionamento conhecidos; solicitações de certificado no AD CS (eventos do serviço de certificação, IDs relacionados a emissão) para contas de computador recém-criadas ou renomeadas, especialmente quando o nome final coincide com um Domain Controller; e uso de ferramentas como Certipy, cujo tráfego LDAP de enumeração e manipulação de atributos de conta de computador deixa rastro em logs de auditoria de diretório se a auditoria de objetos estiver habilitada.

Se a auditoria detalhada de alterações de atributo e de emissão de certificados não estiver habilitada previamente, não há sinal retroativo confiável — a exploração em si (alteração de atributo seguida de emissão de certificado) é rápida e não deixa artefato persistente óbvio fora dos logs de auditoria específicos, que muitos ambientes não coletam por padrão.