Kerberos Double Hop

The double hop problem arises when we try to use Kerberos authentication across two or more hops: for example, we come in over WinRM to host A and from there want to query the directory or reach a resource on host B. The action is denied even though the user has the rights. It is not a bug but a consequence of how Kerberos works: a ticket is not a password, it is a signed grant for one specific resource.

Mechanism

When we authenticate over WinRM with Kerberos we receive a TGS for that service on host A, which lets us run commands there, but the user's TGT never travels to the remote session. When we try to reach B from A, there is no TGT to present to the KDC to request a fresh ticket, so we cannot prove our identity and access is refused. With a password or pass-the-hash (via PsExec, say) this does not happen, because the NTLM hash is cached in the session and the machine reuses it; with Kerberos over WinRM the session stores no credentials, and Mimikatz shows them blank.

Requirements

It occurs when chaining remote sessions that use Kerberos without delegation, typically WinRM/evil-winrm. There are two common workarounds. The first, if you are working from a shell, is to resend credentials on every request with a PSCredential object and a nested Invoke-Command:

$sess = New-PSSession -ComputerName <target> -Credential $cred
Invoke-Command -Session $sess -ScriptBlock { whoami; Get-DomainUser -spn } -Credential $cred

The second, with access to a Windows host, is to enable CredSSP, which does delegate the credentials to the second hop:

Enable-WSManCredSSP -Role Client -DelegateComputer <target>

How to detect it

CredSSP is the interesting part for the defender: by delegating the full credential, it ends up in the target host's memory and can be stolen. Watch for CredSSP being enabled (AllowFreshCredentials under HKLM\...\CredentialsDelegation), WinRM sessions with delegation turned on, and custom Register-PSSessionConfiguration entries, which are another way around the double hop and, at the same time, a persistence backdoor.

Defence. Avoid CredSSP unless justified, prefer protocols that do not require a double hop, limit who can create session configurations, and audit delegations. Related to pass the ticket, overpass the hash and Kerberoasting.