Accidental Sabotage: Beware of CredSSP

One common issue that an administrator faces when using PowerShell remoting is the “double hop” problem. An administrator uses PowerShell remoting to connect to Server A and then attempts to connect from Server A to Server B. Unfortunately, the second connection fails.

The reason is that, by default, PowerShell remoting authenticates using a “Network Logon”.  Network Logons work by proving to the remote server that you have possession of the users credential without sending the credential to that server (see Kerberos and NTLM authentication). Because the remote server doesn’t have possession of your credential, when you try to make the second hop (from Server A to Server B) it fails because Server A doesn’t have a credential to authenticate to Server B with.

To get around this issue, PowerShell provides the CredSSP (Credential Security Support Provider) option. When using CredSSP, PowerShell will perform a “Network Clear-text Logon” instead of a “Network Logon”. Network Clear-text Logon works by sending the user’s clear-text password to the remote server. When using CredSSP, Server A will be sent the user’s clear-text password, and will therefore be able to authenticate to Server B. Double hop works!

Figure 1: The computers colored red have the user credentials cached on them.

While this is certainly convenient, it comes at a price: If the server you authenticate to using CredSSP is compromised, so are your credentials.

An attacker with administrative privilege on a server can intercept any data that is sent to/from the server, as well as view any data in memory and on disk, by design. Because the CredSSP authentication option sends your clear-text credentials to the remote server, an attacker with administrative privilege on the remote server can easily intercept your username and password.

To prove this to you, I’ll do a quick demonstration.

First, I’ll create a PSSession to connect to a remote session using CredSSP; then I will run Mimikatz, a hacker tool used to capture the credentials of users logged in to the server. Because this is PowerShell Magazine, I will use a version of Mimikatz, called Invoke-Mimikatz, which has been modified to run as a PowerShell script.

Figure 2: Connecting to a server using CredSSP and running Invoke-Mimikatz

Figure 3: Mimikatz output showing that the credentials for DEMO\administrator are stored on a remote server when using CredSSP

Next, I’ll create a PSSession to connect to a remote computer without using CredSSP. This time, Mimikatz isn’t able to capture any credentials.

Figure 4: Connecting to a server without using CredSSP and running Invoke-Mimikatz

This shows that when you use CredSSP, your credentials can be captured on the remote computer. If you don’t use CredSSP, you can authenticate to any server you’d like without disclosing your credentials (which makes it harder for an attacker to obtain privileged credentials).

Is it ever safe to use CredSSP? Certainly. The important thing to realize is that you are putting your credentials on the server you authenticate to. It is a bad idea to use CredSSP to authenticate to a user’s workstation using a domain administrator account; you are essentially giving away the keys to the kingdom. It would be perfectly acceptable to use a domain administrator to authenticate to a domain controller using CredSSP because the domain controller is a high trust server.

Designing safe operating procedures is outside the scope of this article, but the general rule is: Don’t put high trust credentials on low trust computers. Additionally, you should always try to design your systems to work with single-hop rather than double-hop so that CredSSP isn’t needed.

Update: This testing was done using Windows Server 2012. Microsoft has made changes to Windows Server 2012R2 and Windows 8.1 to eliminate clear-text credentials from being stored in memory. This means that an attacker who runs Mimikatz will no longer see your clear-text credentials. An attacker will still see your NT password hash and your Kerberos TGT, both of which are password equivalent and can be used to authenticate as you over the network.

Additionally, even though your clear-text credential is not saved in memory, it is still sent to the remote server. An attacker can inject malicious code in the Local Security Authority Subsystem Service (LSASS.exe) and intercept your password in transit. So while you may not see your password with Mimikatz anymore, your password can still be recovered by an attacker.

Filed in: Articles, Online Only Tags: ,

