Caminhos de ataque ADCS explicados

Caminhos de ataque ADCS: o que conta como um caminho real

Se você procura uma explicação prática de caminhos de ataque ADCS, precisa começar pela cadeia, e não pelo rótulo. Um caminho de ataque em AD CS não é só um template fraco. É a combinação de regras de emissão, direitos de enrollment, controle sobre a configuração do template ou da CA, endpoints de enrollment acessíveis e comportamento de autenticação baseada em certificado que permite que uma identidade pouco privilegiada se torne mais privilegiada ou reabra esse caminho mais tarde.

Por isso, uma revisão de AD CS não pode parar em um único screenshot do Certificate Templates. É preciso responder cinco perguntas em conjunto:

Quais Enterprise CAs existem na floresta?
Quais templates estão publicadas e podem ser usadas para autenticação?
Quem pode fazer enroll, auto-enroll ou modificar esses templates?
Quais configurações globais da CA ampliam o abuso de subject ou SAN?
Quais endpoints de enrollment e quais caminhos de autenticação tornam esses certificados realmente utilizáveis em produção?

Na pesquisa Certified Pre-Owned da SpecterOps, os rótulos ESC nomeiam padrões recorrentes de abuso. Numa revisão real, eles são caminhos de ataque porque conectam configuração de PKI a escalada de identidade.

Por que os caminhos de ataque ADCS ainda importam no Active Directory

A Microsoft documenta AD CS como a role do Windows Server que emite e gerencia certificados PKI para autenticação, criptografia, smart card sign-in, TLS, VPN e outros fluxos de segurança. Essa mesma role se torna uma superfície de identidade de alto impacto quando as regras de emissão de certificados e de autenticação por certificado se afastam do princípio de menor privilégio.

Os caminhos em AD CS importam porque nem todos se parecem com um abuso clássico de admin. Alguns permitem que um atacante solicite um certificado que autentica como outra identidade. Outros permitem mudar primeiro o plano de controle e, só depois, criar as condições perigosas no template. Outros dependem de relay de autenticação para endpoints de enrollment em vez de modificação direta da configuração do template. E alguns ainda fazem parte de cadeias de escalada maiores com caminhos de ataque no AD ou abuso de ACL e DCSync, em vez de atuarem sozinhos.

Uma segunda razão são os pontos cegos operacionais. Equipes de segurança costumam monitorar melhor resets de senha, os erros críticos de senhas no AD ou a delegação Kerberos do que emissão de certificados. Se o auditing da CA, a visibilidade de mudanças em templates ou as baselines de autenticação por certificado forem fracos, um caminho PKI vulnerável pode permanecer ativo muito depois de outros caminhos de escalada terem sido revisados.

Pacote mínimo de evidências

Evidência	Por que importa
Inventário de Enterprise CAs	Confirma quais CAs e quais role services realmente existem na floresta
Templates publicadas	Um template não publicado não pode ser solicitado nessa CA
Direitos de enrollment e auto-enrollment	Mostra se identidades de baixo privilégio conseguem obter certificados
ACLs dos templates	Determina quem pode adulterar o template
Controles de subject e SAN	Identifica se o solicitante pode fornecer valores de identidade perigosos
Edit flags da CA	Revela configurações globais como `EDITF_ATTRIBUTESUBJECTALTNAME2`
Estado de web enrollment, HTTPS e EPA	Determina se endpoints relayáveis continuam expostos
Telemetria de emissão e autenticação por certificado	Prova se o monitoramento realmente enxerga solicitações, emissão e autenticação por certificado

Caminhos de abuso de template: ESC1 e templates de autenticação publicadas

ESC1 é o exemplo mais claro de um caminho de abuso de template. O Microsoft Defender for Identity descreve a condição perigosa desta forma: se um certificate template tem Supply in the request ativado e o certificado também é válido para autenticação, atacantes podem conseguir fazer enroll de um certificado válido para usuários arbitrários.

Na prática, um caminho ESC1 normalmente combina estas condições:

o template está publicado em uma CA
identidades de baixo privilégio podem fazer enroll nele
o template permite valores de subject ou SAN fornecidos pelo solicitante
o certificado pode ser usado para autenticação, por exemplo com EKU compatível com client authentication
nenhum controle mais forte, como manager approval ou required authorized signatures, bloqueia a emissão

O ponto importante é que o flag sozinho não basta. Um template pode ter comportamento de naming arriscado e ainda assim não ser um caminho ativo se não estiver publicado ou se estiver restrito a uma população de enrollment fortemente governada. Em contrapartida, um template de autenticação publicado, com scope fraco e controles de emissão fracos, já é um caminho de identidade, não apenas um problema de higiene de templates.

É por isso que a revisão precisa falar de templates de autenticação publicadas, e não apenas de “templates vulneráveis” em abstrato. A publicação determina a explorabilidade.

Caminhos de plano de controle: ESC4 e ESC6

ESC4 e ESC6 são caminhos de plano de controle. Eles são perigosos porque permitem que um atacante crie ou amplie um comportamento de emissão explorável, mesmo que o template não tenha começado em um estado obviamente inseguro.

