ESC9 vs. ESC16: mesma falha, raio de impacto diferente
Nov 9, 2026
ESC9 e ESC16 são a mesma vulnerabilidade do AD CS em dois níveis. Ambos impedem a autoridade certificadora de adicionar a extensão de segurança SID aos certificados, então um controlador de domínio precisa recorrer a um mapeamento fraco baseado em nome. ESC9 é uma flag em um modelo de certificado. ESC16 é um valor de registro na CA que remove a extensão de tudo o que ela emite. Uma auditoria limpa de modelos não cobre ESC16, então verifique a CA e confirme que seus controladores de domínio aplicam mapeamento forte.
ESC9 e ESC16 são duas das técnicas numeradas de escalonamento (ESC) catalogadas para Active Directory Certificate Services (AD CS), e são a mesma vulnerabilidade em diferentes escopos. Ambas removem a extensão de segurança do identificador de segurança (SID) dos certificados emitidos, permitindo que um invasor se faça passar por outra conta por meio de mapeamento fraco de certificados. ESC9 faz isso em um único modelo de certificado. ESC16 faz isso em todos os certificados emitidos por uma autoridade certificadora (CA).
Se você corrigiu o ESC9 há alguns anos, isso não diz nada sobre o ESC16.
O que é ESC9?
ESC9 é uma configuração de modelo. Quando CT_FLAG_NO_SECURITY_EXTENSION está definido no atributo msPKI-Enrollment-Flag de um modelo, os certificados emitidos a partir desse modelo não possuem a extensão SID (szOID_NTDS_CA_SECURITY_EXT). Essa extensão permite que um controlador de domínio (DC) vincule um certificado a uma conta específica. Sem ela, o DC recorre ao mapeamento pelo nome principal do usuário (UPN).
O ataque precisa de três coisas: um atacante com acesso de gravação ao UPN de uma conta vítima (GenericWrite é suficiente), direitos de inscrição em um modelo de client-authentication com a flag ativada e um DC que não aplica mapeamento forte de certificado. O atacante altera o UPN da vítima para coincidir com uma conta privilegiada, se inscreve, restaura o UPN e autentica-se com o certificado como usuário privilegiado.
Oliver Lyak documentou o ESC9 em agosto de 2022, e muitos scanners podem encontrá-lo, incluindo Netwrix PingCastle. A lista de verificação abaixo mostra como verificar seus próprios modelos.
O que é ESC16?
ESC16 chega ao mesmo resultado sem tocar em um modelo. Se o OID 1.3.6.1.4.1.311.25.2, que é a extensão de segurança szOID_NTDS_CA_SECURITY_EXT SID, estiver listado no valor do registro DisableExtensionList do módulo de política da CA, a CA para de adicionar a extensão SID a tudo o que emite. Cada modelo por trás dessa CA agora se comporta como se a flag ESC9 estivesse ativada, incluindo modelos que ninguém revisa há anos.
Um ambiente pode acabar com essa configuração por vários motivos: uma correção de compatibilidade para uma ferramenta de terceiros, uma migração ou um aplicativo legado que não lida com a extensão. É uma única entrada de registro facilmente ignorada, que cancela silenciosamente a proteção que você construiu modelo por modelo.
A configuração não é um atributo de modelo. É uma configuração de CA, e muitas revisões de higiene de certificados nunca abrem as configurações do módulo de política da própria CA. Uma organização pode estar limpa em todos os modelos, ter o relatório para comprovar isso e ainda assim estar exposta através da CA. Se você fez uma varredura para ESC9 anos atrás e não verificou suas CAs desde então, um invasor ainda pode realizar o mesmo ataque de personificação através do ESC16.
O mapeamento forte de certificados protege você?
Parcialmente. Ambas as técnicas dependem do DC aceitar mapeamentos fracos, e os DCs que aplicam vinculação forte de certificado as neutralizam. Desde as atualizações do Windows de setembro de 2025, os DCs corrigidos executam a aplicação total e a configuração do modo de compatibilidade não é mais suportada, então um domínio totalmente corrigido bloqueia ESC9 e ESC16 sem proteção. Ainda restam duas lacunas: qualquer DC que perdeu essas atualizações e cadeias onde o invasor pode fornecer seu próprio SID na solicitação do certificado, como ESC16 combinado com ESC6 ou ESC15. Verifique a aplicação em cada DC e também verifique a CA.
Como você verifica e corrige ambos?
Você precisa de duas verificações, porque ESC9 está nos templates e ESC16 está no CA.
Verificar ESC9 (modelos de certificado)
- Execute uma varredura PingCastle.
- Abra o relatório e procure por CT_FLAG_NO_SECURITY_EXTENSION (o risco é A-CertTempNoSecurity). Procure o texto "Pelo menos um modelo de certificado tem a flag CT_FLAG_NO_SECURITY_EXTENSION definida."
- Se esse texto não estiver presente, nenhum dos modelos escaneados possui a marca. Se estiver, remova a marca dos modelos afetados.
Verifique ESC16 (a CA)
Em cada CA, execute:
certutil -getreg policy\DisableExtensionList
Se o OID 1.3.6.1.4.1.311.25.2 aparecer na saída, essa CA está removendo a extensão SID de tudo que emite. Remova-o da lista, a menos que tenha um motivo documentado.
Para corrigir, remova o OID e reinicie o Certificate Services para que a alteração tenha efeito:
certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2
net stop certsvc
net start certsvc
Execute certutil -getreg policy\DisableExtensionList novamente para confirmar que o OID desapareceu. Certificados já emitidos sem a extensão permanecem assim, então revise-os se suspeitar que a configuração foi abusada. Se um aplicativo precisava da configuração, teste-o antes de implementá-la amplamente.
Em seguida, confirme a aplicação: verifique se seus DCs estão aplicando um mapeamento forte de certificados, pois isso reduz ambas as técnicas. Em um DC com atualizações atuais, essa é a configuração padrão. Para o restante da exposição da sua CA, incluindo ESC8 na inscrição web, revise as configurações arriscadas de AD CS que frequentemente aparecem junto com essas duas.
Como você detecta a próxima mudança?
Para ESC9 em diante: a flag do modelo está no Active Directory, o que significa que uma alteração nela é uma alteração em um objeto AD. Netwrix Threat Prevention monitora as alterações do AD em tempo real e pode bloqueá-las, então alguém que definir CT_FLAG_NO_SECURITY_EXTENSION em um modelo pode ser impedido antes que tenha efeito, não encontrado na próxima avaliação.
Para ESC16 daqui para frente: a configuração está no registro no servidor CA, não no AD, então precisa de cobertura própria: auditoria do registro nos hosts CA que alimentam seu SIEM, além da verificação periódica acima. Netwrix também correlaciona logons baseados em certificado com emissão e sinaliza cenários de extensão SID ausente, então o abuso da configuração aparece mesmo que a alteração do registro passe despercebida.
Veja como Netwrix protege o AD CS.
Compartilhar em
Saiba Mais
Sobre o autor
Joe Dibley
Pesquisador de Segurança
Pesquisador de Segurança na Netwrix e membro da Equipe de Pesquisa de Segurança da Netwrix. Joe é um especialista em Active Directory, Windows e uma ampla variedade de plataformas de software empresarial e tecnologias, Joe pesquisa novos riscos de segurança, técnicas de ataque complexas e as respectivas mitigações e detecções.
Saiba mais sobre este assunto
ESC8 ainda é a descoberta mais comum de AD CS que vemos
Microsoft RAMP para na borda da sua autoridade certificadora
Comprometimento de email empresarial: como a IA muda os ataques BEC e como preveni-los
Você só precisa de tokens de IA para virar hacker
O que é execução remota de código (RCE)? Como a IA acelera a exploração e como limitar os danos