Huy Kha | Arquiteto Sénior de Identidade e Segurança

O escalonamento de privilégios no Active Diretory (AD) permite que os atacantes cibernéticos aumentem o acesso dentro do ambiente e potencialmente comprometam redes inteiras - sem serem detectados. O Enterprise CA Security Configuration (ESC1) é um método de ataque que tem crescido em popularidade porque permite que os malfeitores obtenham acesso privilegiado através de uma ferramenta que, na verdade, foi concebida para facilitar a vida dos administradores: modelos de certificados.

O que é um ataque ESC1?

Os modelos de certificados ajudam a simplificar a administração das autoridades de certificação (CAs) dos Serviços de Certificados do Active Diretory (AD CS), fornecendo um conjunto pré-configurado de regras e definições que são aplicadas aos pedidos de certificados recebidos. Proporcionam uma forma de os administradores optimizarem a gestão de certificados e assegurarem a consistência na aplicação de políticas de certificados.

No entanto, os modelos de certificado podem ser vulneráveis a uma utilização incorrecta.

Num ataque ESC1, um atacante explora um modelo de certificado de AC Empresarial mal configurado no AD CS para solicitar um certificado para uma conta com privilégios elevados - por exemplo, Administrador do Domínio. Em seguida, utiliza esse certificado para agir como essa conta, obtendo controlo não autorizado.

Como é que um ataque ESC1 funciona?

Para efetuar um ataque ESC1, um ator malicioso necessita que o AD CS esteja em execução e tem de ter permissão para se inscrever num modelo de certificado mal configurado.

O atacante procura uma configuração de modelo de certificado vulnerável(Figura 1) com:

  • A definição Fornecer no pedido está selecionada, o que permite ao atacante pedir um certificado para qualquer conta
  • Utilização alargada da chave (EKU) extensões como Client Authentication, PKINIT Client Authentication, Smart Card Logon, Any Purpose-ou nenhuma EKU (como SubCA)
Figura 1. Modelo de certificado vulnerável, que permite a um atacante fazer-se passar por todos os utilizadores do domínio

Quando estas condições existem, o atacante pode pedir um certificado para qualquer conta no domínio(Figura 2) e depois utilizá-lo para se fazer passar por essa conta.

Figura 2. Pedido de um certificado em nome de qualquer conta especificada

Como se pode defender de um ataque ESC1?

Se a sua organização tiver modelos de certificado que permitam Nomes Alternativos de Assunto (SANs) e suporte Client Authentication EKUs, podem ser vulneráveis a um ataque ESC1.

Para se proteger contra isto, siga estes passos práticos:

  • Verificar os modelos de certificado: Reveja todos os seus modelos de certificado e identifique aqueles que permitem SANs e têm extensões EKU, tais como:
    • Client Authentication (1.3.6.1.5.5.7.3.2)
    • PKINIT Client Authentication (1.3.6.1.5.2.3.4)
    • Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2)
    • Any Purpose (OID 2.5.29.37.0)
    • Ou modelos sem EKU (como SubCA)
  • Limitar quem se pode registar: Certifique-se de que apenas os utilizadores ou grupos que realmente necessitam de acesso podem inscrever-se para obter certificados com estes modelos. O acesso mais restrito ajuda a minimizar quem pode explorar os modelos.
  • Exigir a aprovação do gestor da AC: Para quaisquer modelos de certificado que permitam SAN e suportem Client Authenticationactive a aprovação do gestor de certificados da AC. Isto significa que alguém tem de aprovar cada pedido antes de um certificado ser emitido.
  • Desativar modelos não utilizados: Se determinados modelos de certificado não estiverem a ser utilizados, desactive-os ou ajuste-os para remover configurações de risco. Por exemplo, desactive a definição Fornecer no pedido para que os utilizadores não possam pedir certificados para outras contas.

Os defensores podem utilizar o Purple Knight AD para identificar modelos de certificados inseguros e tomar medidas para os remediar(Figura 3).

