ADCS ESC2, ESC3, ESC5, ESC7: Escalada de Certificados entre os Mais Conhecidos

O Que É ADCS ESC2 ESC3 ESC5 ESC7 Escalada de Certificados

ADCS ESC2 ESC3 ESC5 ESC7 escalada de certificados situa-se na lacuna entre duas extremidades já bem cobertas da superfície de ataque do Active Directory Certificate Services (AD CS). A investigação Certified Pre-Owned, da SpecterOps, identificou oito técnicas, de ESC1 a ESC8, e investigações posteriores acrescentaram ESC9, ESC10 e ESC11. Este corpus já cobre ambas as extremidades: Caminhos de Ataque ADCS Explicados aborda ESC1, ESC4, ESC6 e ESC8, e ADCS ESC9, ESC10, ESC11: Caminhos de Escalada de Certificados Além de ESC1-ESC8 aborda as técnicas da camada de binding publicadas após o KB5014754. ESC2, ESC3, ESC5 e ESC7 são as quatro técnicas da numeração original da SpecterOps que nenhum dos dois artigos cobre.

Essa lacuna importa porque estas quatro técnicas não são um resto aleatório e encadeiam-se nos mesmos caminhos de ataque do Active Directory que uma análise ao estilo BloodHound mapeia para qualquer outra técnica de Tier 0. ESC2 e ESC3 são, tal como ESC1, técnicas ao nível do template — mas em vez de um template que revela como quem um certificado se pode autenticar, revelam para que pode ser usado um certificado depois de emitido — seja para qualquer finalidade, seja para a finalidade específica de solicitar certificados em nome de outra pessoa. ESC5 e ESC7 são, tal como ESC4, técnicas de controlo de acesso — mas em vez de uma ACL num único template de certificado, incidem sobre os objetos e permissões que controlam todos os templates e todos os certificados que a CA alguma vez emitirá: o próprio controlo de acesso da CA, e os contentores de PKI no Active Directory que guardam os templates, os registos da CA e a lista de CAs em que os controladores de domínio confiam para autenticação.

Um ambiente que já corrigiu todos os achados de ESC1, ESC4, ESC6 e ESC8, e todos os achados de ESC9, ESC10 e ESC11, pode ainda assim ter um caminho ativo para Domain Admin através destas quatro técnicas — porque nenhuma das outras verificações analisa o âmbito das EKUs, a delegação de enrollment agents, ou o controlo de acesso ao nível dos objetos de PKI e da CA.

Como Funciona

ESC2 — Templates com "Any Purpose" ou Sem EKU

ESC2 é um template de certificado cuja Extended Key Usage (EKU) é a OID Any Purpose (2.5.29.37.0) ou não tem nenhuma EKU definida — o que o Windows trata como um template equivalente a uma CA subordinada, utilizável para qualquer finalidade. Segundo a documentação do Certify, da SpecterOps, explorar isto exige que todas as seguintes condições se verifiquem em simultâneo: o principal do atacante tem direitos de enrollment ao nível da CA, o mesmo principal tem direitos de enrollment no template específico, o template não exige aprovação de manager, o template não exige assinaturas autorizadas (co-assinadas), e a EKU do template é Any Purpose ou está totalmente ausente.

Quando estas condições se alinham, o atacante regista um certificado a partir do template e obtém uma credencial que o Windows aceita para qualquer finalidade que consuma certificados — incluindo, segundo a documentação da SpecterOps, o mesmo papel de "Certificate Request Agent" de que o ESC3 depende. Por outras palavras, um template ESC2 pode ser usado para iniciar um ataque de enrollment agent ao estilo ESC3, mesmo que nunca declare explicitamente a EKU Certificate Request Agent. É também por isso que os achados de ESC2 devem ser sempre confrontados com os outros templates publicados pela CA antes de serem dispensados como de baixa gravidade: um certificado Any Purpose só é tão perigoso quanto aquilo que mais a CA permite que ele resgate.

ESC3 — Templates de Enrollment Agent (Cadeia de Dois Templates)

