Fechamos o Bloco XI com um vetor que ganhou enorme proeminência recente: os ataques ao ADCS (Active Directory Certificate Services), a infraestrutura de certificados de muitos ambientes Windows. Certificados, como você viu no Bloco IV, são uma forma de autenticação — e um ADCS mal configurado permite que um atacante obtenha certificados que o autenticam como qualquer usuário, inclusive administradores, oferecendo tanto comprometimento total quanto persistência de longo prazo. Estudá-lo fecha o quadro do AD ofensivo com uma das áreas mais ativas da pesquisa de segurança. Laboratório AD com ADCS, sempre.

O ADCS como a PKI do domínio

Primeiro, o contexto. O ADCS é a implementação da Microsoft de uma PKI (aula Criptografia assimétrica e PKI: dois cadeados e uma cadeia de confiança) dentro do Active Directory — ele emite certificados digitais para usuários, computadores e serviços do domínio, usados para autenticação, cifragem e assinatura. É uma funcionalidade útil e comum. O problema é que, como toda infraestrutura poderosa, ele pode ser mal configurado — e o ADCS tem um histórico de configurações padrão e comuns que são inseguras. Uma pesquisa influente (publicada sob o nome "Certified Pre-Owned") catalogou uma série de configurações vulneráveis, batizadas de ESC1 a ESC8 (Escalation), cada uma um caminho distinto de abuso. Você não precisa memorizar cada ESC agora, mas precisa entender o princípio que as une.

Um certificado autentica como um usuário

O princípio central é este: um certificado pode servir para autenticar como um usuário, e se um atacante consegue obter um certificado que o identifica como outra pessoa, ele pode se autenticar como essa pessoa. Os ataques ao ADCS exploram configurações de "modelos de certificado" (certificate templates) que permitem, de formas variadas, que um usuário comum solicite e receba um certificado que o identifica como um usuário diferente — inclusive um Domain Admin. Por exemplo, num dos cenários clássicos (ESC1), um modelo de certificado mal configurado permite que o solicitante especifique quem ele quer ser (o "subject") no certificado — de modo que um usuário comum pede um certificado dizendo "eu sou o administrador do domínio", e o ADCS, mal configurado, o emite. De posse desse certificado, o atacante se autentica como administrador. É um caminho direto do usuário comum ao comprometimento total, explorando uma configuração de template.

Acessível a baixo privilégio

O que torna os ataques ao ADCS especialmente perigosos é a combinação de dois fatores. Primeiro, eles frequentemente são acessíveis a usuários de baixo privilégio — muitos dos ESCs podem ser executados por qualquer usuário de domínio, transformando um acesso inicial modesto em comprometimento do domínio, exatamente o tipo de caminho que o BloodHound (que hoje mapeia relações de ADCS) revela. Segundo, e mais insidioso, certificados oferecem persistência de longo prazo. Um certificado tipicamente tem validade longa (meses ou anos), e — crucialmente — permanece válido mesmo que a senha do usuário seja alterada. Então um atacante que obtém um certificado de autenticação de um administrador tem uma credencial que sobrevive à troca de senha desse administrador — um caminho de volta persistente que os esforços de remediação convencionais (resetar senhas) não eliminam. É um problema análogo ao Golden Ticket em persistência: uma credencial durável que ignora as remediações usuais.

Cadeias com coerção e relay

Os ataques ao ADCS também se combinam com as técnicas já vistas, formando cadeias. A coerção e o NTLM relay (aula NTLM relay e ataques de coerção: abusando da autenticação em trânsito), por exemplo, podem ser direcionados a um endpoint de inscrição de certificados vulnerável (o cenário ESC8), permitindo que a autenticação coagida de uma máquina resulte na emissão de um certificado para o atacante — encadeando dois vetores num comprometimento. Ferramentas como o Certipy e o Certify automatizam a descoberta e a exploração dessas configurações. O ADCS ilustra perfeitamente como o AD é um ecossistema de componentes interconectados, onde uma fraqueza num serviço (certificados) se combina com fraquezas em outro (autenticação NTLM) para produzir comprometimento total.

Funcionalidade mal configurada, não bug

O ponto que fecha o bloco: o ADCS reforça o tema central do AD ofensivo — que os ataques mais devastadores exploram funcionalidades legítimas e poderosas mal configuradas, não bugs de software. Certificados são uma tecnologia de segurança sólida; o problema é a configuração dos modelos e das permissões de emissão. E, como todo o bloco demonstrou, o comprometimento do domínio raramente é um único golpe — é o encadeamento de enumeração, extração de credenciais, movimentação lateral, relay e abuso de infraestrutura, cada peça explorando uma configuração ou característica, convergindo para o controle total. O AD é, ao mesmo tempo, a espinha dorsal da empresa e sua maior concentração de risco.

Auditar os modelos de certificado

