ADCS ESC9, ESC10, ESC11: Escalada de Certificados

O que é a Escalada de Certificados ADCS ESC9, ESC10, ESC11

A escalada de certificados ADCS ESC9, ESC10, ESC11 é o conjunto de técnicas de escalada de privilégios do Active Directory Certificate Services (AD CS) publicadas após a pesquisa original "Certified Pre-Owned", que introduziu ESC1 a ESC8. Enquanto os primeiros oito caminhos giram em torno de configurações incorretas de template, configurações perigosas da CA e web enrollment por HTTP, ESC9, ESC10 e ESC11 têm como alvo a camada que decide se um certificado realmente é mapeado para a conta correta: a extensão de segurança incorporada ao certificado, a configuração de mapeamento de certificados do controlador de domínio e a imposição de criptografia na interface RPC de enrollment da CA.

ℹ️

ℹ️ Nota: Este artigo pressupõe a base ESC1-ESC8. Veja Caminhos de ataque ADCS: como erros em certificados viram caminhos de escalada no Active Directory se você precisar dessa base primeiro — esse artigo cobre exclusivamente ESC1 a ESC8 (o próprio slug já diz isso), o que é exatamente a lacuna que este artigo fecha.

As três técnicas existem por causa da mesma mudança subjacente: a atualização da Microsoft de maio de 2022 (KB5014754) introduziu a extensão de segurança szOID_NTDS_CA_SECURITY_EXT, que incorpora o SID do principal solicitante em um certificado emitido, para que o KDC possa vincular fortemente esse certificado a uma única conta. ESC9, ESC10 e ESC11 são três formas diferentes pelas quais essa vinculação pode falhar em proteger um ambiente — uma no nível do template, uma no nível do controlador de domínio/Schannel e uma no nível de transporte RPC.

Como funciona

ESC9 — Sem Extensão de Segurança

O ESC9 ocorre quando o msPKI-Enrollment-Flag de um template de certificado inclui o bit CT_FLAG_NO_SECURITY_EXTENSION (0x80000). A documentação do Certify da SpecterOps descreve isso como a supressão da extensão szOID_NTDS_CA_SECURITY_EXT em qualquer certificado emitido a partir desse template. O efeito é que o processo de mapeamento de certificados se comporta como se StrongCertificateBindingEnforcement estivesse definido como 0, independentemente do valor real do registro no controlador de domínio, porque não há SID no certificado para verificar.

Isoladamente, esse flag não é explorável. Ele se torna ESC9 quando combinado com uma segunda condição que os atacantes já procuram em templates adjacentes a ESC1-ESC8: um principal de baixo privilégio com GenericWrite (ou equivalente) sobre outra conta. Um atacante com GenericWrite sobre uma conta vítima pode alterar o userPrincipalName dessa conta para corresponder a um alvo privilegiado (por exemplo, o sAMAccountName de um administrador), fazer enroll de um certificado a partir do template marcado com ESC9 como a conta vítima, e autenticar-se como o alvo imitado — porque o certificado resultante não carrega extensão SID que contradiga o UPN falsificado.

ESC10 — Mapeamento Fraco de Certificados (em todo o domínio)

O ESC10 produz o mesmo resultado prático que o ESC9 — uma autenticação que se resolve para a conta errada —, mas a configuração incorreta está no controlador de domínio ou no Schannel, não em um único template de certificado. A SpecterOps e a pesquisa da comunidade (incluindo o wiki do Certify e análises independentes de AD CS) descrevem duas variantes:

Caso A — O valor de registro CertificateMappingMethods do Schannel no controlador de domínio inclui mapeamento por UPN. Um atacante que consiga escrever no userPrincipalName de uma conta vítima (novamente via GenericWrite ou similar) o define para corresponder a um principal alvo e, em seguida, se autentica via Schannel (autenticação TLS de cliente) com qualquer certificado cujo subject ou SAN reflita o UPN falsificado.
Caso B — StrongCertificateBindingEnforcement no controlador de domínio está explicitamente definido como 0 (modo de compatibilidade) em vez do padrão de imposição, de modo que uma extensão SID ausente ou não correspondente é aceita em vez de rejeitada, para todos os templates e todos os principais — não apenas para um template marcado, como no ESC9.

A diferença operacional-chave em relação ao ESC9: o ESC10 não está limitado a um único template de certificado, portanto normalmente expande o conjunto de contas exploráveis para todo o domínio.

⚠️

⚠️ Atenção: O ESC10 compartilha sua causa raiz com um tema de hardening mais amplo — a força do mapeamento de certificados do controlador de domínio. Para a mecânica completa do mapeamento fraco versus forte, eventos do KDC e remediação do Schannel, veja Mapeamento fraco de certificados no AD CS: por que a vinculação forte importa.