ESC3 é uma cadeia de dois templates, não uma única má configuração. O primeiro template tem de conter a EKU Certificate Request Agent (OID 1.3.6.1.4.1.311.20.2.1) — a mesma OID que a Microsoft documenta como a extensão de application policy de enrollment agent usada na emissão de smart cards. Segundo a documentação da SpecterOps, o template da primeira fase necessita dos mesmos pré-requisitos de enrollment que o ESC2 (direitos de enrollment ao nível da CA e do template, sem aprovação de manager, sem assinaturas autorizadas), mais essa EKU específica.

Assim que o atacante possui esse certificado de enrollment agent, precisa de um segundo template: um que não restrinja quem pode atuar como enrollment agent, no qual o atacante se possa registar, que não exija aprovação de manager, e cuja EKU seja compatível com o papel de agent — autenticação de cliente, PKINIT, logon por smart card, Any Purpose, ou nenhuma EKU. Com ambas as peças reunidas, o atacante solicita um certificado a partir do segundo template em nome de uma identidade-alvo, como um Domain Admin, usando o certificado de enrollment agent para assinar o pedido. O certificado resultante autentica-se como o alvo, não como o atacante.

A própria documentação da Microsoft sobre a funcionalidade Restricted Enrollment Agent, introduzida no Windows Server 2008 Enterprise, descreve exatamente por que razão isto é perigoso por defeito: antes dessa funcionalidade, "não é possível permitir que um enrollment agent registe apenas um determinado grupo de utilizadores", pelo que qualquer certificado de enrollment agent válido podia ser usado para solicitar um certificado em nome de qualquer utilizador da organização, incluindo Domain Admins. O Restricted Enrollment Agent permite a um administrador da CA definir para quais templates e para quais grupos de segurança-alvo cada certificado de enrollment agent pode ser usado — mas apenas numa CA Enterprise Edition, e apenas se isso tiver sido efetivamente configurado.

ESC5 — Controlo de Acesso Vulnerável em Objetos de PKI

ESC5 não é, de todo, um problema de template. É um problema de ACL do Active Directory nos objetos que tornam toda a PKI fiável. Segundo a documentação da SpecterOps, os objetos em causa são:

• o próprio objeto de computador AD do servidor da CA
• o servidor RPC/DCOM do servidor da CA
• a árvore de contentores Public Key Services no contexto de nomeação Configuration (CN=Public Key Services,CN=Services,CN=Configuration,DC=...), incluindo os seus subcontentores Certificate Templates, Certification Authorities e Enrollment Services
• o objeto NTAuthCertificates dentro desse contentor

Segundo a própria documentação do protocolo [MS-WCCE] da Microsoft, o objeto NTAuthCertificates contém um atributo multivalor de certificados de assinatura de CA codificados em DER — na prática, a lista de CAs em que os controladores de domínio confiam para autenticação baseada em certificados (incluindo logon por smart card). Se um atacante conseguir escrever nesse objeto, pode adicionar uma CA fraudulenta à lista de confiança; todos os certificados que essa CA fraudulenta assinar a partir daí passam a ser considerados fiáveis para autenticação no domínio. A documentação da SpecterOps dá um exemplo concreto do risco geral: Domain Users com GenericAll no contentor Certificate Templates e nos seus descendentes — controlo total sobre a definição de todos os templates de certificado na floresta, a partir de um grupo com âmbito por defeito.

A gravidade de um achado ESC5 depende inteiramente de qual objeto está exposto e a quem. O acesso de escrita ao contentor Certificate Templates permite a um atacante criar ou modificar templates do zero para uma forma vulnerável a ESC1/ESC2/ESC3, contornando qualquer hardening já aplicado aos templates existentes. O acesso de escrita ao objeto de computador da CA ou ao seu servidor RPC/DCOM pode levar ao comprometimento do próprio host da CA e, com ele, da chave privada da CA — a mesma classe de impacto documentada em Certighost CVE-2026-54121, onde uma falha diferente do AD CS permitiu que um utilizador com poucos privilégios se fizesse passar por um controlador de domínio.

ESC7 — Controlo de Acesso Vulnerável da Entidade Certificadora

ESC7 reside no próprio security descriptor do objeto da CA, e não em objetos do AD — e, ao contrário do ESC6, não é uma flag de registry. As CAs Windows suportam separação de funções através de dois direitos de acesso configuráveis no separador Security da consola Certification Authority: ManageCA (o papel de Administrador da CA) e ManageCertificates (o papel de Gestor/Responsável de Certificados).

