Shadow Credentials: How Attackers Create Backdoors in Active Directory Without Changing Main Passwords

To understand how Shadow Credentials operate, it is necessary to first examine the underlying infrastructure they exploit: Active Directory Certificate Services and the PKINIT protocol. Kerberos is the default authentication protocol in modern Active Directory environments. While Kerberos typically relies on symmetric cryptography using NTLM hashes derived from user passwords, it also supports asymmetric cryptography through the PKINIT extension. PKINIT allows a user or a machine to authenticate to the Domain Controller using a digital certificate and its corresponding private key instead of a password.

When PKINIT is enabled and properly configured, a user presents a certificate to the Key Distribution Center during the initial authentication request. If the certificate is valid, issued by a trusted Certificate Authority within the enterprise, and correctly mapped to a specific user account in Active Directory, the Domain Controller grants the user a Ticket Granting Ticket. This TGT can then be used to request access to various services across the network, exactly as if the user had authenticated with their standard password. Active Directory Certificate Services is the Microsoft implementation that issues and manages these certificates.

The critical vulnerability leveraged in a Shadow Credentials attack lies in how Active Directory maps a certificate to a user or computer object. While certificates can be mapped via implicit means (such as the User Principal Name embedded in the certificate), Active Directory also allows for explicit mapping. This explicit mapping is governed by a specific, multi-valued Active Directory attribute populated on the target user or computer object. It is the manipulation of this specific attribute that forms the core of the Shadow Credentials attack vector.

The Shadow Credentials technique centers entirely around the manipulation of the msDS-KeyCredentialLink attribute. This attribute, introduced in Windows Server 2016, was designed to support modern authentication features like Windows Hello for Business. It allows Active Directory to store the public key component of a cryptographic key pair directly on a user or computer object. When an authentication request via PKINIT is initiated using the corresponding private key, the Domain Controller verifies the request against the public key stored in the msDS-KeyCredentialLink attribute.

An attacker executing a Shadow Credentials attack first requires a certain level of privilege. They must compromise an account that possesses the GenericWrite or GenericAll permissions over the target user or computer object. This could be achieved by compromising a helpdesk account with delegated administrative rights or by exploiting a misconfiguration in Active Directory permissions.

Once the requisite permissions are acquired, the attacker's methodology is elegantly simple yet devastatingly effective. The attacker generates a new, self-signed RSA key pair on their own machine. They retain the private key. Then, utilizing their compromised account with write access, they append the public key portion of their newly generated key pair to the target object's msDS-KeyCredentialLink attribute. Active Directory accepts this update. The attacker has now explicitly mapped their own cryptographic material to the victim's account.

Crucially, the attacker does not need to interact with the target organization's Certificate Authority. Because the public key is explicitly stored on the object itself, the Domain Controller implicitly trusts it for authentication purposes, provided the environment is configured to support this authentication path. The attacker can now request a Kerberos TGT on behalf of the target user by authenticating with their retained private key via PKINIT. They achieve full authentication as the target user, entirely bypassing the victim's actual password and any associated password rotation policies.

The primary reason threat actors utilize Shadow Credentials is the unparalleled stealth and persistence the technique offers compared to traditional methods. When an attacker changes a user's password to establish persistence, the user is immediately locked out of their account. This disruption inevitably results in a helpdesk ticket, prompting a password reset and an immediate investigation by the security team. The attacker's persistence mechanism is neutralized almost instantly, and their presence is detected.

Conversely, adding a public key to the msDS-KeyCredentialLink attribute is a silent operation. The victim's original password remains perfectly valid and unchanged. The victim can continue to log in, access their emails, and perform their daily tasks without any indication that their account has been compromised. The attacker operates concurrently, utilizing the "shadow" credential to access the network. This dual-access scenario makes detection significantly more challenging, as there are no obvious disruptions to normal user activity.

Furthermore, Shadow Credentials provide extraordinary resilience against routine security remediation efforts. In a standard incident response scenario, if an account is suspected of being compromised, the standard procedure is to force a password reset. However, resetting the target user's password has absolutely no effect on the Shadow Credentials. The attacker's persistence is tied to the public key stored in the msDS-KeyCredentialLink attribute, not the user's NTLM hash. Therefore, even after a mandatory password rotation, the attacker can seamlessly continue to request TGTs and access the network using their private key. Until the unauthorized public key is explicitly removed from the attribute, the attacker maintains administrative control over the account.

