Kerberos Double Hop Problem: Secure Solutions for PowerShell Remoting Without CredSSP
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The double-hop problem is real and common -- any admin who has connected to a server via PowerShell Remoting and then tried to access a network share discovers it immediately. CredSSP works but is widely misunderstood as safe when it actually passes credentials to the intermediate server. This guide explains why CredSSP is risky, and shows three secure alternatives that solve the double-hop problem without credential exposure.
Why CredSSP Is a Security Problem
CredSSP works by delegating the user's full Network Service credentials to the intermediate server. The server decrypts and stores these credentials in its LSA process memory for the duration of the session. If the intermediate server is compromised (by malware, an attacker with admin access, or Mimikatz running on it), those delegated credentials are extractable from LSASS memory -- including admin credentials. This is the 'overpass-the-hash' risk: using CredSSP to connect a Domain Admin account through a general-purpose server exposes Domain Admin credentials to every process running as SYSTEM on that server. The risk compounds when CredSSP is enabled broadly -- enabling it on all servers in an environment means any compromised server becomes a credential harvesting opportunity. Check how widely CredSSP is enabled in your environment: Get-WSManCredSSP on each server returns whether CredSSP is enabled for client or server use. Any server with CredSSP enabled as a delegate target for privileged accounts is a potential credential exposure point.
Solution 1: Resource-Based Constrained Delegation (RBCD)
RBCD allows the resource (Server B) to specify which accounts or services are allowed to delegate to it. Setup for PowerShell Remoting double-hop: Server A needs to be able to delegate the connected user's identity to Server B. Configure RBCD on Server B to trust Server A: $SID = (Get-ADComputer ServerA).SID; Set-ADComputer ServerB -PrincipalsAllowedToActOnBehalfOfOtherIdentity (New-Object System.Security.Principal.SecurityIdentifier($SID)). After this, when a user connects to Server A via PowerShell Remoting and Server A needs to access Server B, Server A can use S4U2proxy (Service-for-User-to-Proxy) Kerberos extension to obtain a service ticket for Server B on behalf of the connected user -- without holding the user's credentials. The benefit: no credentials are transmitted to Server A. The limitation: requires admin rights to configure on Server B, and is specific to the Server A to Server B delegation path. Configure it for each hop that needs to work.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Solution 2: Just Enough Administration (JEA) Endpoints
JEA solves the double-hop problem differently: instead of delegating the user's identity through the hop, the JEA endpoint runs under a virtual account or group Managed Service Account (gMSA) that has the required access to the second resource. The user connects to the JEA endpoint with their own identity, but the JEA session runs as the virtual account on the intermediate server. When the JEA session accesses Server B, it authenticates as the virtual account, not as the connecting user. Setup: create a JEA Role Capability file that defines allowed commands, and a JEA Session Configuration file that specifies RunAsVirtualAccount = $true. Register the JEA endpoint: Register-PSSessionConfiguration -Name 'JEA-FileServer' -Path 'C:\JEA\SessionConfig.pssc'. Grant the virtual account or gMSA access to Server B's resources. The benefit: the connecting user never has credentials on Server A; the virtual account's access is scoped to only what the JEA role allows. The limitation: requires pre-defining exactly which commands and resources are needed in the JEA role.
Solution 3: Explicit Credential Passing with a Service Account
For scenarios where RBCD and JEA are not practical (complex multi-hop chains, dynamic resource access), a safer alternative to CredSSP is passing explicit credentials to the second hop using a dedicated service account stored in a PAM vault. The pattern: in the PowerShell session on Server A, retrieve the service account credentials from a secrets manager (HashiCorp Vault, CyberArk, or Windows Credential Manager) and use -Credential parameter for the second hop: $cred = Get-PAMCredential -AccountName 'svc-file-access'; Copy-Item -Path '\ServerB\share\file.txt' -Destination C:\ -Credential $cred. The service account has only the minimum required access to the second-hop resource. This avoids transmitting the admin user's credentials but does require a dedicated service account per resource type. The service account's password should be automatically rotated via PAM and should not be known to any individual. This approach is common for automation scripts that run non-interactively and need to access multiple resources.
Audit and Disable Unnecessary CredSSP
If CredSSP is currently enabled in your environment for double-hop workarounds, audit and migrate to one of the above solutions. Enumerate: Invoke-Command -ComputerName (Get-ADComputer -Filter *).Name -ScriptBlock { Get-WSManCredSSP } 2>$null | Where-Object { $_ -match 'The machine is configured' }. For each server where CredSSP is enabled as a delegate target: identify the use case that requires it. Implement RBCD, JEA, or service account alternatives. Disable CredSSP after migration: Disable-WSManCredSSP -Role Server on the intermediate server, Disable-WSManCredSSP -Role Client on the connecting workstation. If CredSSP cannot be disabled immediately because of a blocking dependency, restrict which accounts are allowed to use CredSSP delegation: do not allow Domain Admin or Tier 0 accounts to use CredSSP under any circumstances. Create a Conditional Access or PAM policy that prevents privileged accounts from using CredSSP.
The bottom line
CredSSP solves the double-hop problem by putting credentials on every intermediate server -- a design that creates credential theft risk at scale. RBCD is the recommended solution for server-to-server delegation in scripted or automated scenarios. JEA is the recommended solution for defined administrative task endpoints. Both are more secure than CredSSP and do not expose the connecting user's credentials to the intermediate server. Audit CredSSP usage in your environment and migrate each use case to a safer alternative.
Frequently asked questions
Why doesn't Kerberos allow credential forwarding for the second hop by default?
This is by design for security. If Kerberos allowed unlimited credential forwarding, a compromised intermediate server could forward a user's credentials to any server in the domain, enabling lateral movement. The controlled delegation mechanisms (constrained delegation, RBCD) are the intended way to allow specific, scoped second-hop scenarios while containing the attack surface. Unconstrained delegation (which does allow unlimited forwarding) is a known attack vector and should be avoided.
Does using Invoke-Command with -Credential solve the double-hop problem?
Invoke-Command -Credential passes credentials for the WinRM authentication to the remote server, but once inside that remote session, you still face the double-hop problem -- the remote session cannot forward those credentials to a third system via Kerberos. The -Credential parameter on Invoke-Command only solves authentication to the first hop. For the second hop from within the remote session, you still need RBCD, JEA, or explicit credential passing to the second-hop resource.
Is CredSSP ever acceptable to use?
CredSSP is acceptable in very limited, controlled scenarios: the intermediate server is fully trusted (Tier 0 hardened, no non-admin access), the connecting account credentials are low-privilege and non-sensitive (not Domain Admin), the CredSSP connection is transient and not persistent, and no alternative is technically feasible. For privileged admin accounts, CredSSP should never be used -- the risk of exposing Domain Admin credentials on an intermediate server is not acceptable regardless of how trusted that server is.
Does Constrained Delegation (not RBCD) solve the double-hop problem?
Yes, traditional constrained delegation on the intermediate server's service account (not RBCD) also solves the double-hop problem. The configuration is on the intermediate server's machine or service account: set msDS-AllowedToDelegateTo to the target SPN on Server B. The difference from RBCD: constrained delegation is configured on the delegating account (Server A), while RBCD is configured on the resource (Server B). RBCD is generally preferred in modern environments because it requires only write access to Server B's AD object (not domain admin rights to modify Server A's delegation settings).
How do I configure JEA (Just Enough Administration) as an alternative to CredSSP for administrative double-hop scenarios?
JEA restricts PowerShell remoting sessions to a predefined set of commands that the endpoint is authorized to run. Instead of forwarding the connecting user's credentials to run arbitrary commands on the intermediate server, JEA runs commands under a virtual account (local admin on the JEA endpoint) or a Group Managed Service Account. The administrator connects to the JEA endpoint via PowerShell remoting and can only run the commands defined in the Role Capability file -- there are no credentials to forward because the commands are executed by the pre-configured service identity, not the user's identity. JEA configuration requires: a Session Configuration file (RegisterPSSessionConfiguration), Role Capability files (.psrc) defining allowed commands, and a constrained language mode setting.
How do you detect when CredSSP is being abused in your environment versus used legitimately?
CredSSP abuse detection focuses on identifying CredSSP usage outside of expected administrative workflows. Legitimate CredSSP usage is typically limited to specific jump servers connecting to specific Hyper-V hosts or specific administrative tools that cannot be redesigned. Detection points: Windows Remote Management (WinRM) connections using CredSSP generate Event ID 4648 (explicit credentials used) on the initiating system and Event ID 4624 with LogonType 3 on the destination. Unlike standard Kerberos remoting, CredSSP connections pass the actual credentials to the remote server; the remote server's Event ID 4624 shows the full credential rather than a service ticket. Monitor for CredSSP usage (AllowFreshCredentials group policy applied) on non-server endpoints -- workstations should almost never originate CredSSP connections. Sysmon process creation events for wsmprovhost.exe (the WinRM host process) on target servers, correlated with the source IP, can identify unusual CredSSP targets. If an attacker uses CredSSP for lateral movement after compromising a CredSSP-enabled account, the credential forwarding means the destination server sees a Type 3 logon with the user's actual credentials -- the same artifacts produced by legitimate use, which is why CredSSP elimination rather than detection is the recommended approach.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.