Threat Actor utilizing msDS‐KeyCredentialLink - ToddMaxey/Technical-Documentation GitHub Wiki

The msDS-KeyCredentialLink attribute, like msDS-KeyCredential, is used in Active Directory (AD) to store key-based authentication credentials. Specifically, it is associated with public keys for features such as Windows Hello for Business (WHfB) and FIDO2 security keys. While it is a critical component for enabling secure, passwordless authentication mechanisms, it can also be leveraged by threat actors in several ways if improperly secured or abused.

What is msDS-KeyCredentialLink?

  • Purpose: This attribute links a user's AD object to their key-based credentials. It stores information such as:

    • Public keys used for authentication.

    • Key metadata, including identifiers and associated devices.

    • It enables modern authentication methods like Windows Hello for Business and FIDO2.

  • Scope:

    • Stored on user objects in Active Directory.

    • Used during key-based authentication workflows.

Potential Threat Actor Exploitation

1. Credential Injection (Malicious Key Credential Registration)

A threat actor with write access to a user account's msDS-KeyCredentialLink attribute can add their own public key to the user's AD object. This allows the attacker to:

  • Authenticate as the compromised user using their own private key (corresponding to the malicious public key).

  • Bypass password-based protections like multi-factor authentication (MFA) because the attacker can now authenticate using the key-pair mechanism.

Example Scenario:

  1. The attacker compromises an administrative account (e.g., through phishing or privilege escalation).

  2. They inject their malicious public key into the msDS-KeyCredentialLink attribute of a high-value user (e.g., a domain admin or executive).

  3. The attacker can now authenticate as the compromised user without triggering password-related security controls.

2. Lateral Movement

By exploiting msDS-KeyCredentialLink, a threat actor can facilitate lateral movement within the environment:

  • Persistence: Adding malicious keys to multiple accounts enables persistence, even if passwords are reset or MFA is enforced.

  • Pivoting: The attacker can use compromised accounts to access sensitive systems or escalate privileges further.

3. Evasion of Detection

Using key-based authentication mechanisms rather than passwords can help threat actors evade detection because:

  • Traditional password monitoring tools (e.g., password spraying detection) do not apply.

  • The attacker does not need to brute-force credentials or rely on reusable passwords.

  • Malicious key usage may bypass MFA enforcement if the system prioritizes key-based logins.

4. Data Exfiltration or Abuse of High-Privilege Accounts

If the attacker targets high-privilege accounts (e.g., domain admins), they can use the key to:

  • Access sensitive resources and steal data.

  • Execute commands as the compromised user.

  • Modify or disable security settings.

5. Persistence

The msDS-KeyCredentialLink attribute provides an effective persistence mechanism for attackers:

  • Public keys injected into this attribute are less likely to be noticed than other persistence methods, such as modifying group memberships or GPOs.

  • Even if the account password is reset, the key-based credential remains valid until explicitly removed.

Techniques Threat Actors Might Use

1. Direct Access to Active Directory

  • An attacker with sufficient AD permissions (e.g., WriteProperty or GenericAll on a user object) can directly modify the msDS-KeyCredentialLink attribute using tools like:

    • PowerShell with the Active Directory module:

      Set-ADUser -Identity <UserName> -Add @{msDS-KeyCredentialLink="<malicious-key-data>"}

    • LDAP tools (e.g., ADSIEdit) to manipulate the attribute manually.

  • Privilege Escalation: If the attacker targets an admin or service account, they can gain elevated privileges.

2. Abuse of Legacy Permissions

  • Misconfigured ACLs (Access Control Lists) on user accounts can allow unauthorized users to write to the msDS-KeyCredentialLink attribute.

    • Example: If a service account has unnecessary write access to user objects, an attacker who compromises the service account could modify the msDS-KeyCredentialLink.

3. Use of Existing Tools

Threat actors can use existing tools to automate the exploitation of msDS-KeyCredentialLink:

  • Mimikatz:

    • Can manipulate credentials and attributes in Active Directory, potentially including msDS-KeyCredentialLink.

  • BloodHound:

    • Can map permissions and identify accounts with weak ACLs that allow writing to this attribute.

  • Custom LDAP Scripts:

    • Attackers can write scripts to scan AD for writable msDS-KeyCredentialLink attributes and inject malicious keys.

Mitigation and Defense Strategies