Figura 3. Ferramenta Purple Knight mostrando modelos de certificados vulneráveis

Os defensores também podem utilizar Invoke-Locksmith1 (Figura 4) para identificar rapidamente modelos de certificados inseguros e tomar medidas para corrigi-los. O script do Locksmith PowerShell inclui uma opção para correção automática, mas é importante testar e revisar tudo minuciosamente antes de implementar qualquer etapa de correção.

Uma grande caraterística do Invoke-Locksmith é que também inclui Invoke-RevertLocksmithque permite a uma organização reverter facilmente quaisquer alterações se notar algum impacto negativo. Isto proporciona uma camada extra de segurança quando se ajustam modelos de certificados.

Figura 4. Correção de modelos de certificados vulneráveis com Invoke-Locksmith

Como detetar ataques ESC1

Num ambiente empresarial de grandes dimensões, a deteção de pedidos maliciosos a modelos de certificados vulneráveis pode ser um desafio. Embora os IDs de evento 4886 e 4887 possam mostrar qual usuário solicitou um certificado, eles não revelam o valor que um invasor especificou no campo subjectAltName para se fazer passar por uma conta específica.

De um ponto de vista forense, todos os pedidos de certificado são registados (Figura 5) e pode ser visualizado na IU da Autoridade de Certificação em Certificados Emitidos. Esta secção mostra quando um pedido de certificado inclui valores como os da tabela subjectAltNamejuntamente com outros detalhes importantes, como quem fez o pedido, que modelo de certificado foi utilizado, a EKU e os carimbos de data/hora relevantes. Estes registos são úteis para investigar e localizar quaisquer pedidos de certificado suspeitos.

Figura 5. Certificados que foram emitidos pelo servidor CA

Perfis de actores de ameaças

Os seguintes agentes de ameaças têm estado a executar ataques ESC1 em estado selvagem:

  • UNC53302
  • APT293

Ferramentas ESC1

As seguintes ferramentas públicas de abuso de certificados do Active Diretory podem ser utilizadas para efetuar um ataque ESC1:

  • Certificar
  • Certipy

Visão geral das ameaças

Tática ATT&CK: Aumento de privilégios

Em 4 de abril de 2024, o Google Cloud publicou um relatório descrevendo como o agente de ameaças UNC5330 explorou as vulnerabilidades CVE-2024-21893 e CVE-2024-21887 no Ivanti Connect Secure para se infiltrar na rede de uma vítima. Utilizaram uma conta LDAP bind para explorar um modelo de certificado Windows vulnerável, criando um objeto de computador e fazendo-se passar por um administrador de domínio.4

Em 28 de abril de 2022, a Mandiant informou que o APT29 explorou modelos de certificados mal configurados para se fazer passar por utilizadores administradores. Ao abusar destas configurações incorrectas no AD CS, o atacante conseguiu pedir certificados como utilizadores com pouco privilégio e especificar contas com muito privilégio no campo Subject Alternative Name (SAN). Isto permitiu-lhes autenticar como esses utilizadores com privilégios elevados.5

Instantâneo da Semperis

O AD CS deve ser tratado como um ativo de Nível 0 porque tem controlo direto sobre a segurança de todo o ambiente do Active Diretory. O comprometimento do AD CS pode permitir que os atacantes emitam certificados que lhes permitam fazer-se passar por contas com privilégios elevados, contornar controlos de segurança e obter acesso completo a sistemas sensíveis.

Saiba mais sobre o aumento de privilégios no AD

Notas finais

  1. https://github.com/jakehildreth/Locksmith/tree/main
  2. https://malpedia.caad.fkie.fraunhofer.de/actor/unc5330
  3. https://malpedia.caad.fkie.fraunhofer.de/actor/apt29
  4. https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement
  5. https://cloud.google.com/blog/topics/threat-intelligence/tracking-apt29-phishing-campaigns