Kerberos Double Hop Problem


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:
  1. 1.
    User1 provides credentials and domain controller returns a Kerberos TGT to the User1.
  2. 2.
    User1 uses TGT to request a service ticket to connect to Server1.
  3. 3.
    User1 connects to Server1 and provides service ticket.
  4. 4.
    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.

Unconstrained Delegation

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 suggested option to sysadmins to avoid this problem which is notably insecure **** is Credential Security Support Provider. Enabling CredSSP has been a solution mentioned on various forums throughout the years. 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.”
If you find CredSSP enabled on production systems, sensitive networks, etc it’s recommended they be disabled. A quick way to check CredSSP status is by running Get-WSManCredSSP. Which can be executed remotely if WinRM is enabled.
Invoke-Command -ComputerName bizintel -Credential ta\redsuit -ScriptBlock {


Invoke Command

This method is sort of “working with” the double hop issue, not necessarily solving it. It doesn’t rely on any configurations, and you can simply run it from your attacking box. It’s basically a nested Invoke-Command.
This’ll run hostname on the second server:
$cred = Get-Credential ta\redsuit
Invoke-Command -ComputerName bizintel -Credential $cred -ScriptBlock {
Invoke-Command -ComputerName secdev -Credential $cred -ScriptBlock {hostname}
You could also have a PS-Session established with the first server and simply run the Invoke-Command with $cred from there instead of nesting it. Although, running it from your attacking box centralizes tasking:
# From the WinRM connection
$pwd = ConvertTo-SecureString 'uiefgyvef$/E3' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential('DOMAIN\username', $pwd)
# Use "-Credential $cred" option in Powerview commands

Register PSSession Configuration

If instead of using evil-winrm you can use Enter-PSSession cmdlet you can then use Register-PSSessionConfiguration and reconnect to bypass the double hop problem:
# Register a new PS Session configuration
Register-PSSessionConfiguration -Name doublehopsess -RunAsCredential domain_name\username
# Restar WinRM
Restart-Service WinRM
# Get a PSSession
Enter-PSSession -ConfigurationName doublehopsess -ComputerName <pc_name> -Credential domain_name\username
# Check that in this case the TGT was sent and is in memory of the PSSession
# In this session you won't have the double hop problem anymore


Since we have Local Administrator on the intermediate target bizintel:, you can add a port forwarding rule to send your requests to the final/third server secdev:
Can quickly use netsh to rip out a one-liner and add the rule.
netsh interface portproxy add v4tov4 listenport=5446 listenaddress= connectport=5985 connectaddress=
So the first server is listening on port 5446 and will forward requests hitting 5446 off to the second server port 5985 (aka WinRM).
Then punch a hole in the Windows firewall, which can also be done with a swift netsh one-liner.
netsh advfirewall firewall add rule name=fwd dir=in action=allow protocol=TCP localport=5446
Now establish the session, which will forward us to the first server.


Portforwarding WinRM requests also seems to work when using winrs.exe. This may be a better options if you’re aware PowerShell is being monitored. The below command brings back “secdev” as the result of hostname.
winrs -r:http://bizintel:5446 -u:ta\redsuit -p:2600leet hostname
Like Invoke-Command, this can be easily scripted so the attacker can simply issue system commands as an argument. A generic batch script example winrm.bat:


This method requires installing OpenSSH on the first server box. Installing OpenSSH for Windows can be done completely via CLI and doesn’t take much time at all - plus it doesn’t flag as malware!
Of course in certain circumstances it may not be feasible, too cumbersome or may be a general OpSec risk.
This method may be especially useful on a jump box setup - with access to an otherwise inaccessible network. Once the SSH connection is established, the user/attacker can fire-off as many New-PSSession’s as needed against the segmented network without blasting into the double-hop issue.
When configured to use Password Authentication in OpenSSH (not keys or Kerberos), the logon type is 8 aka Network Clear text logon. This doesn’t mean your password is sent in the clear - it is in fact encrypted by SSH. Upon arrival it’s unencrypted into clear text via its authentication package for your session to further request juicy TGT’s!
This allows the intermediary server to request & obtain a TGT on your behalf to store locally on the intermediary server. Your session can then use this TGT to authenticate(PS remote) to additional servers.

OpenSSH Install Scenario

Download the latest OpenSSH Release zip from github onto you attacking box and move it over (or download it directly onto the jump box).
Uncompress the zip to where you’d like. Then, run the install script - Install-sshd.ps1
Lastly, just add a firewall rule to open port 22. Verify the SSH services are installed, and start them. Both of these services will need to be running for SSH to work.
If you receive a Connection reset error, update permissions to allow Everyone: Read & Execute on the root OpenSSH directory.
icacls.exe "C:\Users\redsuit\Documents\ssh\OpenSSH-Win64" /grant Everyone:RX /T