33 Responses to "Accidental Sabotage: Beware of CredSSP"

  1. Mad Tom Vane says:

    Wow thanks for the information. Any links for alternatives to CredSSP with PowerShell remoting?

    • Joe Bialek says:

      I don’t have links for you. Just don’t use CredSSP. Try to design your systems to use single hop instead of double hop (for example, push files to a server instead of using double hop to download the files to the server). I don’t have any specific documentation to provide you with though, and most of the time the way you do something will be specific to the problem you are trying to solve.

    • ramblingcookiemonster says:

      Mad Tom Vane – Do you use RDP to connect to these endpoints? Heck, do you log in to these endpoints interactively? This article is simply pointing out that if you don’t trust the endpoint, you shouldn’t connect to it.

      Realistically, this is a small risk in the scheme of things (See Trond’s post). Consider the risks, but I would recommend using CredSSP to connect to computers you trust. Servers. Locked down workstations (e.g. if you have an administrative VM).

      If you are talking servers, and you are worried that an attacker has administrative privileges on that server, you have way bigger problems than worrying about CredSSP.

      • Rob Campbell says:

        If you need to work interactively, Powershell Remoting (Enter-PSSession) does NOT store credentials in the LSASS cache.

      • Joe Bialek says:

        I disagree with your assertion that you should basically trust all your servers to not be compromised. You should always assume breach and design your network to survive even if portions of it are compromised. Realistically, the risk of using CredSSP is pretty huge. I attack networks for a living, and it is extremely convenient for me when people automate everything with CredSSP because it pretty much guarantees I’m going to easily obtain credentials that have administrative privilege everywhere.

  2. Nice – I didn’t know about mimikatz before. Great tool!

  3. Sergey Gruzdov says:

    Restrict session via StartupScript and use CredSSP without fear

  4. Trond Hindenes says:

    I don’t disagree with the article, but it needs to be seen in a larger context. For example, it’s easy to tap into the LSASS chache and exploit the credentials of any user who has been logged on interactively (using username/password) since the last boot. So, any server where admins log on through RPD for instance, using their password (as opposed to smart cards) can be compromised in about 5 seconds if the attacker has administrative access to the same server. CredSSP is not your only worry if you care about security.

    • Joe Bialek says:

      That is certainly true. Any form of authentication that sends a credential to the remote server is unsafe. Local login, remote desktop, anything using basic auth, etc etc.. The point of this article is to highlight that CredSSP is one of those unsafe ways to authenticate to a remote server because a lot of people don’t realize how CredSSP works.

      Thanks for adding the additional context!

    • RJasonMorgan says:

      I was about to ask about RDP, thanks for the clarifying question!

  5. Jeffrey Snover says:

    Great explanation Joe. I’ve been warning people about the dangers of using CredSSP for some time (attendees of the first PowerShell summit should remember THAT discussion). Now I have a fantastic explanation that I can just point people to. Thanks!

    Jeffrey Snover[MSFT]

  6. Dave Wyatt says:

    As the Security folks will be quick to point out, you don’t really need a user’s clear-text credentials in order to do bad things. The NTLM hash or Kerberos TGT is enough to impersonate another user, if an attacker can get their hands on them (using a tool such as mimikatz). If someone gets Admin rights to virtually any machine on your network, you could already be in pretty deep trouble.
    Anyhow, if you’re not using Kerberos for authentication with PSRemoting, then it’s a good idea to make sure you’re using SSL. That will at least authenticate the server side of the connection, and help prevent you from sending your credentials (in any form) to a rogue server.

    • Joe Bialek says:

      I want to make sure it is explicitly clear that while getting ahold of the the NTLM hash or Kerberos TGT is password equivalent, doing a “Network Logon” (NTLM authentication or Kerberos authentication) does NOT expose these to the remote server. By default, PowerShell uses “Network Logon”, so there would be NOTHING on the remote server for an attacker to steal.

      • Dave Wyatt says:

        True, but it’s still bad to attempt NTLM authentication to a rogue server. Even though the hash isn’t sent directly in the “Network Logon” scenario, after you go through the NTLM challenge/response process, the attacker can try to recover the hash offline via brute force. (As far as I know, NTLMv2 responses with reasonably strong passwords are still secure from this type of attack, but weak passwords and NTLM / LM responses are toast.)

  7. Steve Mahoney says:

    So using CredSSP, would the password also be exposed to network points like switches and routers? It sounds like it would be.

  8. ramblingcookiemonster says:

    A quick note – when logged in, I can’t view replies from Joe Bialek and Rob Campbell. When logged out, or when browsing Disqus, I see them. Very odd!

    Back on point!

    Joe – I completely agree that the assumption of compromise is the way to go. That being said, one important aspect of security is the balance of the risk and reward. We wouldn’t have businesses if eliminating risk were the goal, rather than managing risk. There are likely more important priorities than preventing CredSSP use on trusted servers, leading to situations where security teams will disallow CredSSP (or worse – try to lock down PowerShell itself) rather than focusing their efforts on issues that present a larger security risk with a smaller reward. Basically, organizations should consider the risks, rather than assuming all risks should be eliminated.
    Thanks for the update on 2012 R2, another reason to update : )
    Rob – That’s good to know, thanks for pointing it out!

  9. Sergey Gruzdov says:

    I would like to explain my position. Linked image is sreenshot of our Powershell Web Access server, used by junior admins to do some of service tasks. Authentication provider is CredSSP (some of comandlets invokes commands on remote server) over SSL, session is restricted via StartupScript. As you can see, only some of comandlets are available, also no access to hard drives and network resources is possible. In this case it’s impossible to obtain any security related information (even you logged in as user with administrative priviledges on server)

  10. Jane says:

    Hey there Clymb3r, a big fan from Croatia here, just wanted to let you know that your blog is doing pretty good on this side of the world, thanks for all the tutorials and excellent examples 🙂

Leave a Reply

Submit Comment

© 2018 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: