Shadow Credentials
Whilst Kerberos pre-authentication is typically carried out using a symmetric key derived from a client's password, asymmetric keys are also possible via Public Key Cryptography for Initial Authentication (PKINIT). There is, however, a use case where the key derived from the password is not used at all, and the pre-authentication scheme is conducted asymmetrically. This scenario is called Public Key Cryptography for Initial Authentication (PKINIT) and allows a user to obtain a TGT with a x509 certificate within Active Directory domains configured with a PKI (Public Key Infrastructure). It's worth noting that AD CS (Active Directory Certificate Services) is Microsoft's PKI implementation. This is called the Certificate Trust model.
The PKINIT protocol is a security protocol that authenticates entities on a network using public key cryptography. PKINIT is a pre-authentication extension that extends the Kerberos Protocol to use public key cryptography and TGT data signing during the initial AS exchange.
Microsoft introduced the concept of Key Trust in Windows Server 2016 to enable passwordless authentication in environments that don't support Certificate Trust. With Key Trust, PKINIT authentication is established using raw key data stored in the AD object's attribute called msDS-KeyCredentialLink instead of a certificate.
The client's public key is stored in the multi-value attribute, msDS-KeyCredentialLink. This attribute's values are Key Credentials, serialized objects containing information such as the creation date, the distinguished name of the owner, a GUID that represents a Device ID, and, of course, the public key. It is a multi-value attribute because an account has several linked devices.
This blog post is a good resource on the subject along with Whisker, which makes exploiting Shadow Credentials very easy.
Before starting the attack we need to enumerate which accounts have this ACL, either through BloodHound, powershell or impacket scripts
The msds-keycredentiallink attribute returned by this query contains Key Credentials, which are serialized objects that include information such as the creation date, the distinguished name of the owner, a GUID representing a Device ID, and, of course, the public key itself. Since an account can have multiple linked devices, msDS-KeyCredentialLink is a multi-value attribute. So, in summary, shadow credentials are a way to gain control over an Active Directory user or computer by exploiting the passwordless authentication function used in the Key Trust model. Suppose we have permission to modify the msDS-KeyCredentialLink attribute of the target object. In that case, we can add an alternate credential as a certificate to take control of the target.
First, we want to list any keys that might already be present for a target - this is important for when we want to clean up later.
Add a new key pair to the target.
And now, we can ask for a TGT using the Rubeus command that Whisker provides.
Whisker's clear command will remove any and all keys from msDS-KeyCredentialLink. This is a bad idea if a key was already present, because it will break legitimate passwordless authentication that was in place. If this was the case, you can list the entries again and only remove the one you want.
From linux this would be done using pywhisker and PKINITools
With the ticket we can get the NTLM hash of the user
or just use the ticket to access services.
Last updated