Do lado defensivo, as contramedidas contra ataques ao ADCS são específicas e cada vez mais conhecidas: auditar e corrigir os modelos de certificado vulneráveis (a raiz — revisar quais templates permitem que solicitantes especifiquem identidades ou tenham configurações abusáveis, e corrigi-los conforme as orientações dos ESCs); restringir quem pode solicitar certificados e para quais propósitos (menor privilégio aplicado à emissão); proteger os endpoints de inscrição contra relay (EPA, HTTPS — fechando o ESC8); monitorar emissão anômala de certificados (solicitações incomuns, certificados emitidos para contas privilegiadas); e — para remediação de comprometimento — revogar certificados potencialmente abusados (já que resetar senhas não basta). Ferramentas defensivas (o próprio Certipy tem modo de auditoria, e o PSPKIAudit) ajudam a encontrar as configurações vulneráveis antes do atacante. A lição, ecoando o bloco: a segurança do AD exige auditar continuamente não só usuários e permissões, mas toda a infraestrutura de suporte — certificados, replicação, autenticação —, porque o atacante procura a fraqueza em qualquer um desses componentes.

Fecha o Bloco XI por completo

Com esta aula, encerramos o Bloco XI — Active Directory ofensivo por completo. Você percorreu o arco integral do ataque ao domínio: fundamentos e enumeração com BloodHound (aula Active Directory ofensivo: fundamentos e enumeração com BloodHound), extração de credenciais via Kerberos (aula Kerberoasting e AS-REP Roasting: extraindo credenciais do Kerberos), reutilização de credenciais com Pass-the-Hash/Ticket (aula Pass-the-Hash, Pass-the-Ticket e a reutilização de credenciais), o comprometimento total com DCSync e Golden Ticket (aula DCSync e Golden Ticket: o comprometimento total do domínio), o abuso de autenticação em trânsito com NTLM relay e coerção (aula NTLM relay e ataques de coerção: abusando da autenticação em trânsito), e o abuso da infraestrutura de certificados com ADCS (aula Ataques ao ADCS: quando a infraestrutura de certificados vira porta dos fundos). Este é o conteúdo mais valorizado do pentest corporativo moderno, e você o domina com a defesa pareada em cada técnica. Daqui em diante o território muda por completo para o maior campo de vulnerabilidades do mundo: o Bloco XII — Web e Aplicações, começando pela arquitetura web e o HTTP.

Fontes e leituras recomendadas

  • "Certified Pre-Owned" (SpecterOps) — a pesquisa que catalogou os ESCs do ADCS
  • Certipy e Certify — ferramentas de exploração e auditoria de ADCS
  • HackTricks — seção de "AD CS" com os cenários ESC
  • PSPKIAudit e orientações da Microsoft sobre segurança de templates (defensivo)

Exercícios

  1. O que é o ADCS, e por que a capacidade de um certificado autenticar um usuário é a base dos ataques a ele?

    ✓ Resposta:

    O ADCS é a implementação da PKI da Microsoft dentro do Active Directory, que emite certificados digitais para usuários, computadores e serviços. Como certificados servem para autenticar, obter um certificado que identifica o atacante como outro usuário permite que ele se autentique como essa pessoa — a base dos ataques.

  2. Explique o princípio geral dos ataques ESC, usando o cenário em que um usuário comum obtém um certificado que o identifica como administrador.

    ✓ Resposta:

    O princípio é explorar modelos de certificado mal configurados que permitem a um usuário comum solicitar e receber um certificado que o identifica como um usuário diferente. No cenário clássico (ESC1), o template permite que o solicitante especifique quem quer ser; o usuário pede um certificado declarando ser o Domain Admin, o ADCS o emite, e o atacante se autentica como administrador.

  3. Por que os certificados oferecem uma persistência especialmente perigosa, comparável em espírito ao Golden Ticket?

    ✓ Resposta:

    Porque um certificado tem validade longa (meses/anos) e permanece válido mesmo após a troca de senha do usuário. Assim, um atacante com um certificado de autenticação de um administrador mantém uma credencial durável que sobrevive ao reset de senha — um caminho de volta persistente que as remediações convencionais não eliminam, análogo ao Golden Ticket.

  4. Como os ataques ao ADCS se combinam com a coerção e o NTLM relay?

    ✓ Resposta:

    A coerção força uma máquina a se autenticar contra o atacante, e o NTLM relay pode direcionar essa autenticação a um endpoint de inscrição de certificados vulnerável (ESC8), fazendo com que a autenticação coagida resulte na emissão de um certificado para o atacante — encadeando os dois vetores em comprometimento.

  5. Cite três contramedidas contra ataques ao ADCS e explique por que, na remediação, revogar certificados é necessário além de resetar senhas.

    ✓ Resposta:

    Contramedidas: auditar e corrigir modelos de certificado vulneráveis, restringir quem pode solicitar certificados, proteger endpoints de inscrição contra relay (EPA/HTTPS), monitorar emissão anômala. Na remediação, revogar certificados é necessário porque um certificado emitido para o atacante continua válido mesmo após reset de senha; sem revogá-lo, ele mantém acesso apesar da troca de credenciais.