Segundo a documentação da SpecterOps, possuir ManageCA permite a um principal alterar a configuração de toda a CA — incluindo ativar/desativar a flag EDITF_ATTRIBUTESUBJECTALTNAME2 de que o ESC6 depende, reativar templates vulneráveis previamente desativados, e criar as condições de que ESC11 e ESC16 dependem. Isto significa que um atacante que possua apenas ManageCA — sem qualquer má configuração de template à vista — pode fabricar condições de ESC6 ou ESC11 sob demanda. A documentação da SpecterOps também descreve um abuso mais direto do ManageCA: solicitar um certificado a partir de um template que exige aprovação de manager, deixar o pedido falhar e ficar pendente, e depois usar o ManageCA em conjunto com o ManageCertificates para forçar a emissão desse pedido pendente, independentemente do requisito de aprovação que devia bloqueá-lo.

Só por si, o ManageCertificates permite a um principal gerir e emitir certificados que estão pendentes de aprovação. Segundo a documentação da SpecterOps, isto possibilita um bypass ao estilo ESC1 através de issuance policies ligadas a grupos: solicitar um certificado a partir de um template com aprovação obrigatória, usar o ManageCertificates para injetar uma OID de issuance policy ligada a um grupo no pedido pendente, e depois emiti-lo — obtendo um certificado cuja issuance policy mapeia para um grupo privilegiado, sem nunca satisfazer o controlo de aprovação de manager que o template foi configurado para impor.

A Cadeia de Ataque

O padrão repete-se nas quatro técnicas: ESC2 e ESC3 abusam daquilo que um template tem permissão para fazer depois de um certificado sair dele; ESC5 e ESC7 abusam de quem tem permissão para controlar os templates e a CA, antes de mais nada. Essa segunda categoria é a razão pela qual corrigir cada template individual sinalizado por ESC1, ESC2, ESC3, ESC4 ou ESC6 não fecha a porta — um atacante com acesso ESC5 ou ESC7 pode simplesmente recriar a condição vulnerável depois de a revisão estar concluída.

🚨 Perigo: o ESC3 e as variantes de acesso de escrita do ESC5 terminam ambos no mesmo resultado que o ESC1 — um certificado que se autentica como uma identidade-alvo, que pode ser convertido num TGT Kerberos e usado para se fazer passar por essa identidade, incluindo um Domain Admin. A escalada para a ACL de um objeto de PKI começa frequentemente como reconhecimento comum de abuso de ACL e DCSync, e não como uma técnica específica de AD CS.

Deteção

Correção

1. Remova templates de autenticação Any Purpose e sem EKU (ESC2). Restrinja a lista de EKUs de cada template publicado apenas ao que realmente é necessário. Se um template genuinamente precisar de ser reutilizável para múltiplas finalidades, mantenha os requisitos de aprovação de manager e de assinatura autorizada em vez de depender apenas de uma EKU restrita.
2. Restrinja os templates de enrollment agent (ESC3). Configure o Restricted Enrollment Agent em cada CA Enterprise Edition que emita certificados Certificate Request Agent, delimitando cada enrollment agent a templates específicos e a grupos de segurança-alvo específicos, em vez de o deixar sem restrições. Onde o restricted enrollment agent não estiver disponível, limite quem se pode registar no template de enrollment agent ao menor grupo possível e sob gestão próxima.
3. Reforce as ACLs dos objetos de PKI (ESC5). Reveja as ACLs dos contentores Certificate Templates, Certification Authorities e Enrollment Services, do objeto NTAuthCertificates, e do objeto de computador AD de cada servidor de CA. Remova GenericAll, WriteDacl, WriteOwner, e direitos equivalentes de qualquer principal fora do grupo de administração de PKI Tier 0 pretendido.
4. Reforce a separação de funções da CA (ESC7). Reveja o separador Security de cada CA e confirme que Manage CA e Issue and Manage Certificates são detidos apenas pelas contas que deles necessitam. Trate ambos como privilégios equivalentes a Tier 0, e não como predefinições genéricas de administração de TI — veja Endurecimento do Active Directory para perceber como estes se enquadram numa revisão mais ampla de privilégios Tier 0.
5. Reveja o tratamento de pedidos pendentes. Confirme que forçar a emissão de um pedido de certificado negado ou pendente não está rotineiramente disponível para os mesmos principals que também podem solicitar certificados — é exatamente essa combinação que torna possível o bypass de aprovação do ESC7.
6. Volte a testar após cada alteração. As restrições de enrollment agent e as alterações às ACLs de PKI podem quebrar a emissão legítima de smart cards e os fluxos de administração delegada. Valide com um grupo piloto representativo antes de impor as alterações a toda a CA, e mantenha a revisão do registo de auditoria da CA descrita na secção de deteção durante todo o rollout.