ESC11 — Relay de NTLM para a Interface RPC da CA

O ESC11 é o irmão em transporte RPC do ESC8 (relay de NTLM para web enrollment por HTTP). As Autoridades Certificadoras expõem a interface RPC ICertPassage (MS-ICPR) para solicitações de certificado. De acordo com a documentação do Certify da SpecterOps e pesquisa independente da Compass Security, se essa interface impõe criptografia no nível de pacote é controlado pelo flag de interface IF_ENFORCEENCRYPTICERTREQUEST na CA. Esse flag é habilitado por padrão, mas é frequentemente desabilitado por compatibilidade com clientes mais antigos que não conseguem negociar RPC_C_AUTHN_LEVEL_PKT_PRIVACY.

Quando o flag está desativado, um atacante que force uma vítima (por exemplo, uma conta de máquina de controlador de domínio) a se autenticar via NTLM pode fazer relay dessa autenticação para a interface RPC da CA — contornando as mesmas proteções de web enrollment que o ESC8 cobre, mas via RPC em vez de HTTP, e independentemente de o web enrollment sequer estar instalado.

A Cadeia de Ataque

Técnica	Pré-requisito	Caminho de abuso	Impacto
ESC9	`GenericWrite` sobre uma conta vítima + um template com `CT_FLAG_NO_SECURITY_EXTENSION`	Reescrever o UPN da vítima para o `sAMAccountName` de um alvo, fazer enroll, autenticar-se como o alvo	Imitar uma conta alvo específica
ESC10 (Caso A)	`GenericWrite` sobre uma conta vítima + `CertificateMappingMethods` do Schannel do DC permite mapeamento por UPN	Reescrever o UPN da vítima, autenticar-se via certificado de cliente Schannel	Imitar qualquer conta com UPN correspondente, em todo o domínio
ESC10 (Caso B)	`StrongCertificateBindingEnforcement` = 0 no controlador de domínio	Qualquer certificado sem a extensão SID é aceito para mapeamento	Aceitação de mapeamento fraco em todo o domínio
ESC11	`IF_ENFORCEENCRYPTICERTREQUEST` da CA não definido	Forçar autenticação NTLM de um alvo, fazer relay para o endpoint RPC (ICPR) da CA, solicitar um certificado como o alvo	Obter um certificado para a identidade relayada, muitas vezes um controlador de domínio

🚨 Perigo: As três técnicas podem terminar no mesmo resultado que ESC1-ESC8 — um certificado utilizável para autenticação Kerberos PKINIT como Domain Admin ou como um controlador de domínio. A escalada via GenericWrite encadeia diretamente em Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin. A etapa de relay do ESC11 usa as mesmas primitivas de coerção/relay cobertas em Ataques NTLM Relay: Sequestrar Autenticacao Sem Crackear Senhas.

Detecção

Indicador	Event ID / Fonte	O que procurar
Mapeamento de certificado fraco ou falho no logon	Log de Sistema do controlador de domínio, Event ID 39 (sem mapeamento forte), 40 (certificado anterior à conta), 41 (SID incompatível)	Eventos de auditoria do KB5014754 disparando para contas privilegiadas, estações administrativas ou controladores de domínio — não apenas ruído de compatibilidade legada
Template sem extensão de segurança	Inventário de templates do AD CS	`msPKI-Enrollment-Flag` inclui `CT_FLAG_NO_SECURITY_EXTENSION` (0x80000) em algum template com EKU de autenticação
Downgrade de mapeamento em todo o domínio	Registro do controlador de domínio	`HKLM\SYSTEM\CurrentControlSet\Services\Kdc\StrongCertificateBindingEnforcement` = 0 (Compatibilidade) em vez do valor imposto; `CertificateMappingMethods` (Schannel, `HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL`) reativando mapeamento por UPN/Subject-Issuer
Mudanças de UPN antes de solicitações de certificado	Log de emissão da CA do AD CS + auditoria de mudanças no diretório (Event ID 4738 no DC)	Uma modificação de `userPrincipalName` imediatamente seguida por uma solicitação de certificado (Event ID 4886/4887 na CA) na mesma sessão
Criptografia da interface RPC não imposta	Registro da CA via `certutil -config "<CA>" -getreg CA\InterfaceFlags`	O valor retornado não inclui `IF_ENFORCEENCRYPTICERTREQUEST` (0x200) — indica que o endpoint RPC do ICPR aceita solicitações não criptografadas/não assinadas e é passível de relay
Solicitações de certificado anômalas via RPC	Rede / servidor da CA	Conexões RPC/DCOM de entrada inesperadas ao servidor da CA vindas de hosts diferentes dos clientes de enrollment conhecidos, correlacionadas com tentativas de coerção de autenticação NTLM

💡