Detecting the use of Shadow Credentials requires security teams to pivot their monitoring strategies away from standard password-based authentication anomalies and focus specifically on modifications to Active Directory attributes and PKINIT authentication events. Relying solely on traditional Intrusion Detection Systems or basic log analysis is insufficient to uncover this stealthy persistence mechanism.

The most direct method of detection is monitoring Active Directory for any modifications to the msDS-KeyCredentialLink attribute. Security Information and Event Management systems should be configured to ingest and alert on Windows Security Event ID 5136 (A directory service object was modified). Analysts must specifically filter these events to identify when the msDS-KeyCredentialLink property is added or altered. Any modification to this attribute, especially on high-value targets like Domain Admin accounts or critical servers, should be treated as highly suspicious and immediately investigated. It is crucial to establish a baseline of normal activity, as legitimate features like Windows Hello for Business will also modify this attribute. Differentiating between a legitimate system process adding a key and an attacker utilizing tools like Whisker or targeted PowerShell scripts is critical.

Additionally, organizations must monitor for the actual authentication events that utilize the Shadow Credentials. When an attacker uses their private key to request a TGT via PKINIT, the Domain Controller logs specific event IDs. Security teams should monitor Event ID 4768 (A Kerberos authentication ticket (TGT) was requested). Within this event, analysts should scrutinize the "Certificate Information" fields. If an authentication request is successful but the certificate information appears irregular, lacks a standard Certificate Authority structure, or does not align with the organization's known PKI deployment, it strongly indicates the potential use of Shadow Credentials.

Proactive auditing is equally important. Security teams should regularly query Active Directory to identify all user and computer objects that currently have the msDS-KeyCredentialLink attribute populated. This can be accomplished using specialized PowerShell modules or Active Directory auditing tools. By periodically reviewing these objects, organizations can identify potentially unauthorized keys that may have been implanted prior to the implementation of robust monitoring, ensuring that legacy persistence mechanisms are discovered and eradicated.

Defending against Shadow Credentials requires a comprehensive, defense-in-depth approach that addresses the underlying permissions model of Active Directory and hardens the authentication infrastructure. There is no single "patch" to prevent this technique, as it abuses legitimate functionality; therefore, mitigation relies on strict configuration management and continuous monitoring.

The most fundamental mitigation strategy is the rigorous enforcement of the principle of least privilege regarding Active Directory access control lists. The Shadow Credentials attack is entirely dependent on the attacker possessing the ability to write to the msDS-KeyCredentialLink attribute. Therefore, organizations must meticulously review and audit the permissions delegated across their domain. Security teams must ensure that generic write permissions (GenericWrite, GenericAll, WriteProperty) are not overly permissive. Helpdesk staff, service accounts, and lower-tier administrators should not possess the ability to modify critical attributes on high-tier administrative accounts or sensitive computer objects. Regularly auditing ACLs using tools like BloodHound can help visualize and remediate these dangerous permission paths before an attacker can exploit them.

Another critical defense layer involves protecting high-value targets through the implementation of the Protected Users Security Group. Adding sensitive accounts (such as Domain Admins and Enterprise Admins) to this group significantly hardens their authentication requirements. Among other restrictions, accounts in the Protected Users group are prevented from authenticating via NTLM, and their Kerberos TGTs have a significantly reduced lifetime. While this group does not inherently prevent the modification of the msDS-KeyCredentialLink attribute, the overall hardening it provides makes the lateral movement required to reach a position to execute the attack substantially more difficult for an adversary.

Finally, organizations should evaluate their reliance on PKINIT and Active Directory Certificate Services. If the environment does not utilize features like Windows Hello for Business or smart card authentication, the attack surface can be reduced. While disabling the functionality entirely may not be feasible for all organizations, strictly controlling the infrastructure required for PKINIT (such as ensuring Domain Controllers do not possess the specific certificates required for this authentication path if it is not actively used) can disrupt the attacker's ability to successfully request a TGT, even if they manage to populate the msDS-KeyCredentialLink attribute.