Com ESC4, o problema está na ACL do objeto template. Certificate templates são objetos do Active Directory, e suas ACLs controlam não apenas o enrollment, mas também quem pode editar o objeto. O Microsoft Defender for Identity destaca explicitamente o risco quando grupos não privilegiados recebem permissões que permitem alterar configurações do template, como Full Control ou WriteDACL. Em outras palavras, o atacante não precisa que o template já comece como ESC1: ele pode manipulá-lo até chegar lá.

Com ESC6, o problema sai do template e vai para a CA. Se a CA tem o flag EDITF_ATTRIBUTESUBJECTALTNAME2 ativado, o Microsoft Defender for Identity observa que usuários podem especificar configurações SAN em solicitações de certificado e que isso afeta templates independentemente de elas ativarem ou não individualmente Supply in the request. Isso não significa que todo template vire automaticamente um botão direto de Domain Admin. Significa que a CA ampliou a superfície de controle do subject, e qualquer template de autenticação publicado no scope errado fica muito mais perigoso.

Esses dois caminhos pertencem à mesma revisão que abuso de permissões e direitos de replicação, porque no fundo são problemas de governança no plano de controle da PKI.

Caminhos de relay: ESC8 e endpoints de enrollment

ESC8 é diferente de abuso de template. O caminho depende de endpoints de enrollment relayáveis, e não apenas de flags do template.

A Microsoft documenta AD CS web enrollment e certificate enrollment web services como superfícies de enrollment baseadas em HTTP. O suporte Microsoft KB5005413 explica por que isso importa: se atacantes puderem fazer relay de autenticação NTLM para endpoints AD CS vulneráveis, podem obter certificados que depois serão usados para avançar a intrusão. A avaliação ESC8 do Microsoft Defender for Identity restringe ainda mais a condição ao apontar endpoints IIS que aceitam autenticação NTLM sem HTTPS forçado ou sem Extended Protection for Authentication (EPA).

Isso faz de ESC8 um problema de endpoint e de protocolo tanto quanto um problema de PKI. A revisão deve incluir:

se CA Web Enrollment ou enrollment web services relacionados estão instalados
se continuam acessíveis por HTTP
se EPA está realmente imposto
se NTLM ainda é aceito onde a Microsoft recomenda desativá-lo ou restringi-lo

Esse caminho também deve ser lido junto com o endurecimento mais amplo contra relay, como ataques NTLM relay e SMB signing desativado, porque o endpoint de certificados costuma ser apenas um passo da cadeia.

Onde weak certificate mapping se encaixa

Weak certificate mapping importa, mas não é o mesmo problema que ESC1, ESC4, ESC6 ou ESC8.

O núcleo dos caminhos AD CS acima trata de como um certificado é emitido ou como o caminho de emissão pode ser reaberto. KB5014754 trata de outra camada: como os domain controllers avaliam o mapeamento de autenticação por certificado e avançam para um binding mais forte. Por isso, weak mapping deve ser tratado como um controle adjacente e apontar para o post dedicado Weak Certificate Mapping in AD CS: Why Strong Binding Matters, e não ser fundido neste artigo como se já estivesse coberto pelos quatro vuln tags ADCS do grupo.

Na prática, uma revisão forte de AD CS precisa separar duas perguntas:

um atacante consegue obter um certificado perigoso?
se um certificado perigoso existir, como os domain controllers vão vinculá-lo a uma conta?

Os dois temas se relacionam, mas não são o mesmo caminho de ataque.

Detecção

A detecção precisa correlacionar emissão, mudanças de plano de controle e telemetria de autenticação. Nenhum evento isolado prova abuso de AD CS.

Telemetria de emissão e configuração da CA

A orientação da Microsoft sobre advanced audit policy e monitoramento de PKI coloca o auditing da CA no centro. No mínimo, a equipe de segurança precisa saber se a CA produz telemetria de solicitação e emissão como:

4886 para solicitações de certificado
4887 para emissão de certificado
4882 para mudanças de permissões de segurança do Certificate Services
4890, 4891 ou 4892 para mudanças de gerenciamento e configuração no Certificate Services

Esses eventos são úteis porque mostram que uma solicitação, uma emissão ou uma mudança de configuração ocorreu. Eles não provam sozinhos que a solicitação foi maliciosa. Ainda é necessário correlacionar solicitante, template, subject pretendido e fluxo de negócio esperado.

Telemetria de mudanças em objetos do Active Directory

Templates são objetos do AD, então 5136 importa quando o auditing está configurado e as SACLs relevantes existem. A Microsoft documenta 5136 como o evento gerado quando um objeto do Active Directory é modificado. Em uma revisão de AD CS, isso importa para mudanças de ACL de template, mudanças de publicação e outras modificações de objeto que transformam um template normal em um caminho de ataque.

Telemetria de autenticação

No domain controller, 4768 registra solicitações de TGT. Isso o torna útil para correlacionar emissão de certificados com padrões posteriores de autenticação, especialmente para contas ou máquinas que normalmente não usam autenticação baseada em certificado. Mas 4768 não é um detector AD CS. É uma fonte de correlação entre várias, e fica muito mais útil quando é combinada com eventos de emissão da CA e com uma baseline do comportamento esperado de autenticação por certificado.