💡 Dica: O Microsoft Defender for Identity oferece uma avaliação de postura de segurança dedicada, "Impor criptografia para a interface de enrollment de certificados por RPC", que sinaliza diretamente CAs vulneráveis a ESC11 — use-a se o Defender for Identity estiver implantado, em vez de depender apenas de verificações manuais via certutil.

Remediação

Remover CT_FLAG_NO_SECURITY_EXTENSION dos templates (ESC9). Audite o msPKI-Enrollment-Flag de cada template de certificado. Qualquer template capaz de autenticação com esse flag definido deve ter o flag removido, a menos que exista um motivo documentado e revisado — e esse motivo não deve incluir direitos de enrollment não privilegiados.
Mover os controladores de domínio para Full Enforcement (ESC10 Caso B). Confirme que StrongCertificateBindingEnforcement não está fixado em 0. Segundo o cronograma da KB5014754 da Microsoft, os controladores de domínio sem um valor de registro explícito passaram para o modo Full Enforcement a partir da atualização de fevereiro de 2025, e a própria chave de registro deixou de ser respeitada após a atualização de setembro de 2025 — portanto, um 0 explícito deixado no lugar é um downgrade deliberado que deve ser encontrado e justificado.
Desabilitar métodos fracos de mapeamento do Schannel (ESC10 Caso A). Revise CertificateMappingMethods em cada controlador de domínio e em qualquer servidor que finalize TLS com certificado de cliente. Métodos fracos (Subject/Issuer, apenas Issuer, UPN) devem permanecer desabilitados; apenas métodos fortes (S4U2Self, S4U2Self explícito) devem ser permitidos, a menos que uma aplicação legada específica e documentada exija outra coisa.
Impor criptografia RPC em cada CA (ESC11). Execute certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST em cada CA e reinicie em seguida o serviço Certificate Services (net stop certsvc && net start certsvc). Valide depois com certutil -config "<CA>" -getreg CA\InterfaceFlags e confirme que 0x200 está presente.
Fechar a exposição subjacente de GenericWrite. Tanto o ESC9 quanto o ESC10 Caso A exigem que um atacante já detenha acesso de escrita ao userPrincipalName de uma conta vítima. Revise ACLs em busca de concessões excessivamente amplas de GenericWrite, GenericAll, WriteProperty ou equivalentes a Validated-SPN em objetos de usuário, especialmente de grupos de helpdesk ou provisionamento, como parte da mesma rodada de remediação.
Testar novamente após cada mudança. Mudanças no mapeamento de certificados e na criptografia RPC podem quebrar clientes legados (versões antigas do Windows, clientes RPC não Windows, middleware de smart card mais antigo). Implante as mudanças por meio de um grupo piloto representativo antes de impor em todo o domínio, e mantenha a revisão de eventos do KDC/Schannel da seção de detecção rodando durante o rollout para confirmar que nenhuma autenticação legítima começa a falhar.

✅ Vitória rápida: Se o tempo hoje só permitir uma ação, execute a verificação certutil -config "<CA>" -getreg CA\InterfaceFlags em cada CA. O ESC11 não exige privilégios de diretório para ser explorado — apenas acesso de rede e uma primitiva de coerção —, o que o torna o caminho de menor barreira dos três.

Como o EtcSec Detecta Isso

As verificações de auditoria de AD do EtcSec mapeiam diretamente cada técnica: ESC9_NO_SECURITY_EXTENSION sinaliza templates de certificado que carregam CT_FLAG_NO_SECURITY_EXTENSION em um template capaz de autenticação, ESC10_WEAK_CERTIFICATE_MAPPING revisa a configuração de mapeamento de certificados do controlador de domínio e do Schannel em busca de configurações de modo de compatibilidade, e ESC11_ICERT_REQUEST_ENFORCEMENT verifica a imposição de criptografia RPC em cada CA descoberta. Como o ESC9 e o ESC10 Caso A dependem de um pré-requisito do tipo GenericWrite, o EtcSec também correlaciona esses achados com a superfície mais ampla de exposição de ACL, para que um flag de template ou uma configuração de registro seja priorizado conforme o atacante realmente tenha um caminho para explorá-lo — e não sinalizado isoladamente.

Se você está construindo uma revisão completa de AD CS em vez de verificar uma técnica de cada vez, combine este artigo com Como auditar a segurança do Active Directory: checklist prática para equipes internas para a checklist completa de Tier 0 na qual esses caminhos se encaixam.

ℹ️

ℹ️ Nota: O EtcSec verifica automaticamente a exposição a ESC9, ESC10 e ESC11 em cada auditoria de AD. Execute uma auditoria gratuita para verificar seu ambiente.

ADCS ESC9, ESC10, ESC11: Escalada de Certificados Além de ESC1-ESC8