Microsoft RAMP para na borda da sua autoridade certificadora

A Microsoft corrigiu o CVE-2026-54121 em 14 de julho. Os pesquisadores H0j3n e Aniq Fakhrul publicaram um proof of concept funcional 10 dias depois e o nomearam Certighost. Se seus servidores AD CS receberam a atualização cumulativa de julho, você está protegido. Se ainda estiverem nas versões de junho, estão expostos ao código de exploit público.

O ataque em si é curto. Um usuário padrão do domínio sem direitos de administrador manipula atributos em uma conta de máquina que controla, aciona uma lógica de fallback defeituosa dentro da autoridade certificadora e recebe um certificado assinado que autentica como controlador de domínio via PKINIT. A partir daí, DCSync gera o hash krbtgt e a capacidade de forjar Golden Tickets em toda a floresta. Requer uma Enterprise CA integrada ao Active Directory e a capacidade de criar ou controlar uma conta de computador, que a cota padrão de 10 contas de máquina concede a cada usuário do domínio.

A conta que iniciou a cadeia nunca teve privilégios elevados em nenhum momento. Esse é o detalhe que importa aqui, pois o roadmap da Microsoft para privileged access é construído em torno de um modelo de ameaça que este ataque evita.

Os três grupos de iniciativa do RAMP

O Plano de Modernização Rápida orienta a separar e gerenciar contas privilegiadas, melhorar a experiência de credenciais para quem as possui e implantar estações de trabalho administrativas. Abaixo disso estão os detalhes que a maioria das equipes de segurança está trabalhando agora: Privileged Identity Management (PIM), contas de acesso de emergência, categorização de funções Microsoft Entra por impacto, MFA e acesso sem senha para administradores, bloqueio de autenticação legada e Privileged Access Workstations.

A maior parte disso é trabalho do Microsoft Entra ID. O que o RAMP exige localmente se resume a contas de administrador separadas, estações de trabalho dedicadas para as pessoas que as usam e senhas únicas de administrador local. Certighost é um defeito no AD CS. Nenhum desses três o afeta.

RAMP não contém nenhuma iniciativa de autoridade certificadora. A Microsoft definiu isso deliberadamente, e as orientações indicam isso, baseando-se em um documento separado de implantação de Privileged Access Management. RAMP responde quem tem acesso elevado no seu ambiente. Como sua CA decide qual identidade vincular a um certificado é outra questão.

Certighost não será o último

A integridade na emissão de certificados é uma categoria que continua a gerar casos. A maioria dos métodos conhecidos são as técnicas de ataque ESC documentadas desde "Certified Pre-Owned", onde um modelo ou uma flag de CA permite que um usuário sem privilégios solicite um certificado para uma identidade que não possui. Certighost é diferente. A configuração do modelo é irrelevante. O defeito está na lógica de tratamento de solicitações da autoridade certificadora, em como ela resolveu qual objeto do diretório a solicitação realmente estava pedindo.

Essa distinção importa para o que você fará a respeito. Uma auditoria de modelo de certificado, que é o conselho padrão, não teria encontrado este.

O que os clientes entendem errado sobre isso

A maioria dos clientes considera o AD CS coberto porque alguém é responsável por ele. A autoridade certificadora fica com uma equipe de PKI ou infraestrutura, a equipe de identidade presume que isso significa que está gerenciado, e uma linha de reporte diferente é vista como um controle. Quando pergunto se eles auditaram suas configurações em relação a algum dos caminhos ESC, a resposta geralmente é que não estavam cientes deles.

As equipes que o possuem são avaliadas pela disponibilidade. A emissão tem sucesso, as renovações não expiram, a autenticação não falha, a CA está saudável em todas as métricas pelas quais são responsáveis. Ela permanece saudável em todas quando um usuário padrão registra um certificado para uma conta que não lhe pertence, e é exatamente por isso que ninguém percebe.

A governança não tem nada a que se agarrar

Os controles do RAMP ativam-se em torno de uma conta privilegiada. O Certighost nunca a toca até que a CA emita o certificado que a cria.

Não há uma conta intermediária para o PIM controlar nem autenticação de administrador para o MFA desafiar. A escalada e o pagamento ocorrem em uma única transação dentro do processamento da solicitação da autoridade certificadora, e a conta inicial do adversário permanece exatamente onde começou, no mesmo nível que qualquer outro usuário padrão do domínio. A cota de contas de máquina que torna possível a etapa de preparação também não é uma iniciativa RAMP.

RAMP aponta para Microsoft Defender for Identity (MDI), e o MDI oferece cobertura real de certificados. As avaliações de postura analisam modelos e configurações de CA para os caminhos conhecidos de escalonamento, e as verificações que examinam a própria CA exigem um sensor MDI no servidor AD CS. Também existe uma detecção nomeada para esta técnica que é acionada pelo padrão de solicitação.

Ambos valem a pena. Nenhum deles nega o pedido de inscrição. Uma avaliação de postura é um relatório de configuração que você lê periodicamente, e uma detecção é um alerta que chega enquanto a transação é concluída.

Assim, uma equipe de segurança pode concluir o RAMP de ponta a ponta, fazê-lo bem, executar o MDI junto e ainda assim não ter nenhum controle que avalie e recuse uma solicitação de certificado. A governança de Privileged Access Management e a integridade da autoridade certificadora são problemas separados. O RAMP resolve um deles, e eu diria que tratar um rollout concluído como cobertura para ambos é a interpretação errada mais comum do propósito desse roadmap.

Se alguém me disser que terminou o trabalho com RAMP, minha primeira pergunta é quem possui a autoridade certificadora. Se eles precisam descobrir, essa é a resposta. RAMP é o roteiro certo e concluí-lo significa que suas contas privilegiadas estão governadas, o que é um progresso real e não nada. Isso não diz nada sobre o sistema que pode criar uma dessas contas a partir da solicitação de certificado de um usuário padrão. Monitorar esse sistema é o mínimo. O que eu gostaria em seguida é algo que possa recusar a solicitação.

Bloqueando a solicitação de inscrição

Netwrix Threat Prevention (NTP) e Netwrix Threat Manager (NTM) atuam em ambos os lados. No monitoramento, o NTM cobre o mesmo campo apontado pelo RAMP via Defender for Identity, detectando uso indevido de AD CS e padrões de abuso de certificados em tempo real.

O lado da prevenção é o que os diferencia. O NTP avalia solicitações de inscrição contra padrões conhecidos de abuso do AD CS, incluindo as técnicas ESC1 a ESC7, e as bloqueia antes que um certificado exista, em vez de gerar um registro de que um foi emitido. Uma avaliação de postura indica que um modelo está errado e uma detecção indica que uma solicitação parecia errada, mas a aplicação é a única das três que encerra a transação.

Faça RAMP, depois verifique sua autoridade certificadora

Siga RAMP. O trabalho que ele pede vale a pena ser feito. Atualize seus servidores AD CS e defina a cota de contas de máquina para zero enquanto estiver lá.

Então, verifique sua autoridade certificadora, porque o RAMP não vai te levar até lá. Audite os modelos, e então faça a pergunta mais difícil por trás deles: quando uma conta padrão envia uma solicitação de inscrição afirmando uma identidade que não possui, o que no seu ambiente avalia essa solicitação, e algo a impede ou apenas a registra?