Evidência de configuração e exposição

Nem toda detecção útil é dirigida por evento. Alguns dos achados mais importantes em AD CS são achados de estado:

um template de autenticação publicado continua enrollável por usuários de baixo privilégio
uma ACL de template continua concedendo direitos perigosos de escrita
EDITF_ATTRIBUTESUBJECTALTNAME2 continua ativado
um endpoint de enrollment continua aceitando condições relayáveis de NTLM em HTTP ou sem EPA

Essa é uma das razões pelas quais o monitoramento de segurança AD e os eventos que importam deve ser combinado com uma revisão repetível de configuração, e não tratado como resposta completa.

Remediation: prioridades de correção

A ordem correta é quebrar primeiro os caminhos ativos de emissão, depois endurecer o plano de controle, fechar as lacunas de endpoint e, por fim, validar separadamente a postura de mapping.

1. Quebrar os caminhos ativos de emissão

Comece despublicando ou restringindo os templates que hoje criam o caminho. O Microsoft Defender for Identity recomenda explicitamente remover da publicação um template perigoso quando ele não deveria ser solicitável. Se um template precisar continuar disponível, reduza primeiro o scope de enrollment antes de fazer limpeza cosmética.

Depois, remova ou limite comportamentos de subject e SAN fornecidos pelo solicitante quando eles não forem estritamente necessários. Para templates que ainda precisem suportar fluxos específicos, aplique controles de emissão mais fortes, como approval ou authorized signatures, em vez de manter enrollment amplo para identidades de baixo privilégio.

2. Remover as condições de abuso do plano de controle

Para ESC4, endureça as ACLs dos templates para que grupos não privilegiados não possam alterar permissões nem configurações. Para ESC6, remova EDITF_ATTRIBUTESUBJECTALTNAME2 salvo se existir uma dependência operacional justificada e revisada.

Revise também quem pode gerenciar configurações da CA, publicar templates ou delegar administração de PKI. Uma correção no template não é durável se outro operador ou grupo delegado puder restaurar silenciosamente o estado perigoso depois.

3. Fechar superfícies de enrollment relayáveis

Para ESC8, aplique as mitigações da Microsoft em KB5005413:

desativar roles web de enrollment não utilizadas quando possível
exigir HTTPS
habilitar EPA
reduzir ou desativar a exposição a NTLM nos endpoints IIS de enrollment onde a Microsoft recomenda isso

Se web enrollment não for necessário em produção, removê-lo costuma ser uma redução de risco melhor do que tentar preservá-lo com controles parciais.

4. Tratar weak certificate mapping como endurecimento adjacente

Não confunda endurecimento de template com endurecimento de mapping. Se o ambiente ainda depende de mappings fracos, trate KB5014754 como uma trilha separada de remediação e valide explicitamente essas mudanças do lado dos domain controllers.

Validação após a remediação

Não dê a remediação de AD CS como concluída até conseguir provar que o caminho de ataque foi realmente quebrado a partir da mesma perspectiva usada na revisão de segurança.

A validação deve incluir:

prova de que os templates vulneráveis não estão mais publicados ou não permanecem enrolláveis por identidades de baixo privilégio
prova de que entradas perigosas de ACL desapareceram
prova de que a CA não expõe mais EDITF_ATTRIBUTESUBJECTALTNAME2
prova de que endpoints de enrollment não permanecem expostos em HTTP ou sem EPA quando o caminho dependia dessas condições
prova de que o auditing da CA agora captura solicitações e emissões de certificados
prova de que o monitoramento do AD enxerga mudanças de objetos template onde isso importa
prova de que certificados de risco já emitidos foram revisados e revogados quando necessário

É aqui que um fluxo mais amplo como auditar a segurança do Active Directory se torna útil. A validação de AD CS não é sobre um único flag: ela precisa provar que o caminho de emissão, o plano de controle e o caminho de monitoramento mudaram de fato em produção.

Como EtcSec mapeia os caminhos de ataque ADCS

O EtcSec precisa permanecer estreito aqui: ele mede as condições que criam o caminho.

Para os caminhos centrais, isso significa mapear findings como:

ESC1_VULNERABLE_TEMPLATE
ESC4_VULNERABLE_TEMPLATE_ACL
ESC6_EDITF_FLAG
ESC8_HTTP_ENROLLMENT

A mesma revisão também pode expor findings adjacentes que explicam por que o caminho existe ou como ele encadeia mais adiante:

ADCS_WEAK_PERMISSIONS
PATH_CERTIFICATE_ESC

O ponto importante não é prometer detecção mágica de ataque. O valor está em medir repetidamente o scope dos templates, as ACLs, os flags da CA e a exposição dos endpoints de enrollment para que a deriva de PKI fique visível antes de voltar a se transformar em uma cadeia de escalada.

Caminhos de ataque ADCS: como erros em certificados viram caminhos de escalada no Active Directory