Onde Isto Se Enquadra: ANSSI R36, R37, e o Resto do Corpus ADCS

O guia da ANSSI sobre a administração segura do Active Directory (ANSSI-PA-099) trata o risco de PKI para o Tier 0 como uma recomendação numerada própria, independente da higiene geral de certificados. A R36 afirma que, sempre que uma PKI pode gerar certificados utilizáveis para autenticação no Tier 0, essa PKI "não deve oferecer caminhos de ataque para o Tier 0 a partir de níveis de confiança inferiores, seja através da administração dos sistemas que a alojam, através da delegação de direitos sobre as capacidades de geração de certificados, ou através de templates de certificado publicados" — uma descrição quase exata daquilo que ESC5 e ESC7 abusam (controlo delegado sobre a capacidade de geração de certificados, ou seja, a CA e os seus objetos de PKI) e daquilo que ESC2 abusa (templates publicados que concedem mais capacidade do que a pretendida). O mesmo guia refere separadamente a R37, que trata da robustez criptográfica dos certificados (proibindo assinaturas DSA, exigindo hashes SHA-2/SHA-3, e definindo tamanhos mínimos de chave RSA) — uma preocupação real, mas distinta das más configurações de EKU e de ACL aqui abordadas, que vale a pena auditar a par destas quatro técnicas, e não em substituição delas.

Este artigo não repete deliberadamente ESC1, ESC4, ESC6 ou ESC8 — veja Caminhos de Ataque ADCS Explicados para essas — nem ESC9, ESC10, ESC11, que residem na camada de mapeamento de certificados e de encriptação RPC abordada em ADCS ESC9, ESC10, ESC11 e no seu artigo complementar sobre mapeamento fraco de certificados. Uma revisão completa de AD CS precisa dos três artigos, mais a checklist Tier 0 mais ampla em Auditar a Segurança do Active Directory, porque nenhuma das onze técnicas substitui outra.

Como a EtcSec Deteta Isto

As verificações de auditoria de AD da EtcSec mapeiam diretamente cada técnica aqui abordada: ESC2_ANY_PURPOSE sinaliza templates capazes de autenticação com EKU Any Purpose ou vazia e sem barreira de aprovação, ESC3_ENROLLMENT_AGENT sinaliza templates Certificate Request Agent e os seus alvos a jusante sem restrição, ESC5_PKI_OBJECT_ACL revê as ACLs da árvore de contentores Public Key Services, do NTAuthCertificates, e dos objetos de computador da CA, e ESC7_CA_VULNERABLE_ACL revê a separação de funções ao nível da CA em busca de concessões demasiado amplas de ManageCA e ManageCertificates. Os achados das quatro técnicas convergem em PATH_CERTIFICATE_ESC quando formam um caminho ativo para Domain Admin, pelo que uma sinalização de template ou uma entrada de ACL é priorizada consoante seja ou não realmente alcançável — e não sinalizada isoladamente.

Referências Principais

• SpecterOps / Certify — Escalation Techniques Overview
• SpecterOps / Certify — ESC2: Misconfigured Any Purpose
• SpecterOps / Certify — ESC3: Misconfigured Certificate Request Agent
• SpecterOps / Certify — ESC5: Vulnerable PKI Object Access Control
• SpecterOps / Certify — ESC7: Vulnerable Certificate Authority Access Control
• Certified Pre-Owned: Abusing Active Directory Certificate Services
• Microsoft: AD CS Restricted Enrollment Agent
• Microsoft: [MS-WCCE] NTAuthCertificates Object
• ANSSI-PA-099: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory