Detecting Shadow Credentials Attacks in Active Directory

In the landscape of Active Directory (AD) exploitation, the most dangerous attacks are not those that trigger loud,-latency-heavy password spraying or brute-force alerts, but those that leverage legitimate, built-in functionality to establish silent persistence. One such technique is the "Shadow Credentials" attack.

Unlike traditional credential theft, which involves extracting hashes from LSASS or cracking NT hashes, Shadow Credentials involve manipulating the `msDS-KeyCredentialLink` attribute of a target object. This allows an attacker to inject a public key into an object (such as a user or a computer), enabling them to authenticate via PKINIT (Kerberos Pre-Authentication) without ever knowing or changing the object's actual password. Because the password remains untouched, traditional password-rotation-based monitoring and standard account lockout policies are rendered useless.

The Mechanics of the Attack

To understand the detection challenge, we must first understand the underlying protocol. The attack exploits the way Windows handles certificate-based authentication through the Key Distribution Center (KDC).

The `msDS-KeyCredentialLink` attribute is a multi-valued attribute designed to support modern authentication methods, such as Windows Hello for Business (WHfB). When a user or device uses a cryptographic key for authentication, the public portion of that key is stored in this attribute. During the Kerberos AS-REQ (Authentication Service Request) phase, the KDC checks this attribute. If a valid key exists, the KDC can validate the user's identity via the PKINIT extension.

The attack follows a specific, highly surgical workflow:

1. Permission Acquisition: The attacker identifies a target object (e.g., a Domain Admin or a sensitive Service Account) for which they possess certain write permissions. These permissions are often overlooked, such as `GenericAll`, `GenericWrite`, or specifically `WriteProperty` on the `msDS-KeyCredentialLink` attribute.
2. Key Generation: The attacker generates a new RSA key pair locally.
3. Attribute Injection: Using a tool like `pyWhisker` or custom PowerShell scripts, the attacker encodes the public key into the format required by the `msDS-KeyCredentialLink` attribute and writes it to the target object in AD.
4. Authentication: The attacker uses the corresponding private key to perform a PKINIT-based Kerberos authentication. The KDC sees the public key in the attribute, validates the request, and issues a Ticket Granting Ticket (TGT).

The brilliance of this attack lies in its "shadow" nature: the attacker has gained the ability to impersonate the target, but the target's primary credential (the password) remains unchanged and seemingly valid.

Detection Strategies: Moving Beyond Password Monitoring

Detecting Shadow Credentials requires a shift from monitoring what changed (the password) to how the object's authentication capabilities were modified.

1. Monitoring Attribute Modification (Event ID 4662)

The primary detection vector is monitoring for modifications to the `msDS-KeyCredentialLink` attribute. This is captured via Windows Event ID 4662 ("An operation was performed on an object").

However, 4662 is notoriously noisy in large environments. To make this actionable, you must filter specifically for the GUID of the `msDS-KeyCredentialLink` attribute. Monitoring for any `Write` operation where the `AttributeName` matches the target GUID is the most effective way to identify the injection phase.

What to look for:

• Event ID: 4662
• Target Attribute: `msDS-KeyCredentialLink` (You will need to resolve the attribute's GUID in your SIEM).
• Subject User: The account performing the write. If this is not a known, authorized process or a highly privileged administrative account performing documented maintenance, it is a high-fidelity alert.

Lack of Kerberos Pre-Authentication Anomalies

Once the key is injected, the attacker authenticates. While the authentication itself looks like a legitimate PKINIT request, the context can be suspicious.

Monitor for Event ID 4768 (A Kerberos authentication ticket (TGT) was requested). While PKINIT is common for WHfB, an influx of TGT requests for sensitive accounts using `Pre-Authentication Type: 7` (PKINIT) from unusual source workstations or at unusual times should trigger investigation.

2. Identifying Over-Privileged Accounts

Detection is significantly easier if you proactively audit the permissions that enable the attack. The attack is only possible if an attacker can write to the `msDS-KeyCredentialLink` attribute.

Perform regular audits of AD permissions to identify accounts that possess `GenericWrite`, `WriteProperty`, or `AllExtendedRights` on sensitive objects. Specifically, look for "shadow admins"-users who do not belong to the "Domain Admins" group but possess enough delegated permissions to modify critical attributes on high-value targets.

Operational Considerations and The "False Positive" Trap

The greatest challenge in detecting Shadow Credentials is the legitimate use of Windows Hello for Business (WHfB).

WHfB functions by design using the `msDS-KeyCredentialLink` attribute. When a user sets up a PIN or biometric authentication, the system writes a new key to this attribute

Conclusion

As shown across "The Mechanics of the Attack", "Detection Strategies: Moving Beyond Password Monitoring", "Operational Considerations and The "False Positive" Trap", a secure implementation for detecting shadow credentials attacks in active directory depends on execution discipline as much as design.

The practical hardening path is to enforce deterministic identity policy evaluation with deny-by-default semantics, certificate lifecycle governance with strict chain/revocation checks, and host hardening baselines with tamper-resistant telemetry. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track false-allow rate and time-to-revoke privileged access and time from suspicious execution chain to host containment, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.