mirror of https://github.com/carlospolop/hacktricks synced 2024-12-20 18:14:15 +00:00

Carlos Polop 31d14b2558 Recreating repository history for branch pt

2024-12-12 13:56:11 +01:00

9.1 KiB

Raw Blame History

Problema do Duplo Salto do Kerberos

{% hint style="success" %} Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Confira os planos de assinatura!
Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

{% endhint %}

{% embed url="https://websec.nl/" %}

Introdução

O problema do "Duplo Salto" do Kerberos aparece quando um atacante tenta usar autenticação Kerberos através de dois saltos, por exemplo usando PowerShell/WinRM.

Quando uma autenticação ocorre através do Kerberos, as credenciais não são armazenadas em memória. Portanto, se você executar o mimikatz, você não encontrará credenciais do usuário na máquina, mesmo que ele esteja executando processos.

Isso acontece porque, ao conectar-se com o Kerberos, estes são os passos:

User1 fornece credenciais e o controlador de domínio retorna um TGT Kerberos para o User1.
User1 usa o TGT para solicitar um ticket de serviço para conectar-se ao Server1.
User1 conecta-se ao Server1 e fornece o ticket de serviço.
O Server1 não tem as credenciais do User1 armazenadas ou o TGT do User1. Portanto, quando o User1 do Server1 tenta fazer login em um segundo servidor, ele não consegue se autenticar.

Delegação Não Restrita

Se a delegação não restrita estiver habilitada no PC, isso não acontecerá, pois o Servidor irá obter um TGT de cada usuário que o acessar. Além disso, se a delegação não restrita for usada, você provavelmente pode comprometer o Controlador de Domínio a partir dele.
Mais informações na página de delegação não restrita.

CredSSP

Outra maneira de evitar esse problema, que é notavelmente insegura, é o Provedor de Suporte de Segurança de Credenciais. Da Microsoft:

A autenticação CredSSP delega as credenciais do usuário do computador local para um computador remoto. Essa prática aumenta o risco de segurança da operação remota. Se o computador remoto for comprometido, quando as credenciais forem passadas para ele, as credenciais podem ser usadas para controlar a sessão de rede.

É altamente recomendável que o CredSSP seja desativado em sistemas de produção, redes sensíveis e ambientes semelhantes devido a preocupações de segurança. Para determinar se o CredSSP está habilitado, o comando Get-WSManCredSSP pode ser executado. Este comando permite a verificação do status do CredSSP e pode até ser executado remotamente, desde que o WinRM esteja habilitado.

Invoke-Command -ComputerName bizintel -Credential ta\redsuit -ScriptBlock {
Get-WSManCredSSP
}

Soluções Alternativas

Invoke Command

Para resolver o problema do double hop, é apresentado um método que envolve um Invoke-Command aninhado. Isso não resolve o problema diretamente, mas oferece uma solução alternativa sem a necessidade de configurações especiais. A abordagem permite executar um comando (hostname) em um servidor secundário através de um comando PowerShell executado de uma máquina de ataque inicial ou através de uma PS-Session previamente estabelecida com o primeiro servidor. Veja como é feito:

$cred = Get-Credential ta\redsuit
Invoke-Command -ComputerName bizintel -Credential $cred -ScriptBlock {
Invoke-Command -ComputerName secdev -Credential $cred -ScriptBlock {hostname}
}

Alternativamente, estabelecer uma PS-Session com o primeiro servidor e executar o Invoke-Command usando $cred é sugerido para centralizar tarefas.

Registrar Configuração de PSSession

Uma solução para contornar o problema do double hop envolve o uso de Register-PSSessionConfiguration com Enter-PSSession. Este método requer uma abordagem diferente do evil-winrm e permite uma sessão que não sofre da limitação do double hop.

Register-PSSessionConfiguration -Name doublehopsess -RunAsCredential domain_name\username
Restart-Service WinRM
Enter-PSSession -ConfigurationName doublehopsess -ComputerName <pc_name> -Credential domain_name\username
klist

PortForwarding

Para administradores locais em um alvo intermediário, o redirecionamento de porta permite que solicitações sejam enviadas para um servidor final. Usando netsh, uma regra pode ser adicionada para o redirecionamento de porta, juntamente com uma regra de firewall do Windows para permitir a porta redirecionada.

netsh interface portproxy add v4tov4 listenport=5446 listenaddress=10.35.8.17 connectport=5985 connectaddress=10.35.8.23
netsh advfirewall firewall add rule name=fwd dir=in action=allow protocol=TCP localport=5446

winrs.exe

winrs.exe pode ser usado para encaminhar solicitações WinRM, potencialmente como uma opção menos detectável se o monitoramento do PowerShell for uma preocupação. O comando abaixo demonstra seu uso:

winrs -r:http://bizintel:5446 -u:ta\redsuit -p:2600leet hostname

OpenSSH

Instalar o OpenSSH no primeiro servidor permite uma solução para o problema do double-hop, particularmente útil para cenários de jump box. Este método requer a instalação e configuração do OpenSSH para Windows via CLI. Quando configurado para Autenticação por Senha, isso permite que o servidor intermediário obtenha um TGT em nome do usuário.

Passos para Instalação do OpenSSH

Baixe e mova o arquivo zip da versão mais recente do OpenSSH para o servidor de destino.
Descompacte e execute o script Install-sshd.ps1.
Adicione uma regra de firewall para abrir a porta 22 e verifique se os serviços SSH estão em execução.

Para resolver erros de Connection reset, as permissões podem precisar ser atualizadas para permitir que todos tenham acesso de leitura e execução no diretório do OpenSSH.

icacls.exe "C:\Users\redsuit\Documents\ssh\OpenSSH-Win64" /grant Everyone:RX /T

Referências