Microsoft corrige Certighost e mostra como conta virava dona do domínio

Microsoft fechou uma falha de alta gravidade no Active Directory Certificate Services, o serviço que emite identidades digitais dentro de redes Windows corporativas. A vulnerabilidade ganhou o identificador CVE 2026 54121 e o apelido de Certighost. Na prática, ela permitia que um usuário com acesso básico solicitasse um certificado válido em nome de um Controlador de Domínio. Em seguida, quem tinha esse certificado passava a mandar na floresta inteira.

A dupla de pesquisadores H0j3n e Aniq Fakhrul reportou o problema em maio de 2026. A correção saiu em 14 de julho. Dez dias depois, os mesmos pesquisadores publicaram a análise técnica e uma prova de conceito funcional. Agora a equipe de Inteligência de Ameaças da Microsoft reforçou o alerta e liberou orientações extras de monitoramento.

Microsoft: Quando a autoridade certificadora acredita no endereço que o pedido informa

O ponto fraco estava em um mecanismo de contingência do fluxo de emissão, apelidado internamente de chase. Ele existe para casos em que a autoridade certificadora falha ao localizar a identidade de quem pediu o certificado. Nesse cenário, a CA consultava um servidor de diretório secundário indicado no próprio pedido. O detalhe importante aparece aqui: esse endereço seguia sem qualquer validação de legitimidade.

Portanto, bastava apontar a consulta para uma infraestrutura controlada pelo atacante. A partir daí, o servidor falso devolvia os atributos de diretório que o invasor quisesse. A CA lia aquilo como verdade e assinava. Como resultado, saía um certificado autêntico com identidade de Controlador de Domínio.

Do enrollment básico ao segredo krbtgt

Vale entender o encadeamento, porque ele explica a gravidade alta. Primeiro, o atacante entra com uma conta comum de domínio. Depois, ele obtém o certificado forjado. Então, autentica na rede como se fosse um DC.

E é nesse momento que a conversa muda de patamar. Contas de Controlador de Domínio carregam direitos de replicação de diretório. Ou seja, elas podem pedir segredos de qualquer conta do ambiente. Inclusive o segredo krbtgt, que sustenta a emissão de tickets Kerberos.

Quem tem o krbtgt escreve os próprios ingressos de acesso. Assim, a persistência deixa de depender de senha, de sessão ou de endpoint comprometido. Em resumo, o invasor vira parte da infraestrutura de confiança.

A assinatura saiu perfeita e a identidade era falsa

Jason Soroko, pesquisador sênior da Sectigo, resumiu bem o caso. Segundo ele, a criptografia cumpriu o papel dela. A CA assinou corretamente aquilo que recebeu. O erro morava na etapa anterior, quando o sistema aceitou dados de diretório sem prova de origem.

Essa distinção interessa demais para quem escreve código. Afinal, times gastam meses discutindo algoritmo, tamanho de chave e rotação. Enquanto isso, a fonte que alimenta a decisão de identidade fica sem revisão. Aqui vale a regra antiga do garbage in, garbage out aplicada a PKI.

O patch chegou e o PoC também – Microsoft

A Microsoft informou que segue sem registro de exploração ativa até o momento. Ainda assim, a empresa recomendou prioridade máxima na aplicação da atualização. O motivo é direto: código público reduz o custo de tentativa para qualquer oportunista.

A correção adicionou uma verificação prévia no Active Directory. Agora a autenticidade do servidor consultado passa por checagem antes de qualquer emissão. Dessa forma, o caminho de contingência deixa de ser um canal aberto para dados arbitrários.

Checklist para quem administra CA corporativa

Comece pelo inventário. Levante todos os servidores com a função Enterprise CA ativa, inclusive os esquecidos em laboratório e homologação. Em ambientes antigos, esse levantamento costuma revelar surpresas.

Depois, aplique o pacote de julho em cada um deles. Além disso, revise quem tem permissão de enrollment nos templates disponíveis. Templates que aceitam SAN definido pelo solicitante merecem atenção redobrada.

Em seguida, ligue a auditoria de emissão. Logs relevantes ficam nos eventos 4886 e 4887 do próprio serviço. Vale cruzar essas emissões com o inventário de contas de máquina. Certificados de DC emitidos para solicitantes improváveis são o sinal mais claro de abuso.

Por fim, monitore autenticação por certificado nos DCs. Eventos 4768 e 4769 ajudam a flagrar tickets pedidos logo após uma emissão suspeita. E vale rodar ferramentas de mapeamento de PKI para enxergar caminhos de escalada que já existiam antes do Certighost.

Microsoft: O que devs levam desse caso

O Certighost interessa muito além do time de infraestrutura. Ele descreve um padrão que aparece em qualquer sistema distribuído: a confiança delegada a uma fonte que ninguém valida.

Pense em fluxos de OIDC com discovery dinâmico. Pense em webhooks que aceitam URL de callback vinda do payload. Pense em serviços internos que confiam em um header porque a requisição veio da rede privada. O formato muda e a lógica se repete.

Portanto, a pergunta útil para levar ao próximo code review é simples. Quando o caminho feliz falha, para onde o sistema recorre? E quem valida a resposta que volta desse caminho alternativo?

Emissão de identidade é código crítico. Trate cada fallback com o mesmo rigor do fluxo principal.

Acompanhe nosso perfil no Instagram!