Certighost a vulnerabilidade de AD CS que poderia converter um usuário de domínio no Controlador de Domínio

Em 24 de julho, tornou-se pública uma prova de conceito que explora uma vulnerabilidade em Active Directory Certificate Services (AD CS) —bautizada por seus descubridores como Certighost — e que permite a um utilizador de domínio com poucos privilégios obter um certificado que identifique um Controlador de Domínio (Domain Controller) e autenticar-se como essa máquina. A gravidade não é simbólica: ao autenticar como um DC se abrem as portas para solicitar segredos de contas por DCSync, incluindo o krbtgt, o que pode desembocar em uma compromissão total do domínio mediante tickets forjados e persistência a longo prazo.

A Microsoft classificou o problema como uma falha de autorização e o designou como CVE-2026-54121 Com uma pontuação CVSS de 8.8; o adesivo para AD CS foi publicado em 14 de julho. Ao contrário de muitas vulnerabilidades que requerem privilégios elevados ou interação do usuário, este vetor exige somente acesso de rede e uma conta de domínio padrão. Nos testes públicos, os pesquisadores usaram uma conta do grupo Domain Users e apoiaram-se em comportamentos padrão como a quota ms-DS-MachineAccountQuota (10) para criar ou reutilizar contas de equipe.

O núcleo técnico reside na lógica de “chase” do enrolamento de AD CS: quando uma CA não pode resolver a informação do sujeito, o protocolo permite que o pedido indique um cdc (o servidor de Active Directory a contactar) e rmd (o objeto de máquina a resolver). Os atacantes podem enganar a CA para comunicar com serviços SMB/LDAP falsos, relé a autenticação ao DC real via Netlogon e devolva atributos como objectSid e dNSHostName do objetivo, validando assim identidade e provocando a CA assinar um certificado com identidade de DC. O teste de conceito automatiza este encadeamento, levanta escutas em portos 445/389 e produz um PFX e um cache de credenciais Kerberos PKINIT capazes de autenticar-se como o Controlador de Domínio.

Que exista uma PoC pública torna o risco iminente: embora até à data não tenham sido verificadas explorações na natureza segundo relatos primários, a disponibilidade do exploit significa que equipamentos de resposta poderão ver ataques ativos rapidamente. Além disso, o vetor explora configurações muito comuns: CA de empresa (Enterprise CA), modelo Machine por defeito e acessibilidade da CA para serviços SMB/LDAP do atacante.

A Microsoft corrigiu a falha adicionando validações antes de seguir uma chase; a atualização introduz verificações que rejeitam literales IP, nomes demasiado longos e metacaracteres LDAP, exige exatamente um objeto de equipe cujo nome DNS coincida e que tenha o flag SERVER_TRUST_ACCOUNT, e realiza comparações de SID para evitar substituições de objetos. Esta verificação está incluída no binário da CA e é a mitigação correta e definitiva, pelo que As organizações com a Enterprise CA devem instalar os adesivos da Microsoft nos hosts de AD CS imediatamente. Para referência geral sobre AD CS e sua arquitetura consulte a documentação oficial da Microsoft em https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/ad-cs-overview.

Quando aplicar adesivos não for possível imediatamente, os autores documentaram uma mitigação temporária que desactiva a flag de chase na política da CA: executar certutil para modificar EditFlags e reiniciar o serviço CertSvc. Essa mudança pode interromper fluxos legítimos de enrolamento, pelo que os pesquisadores e a Microsoft recomendam testá-lo em um ambiente controlado antes de o colocar em produção. A utilidade certutil e seus parâmetros estão documentados pela Microsoft em https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil.

Em termos de detecção e resposta, há ações concretas que devem ser priorizadas: auditar a criação recente de contas de equipe e mudanças na ms-DS-MachineAccountQuota, revisar os registros da CA por pedidos de enrolamento que utilizem atributos cdc/rmd, monitorar atividade PKINIT incomum e operações DCSync ou pedidos LDAP anormais. Se houver indícios de compromisso, a resposta deve incluir a rotação do krbtgt (idealmente duas vezes por segurança) e a investigação forense de acesso à CA e aos DC afetados.

Para além do sistema transdérmico e monitorizar, é conveniente tomar medidas de hardening: restringir que hosts podem comunicar com a CA em portos SMB/LDAP, limitar os direitos de inscrição em modelos de certificado, rever delegações que permitam criar contas de equipamento e segmentar as CA para que não estejam directamente acessíveis a partir de estações de trabalho de baixo privilégio. A defesa em profundidade reduz a probabilidade de um usuário com permissões mínimas poder atingir a cadeia completa de exploração.

A comunidade deve seguir a evolução do caso em fontes de referência técnica; o registo oficial da vulnerabilidade na base de dados nacional de vulnerabilidades pode ser consultado em https://nvd.nist.gov/vuln/detail/CVE-2026-54121. Também é importante manter-se alerta contra atualizações e guias adicionais da Microsoft ou da CERT nacionais que proporcionem indicadores de compromisso e procedimentos de remediação específicos.

Para equipamentos de TI e segurança, a recomendação é clara: priorizar a instalação do adesivo em todos os servidores AD CS, testar cuidadosamente qualquer mitigação temporária como a desativação de chase, e executar uma caça de anomalias centrada em certificados de máquina não habituais, criação de contas de equipamento e sinais de uso de DCSync. A combinação de patches, monitoramento e endurecimento da CA reduz significativamente o risco de uma vulnerabilidade como Certighost derive em um compromisso de domínio completo.