Kerberos Double Hop Problem
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
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 ocorre 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.
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.
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.
Para resolver o problema do double hop, um método envolvendo um Invoke-Command aninhado é apresentado. 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 a partir de uma máquina de ataque inicial ou através de uma PS-Session previamente estabelecida com o primeiro servidor. Veja como é feito:
Alternativamente, estabelecer uma PS-Session com o primeiro servidor e executar o Invoke-Command usando $cred é sugerido para centralizar tarefas.
Uma solução para contornar o problema do double hop envolve usar 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.
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.
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:
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.
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.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
