Kerberos Double Hop Problem
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
The Kerberos "Double Hop" problem appears when an attacker attempts to use Kerberos authentication across two hops, for example using PowerShell/WinRM.
When an authentication occurs through Kerberos, credentials aren't cached in memory. Therefore, if you run mimikatz you won't find credentials of the user in the machine even if he is running processes.
This is because when connecting with Kerberos these are the steps:
User1 provides credentials and domain controller returns a Kerberos TGT to the User1.
User1 uses TGT to request a service ticket to connect to Server1.
User1 connects to Server1 and provides service ticket.
Server1 doesn't have credentials of User1 cached or the TGT of User1. Therefore, when User1 from Server1 tries to login to a second server, he is not able to authenticate.
If unconstrained delegation is enabled in the PC, this won't happen as the Server will get a TGT of each user accessing it. Moreover, if unconstrained delegation is used you probably can compromise the Domain Controller from it. More info in the unconstrained delegation page.
Another way to avoid this problem which is notably insecure is Credential Security Support Provider. From Microsoft:
CredSSP authentication delegates the user credentials from the local computer to a remote computer. This practice increases the security risk of the remote operation. If the remote computer is compromised, when credentials are passed to it, the credentials can be used to control the network session.
It is highly recommended that CredSSP be disabled on production systems, sensitive networks, and similar environments due to security concerns. To determine whether CredSSP is enabled, the Get-WSManCredSSP command can be run. This command allows for the checking of CredSSP status and can even be executed remotely, provided WinRM is enabled.
To address the double hop issue, a method involving a nested Invoke-Command is presented. This does not solve the problem directly but offers a workaround without needing special configurations. The approach allows executing a command (hostname) on a secondary server through a PowerShell command executed from an initial attacking machine or through a previously established PS-Session with the first server. Here's how it's done:
Alternatively, establishing a PS-Session with the first server and running the Invoke-Command using $cred is suggested for centralizing tasks.
A solution to bypass the double hop problem involves using Register-PSSessionConfiguration with Enter-PSSession. This method requires a different approach than evil-winrm and allows for a session that does not suffer from the double hop limitation.
For local administrators on an intermediary target, port forwarding allows requests to be sent to a final server. Using netsh, a rule can be added for port forwarding, alongside a Windows firewall rule to allow the forwarded port.
winrs.exe can be used for forwarding WinRM requests, potentially as a less detectable option if PowerShell monitoring is a concern. The command below demonstrates its use:
Installing OpenSSH on the first server enables a workaround for the double-hop issue, particularly useful for jump box scenarios. This method requires CLI installation and setup of OpenSSH for Windows. When configured for Password Authentication, this allows the intermediary server to obtain a TGT on behalf of the user.
Download and move the latest OpenSSH release zip to the target server.
Unzip and run the Install-sshd.ps1 script.
Add a firewall rule to open port 22 and verify SSH services are running.
To resolve Connection reset errors, permissions might need to be updated to allow everyone read and execute access on the OpenSSH directory.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