1. Secure Permissions on the Attribute

  • Restrict access to the msDS-KeyCredentialLink attribute:

    • Ensure that only authorized administrators have WriteProperty or GenericAll permissions.

    • Audit ACLs for user objects to identify any misconfigured permissions.

2. Monitor Changes to the Attribute

  • Use SIEM (Security Information and Event Management) tools to detect unauthorized modifications to msDS-KeyCredentialLink.

  • Audit changes to AD user objects, focusing on:

    • Changes to msDS-KeyCredentialLink.

    • Unexpected additions of public keys.

3. Enforce Conditional Access and MFA

  • Implement conditional access policies to ensure that key-based authentication cannot bypass other controls, like MFA or device compliance checks.

4. Remove Malicious Keys

  • Periodically review the msDS-KeyCredentialLink attribute for unexpected or unauthorized keys.

  • Remove any malicious or unknown public keys from user accounts.

5. Monitor Authentication Behavior

  • Look for unusual login patterns, such as:

    • Key-based logins from unknown devices or IP addresses.

    • Logins to high-value accounts (e.g., domain admins) without expected MFA prompts.

6. Educate Admins

  • Ensure Active Directory administrators understand the risks of improperly secured attributes, including msDS-KeyCredentialLink.

To identify the Domain Controller (DC) where the msDS-KeyCredentialLink attribute was modified, you can use the repadmin /showobjmeta command. This command shows metadata about object attributes in Active Directory, including when an attribute was modified, which DC made the change, and the version of the attribute.

Steps to Use repadmin /showobjmeta to Identify the DC

1. Identify the Target User Object

  • Determine the distinguished name (DN) or GUID of the user object whose msDS-KeyCredentialLink attribute you want to investigate.

  • You can find the DN of the user object in Active Directory Users and Computers (ADUC) or by using PowerShell:

    Get-ADUser -Identity <username> | Select-Object DistinguishedName

2. Run repadmin /showobjmeta

  • Use the repadmin tool to retrieve the metadata of the object. The metadata includes details about changes to the msDS-KeyCredentialLink attribute.

Command:

repadmin /showobjmeta <DCName> "<DistinguishedName>"

  • Replace <DCName> with the name of a domain controller (any DC in the domain).

  • Replace <DistinguishedName> with the DN of the user object.

Example:

repadmin /showobjmeta DC01 "CN=John Doe,OU=Users,DC=example,DC=com"

3. Analyze the Metadata

  • The output will include a table listing attributes of the object, their modification metadata, and replication metadata. Look for the row corresponding to msDS-KeyCredentialLink.

Key Columns to Check:

  • Ver: Indicates the version number of the attribute. A higher number suggests more recent changes.

  • Last Originating DSA: Shows the Domain Controller (DC) where the last modification originated.

  • Last Originating USN: The Update Sequence Number (USN) of the change.

  • Originating Time/Date: The timestamp when the attribute was last modified.

Example Output (Simplified):

Attribute               Ver    Last Originating DSA        Originating Time/Date 

----------------------  ----   --------------------------  ---------------------- 

msDS-KeyCredentialLink   3     DC02.example.com            2023-12-02 15:45:12

From this output:

  • msDS-KeyCredentialLink has a version of 3, meaning it has been modified three times.

  • The last change originated from DC02.example.com.

  • The change occurred on 2023-12-02 at 15:45:12.

4. Correlate the Information

  • Once you identify the DC (e.g., DC02.example.com) that made the modification, you can:

    • Inspect its event logs for more details about the change.

    • Trace the change back to the responsible user or process by reviewing relevant logs.

Using Event Logs for Additional Context

  • If auditing is enabled in Active Directory, you can check the Security Event Logs on the identified DC (DC02.example.com in this case) for events related to modifications of the msDS-KeyCredentialLink attribute.

  • Look for events such as:

    • Event ID 4662: "An operation was performed on an object."

      • This event provides details about the attribute modification, including the actor and the process.

Summary

To identify the DC where the msDS-KeyCredentialLink attribute was last modified:

  1. Use repadmin /showobjmeta to retrieve object metadata.

  2. Locate the msDS-KeyCredentialLink row in the output and check the Last Originating DSA column to find the DC that made the change.

  3. Correlate this information with security logs on the identified DC for more context about the modification.

⚠️ **GitHub.com Fallback** ⚠️