Abstract

If certain common requirements are met, it is possible to compromise the domain. When combined with other known exploits, the impact can escalate, particularly in environments with stringent security measures. Active Directory categorizes certificate mappings into two types: strong and weak, as outlined in KB50147541. The three mappings classified as strong are X509SKI, X509SHA1PublicKey, and X509IssuerSerialNumber.

However, I argue that X509SKI is as insecure as weaker mappings like X509SubjectOnly or X509RFC822. The issue lies in the fact that Active Directory inherently trusts “strong” mappings more than “weak” ones. Treating X509SKI as strong poses a security risk because the SKI (Subject Key Identifier) is merely a field that the certificate authority can populate with any arbitrary value. Active Directory then trusts this value without further verification. If a malicious or compromised certificate authority is added to the domain controller’s trusted certificate store and an SKI exists for a privileged account, that account is effectively compromised.

In contrast, the one well standing one strong bindings is X509SHA1PublicKey that depends on a SHA-1 collision, which is computationally challenging—especially as the collision must target a crafted certificate, not just any data.

While this issue is demonstrated through Remote Desktop Protocol (RDP), it potentially affects all authentication mechanisms. Addressing the classification of X509SKI as a strong binding is essential to improving security in Active Directory environments.

The problem

Certificate mappings

With the release of KB5014754, Microsoft introduced the distinction between Weak (insecure) and Strong explicit certificate mappings. The article outlines six different mappings, but this is where complications began to emerge.

The recommendation above is made by Microsoft in the old KB5014754, as of today I dont belive it is recommended.

So here we see that we have three strong mappings. The problem lies with the RFC for the SKI (Subject Key Identifier). This mapping is not as robust as Microsoft considers it to be.
When we refer to RFC5280, we find the following key point in section 4.2.1.2:

For end entity certificates, subject key identifiers SHOULD be derived from the public key. Two common methods for generating key identifiers from the public key are identified above.

Even within the RFC, there are multiple methods for calculating the SKI (Subject Key Identifier). This leaves it up to the Certificate Authority (CA) to determine how they choose to calculate it.
As a result, any CA can assign any SKI value. This lack of restriction means SKI should be classified as Weak, as there is no limitation on which CA issued the certificate.

Making a it worse

Carl Sörqvist has published a blog post discussing AMA abuse. When combined with my discovery, this makes any use of SKI particularly concerning.

Building your own certs with specific SKIs

Below are several methods for creating certificates with manually selected SKIs.

OpenSSL

Below is an OpenSSL configuration file that can be utilized for signing with OpenSSL.

[ ca ]
default_ca = CA_default
[ CA_default ] # Default settings for the CA
x509_extensions = extensions_section
[ extensions_section ]
crlDistributionPoints=URI:https://example.virot.eu/cve-2025-26647.crl
subjectKeyIdentifier=12:34:56:78:90:12:34:56:78:90:12:34:56:78:90:12:34:56:78:90
extendedKeyUsage = serverAuth, clientAuth, 1.3.6.1.4.1.311.20.2.2
keyUsage = critical, digitalSignature

Using the complete OpenSSL we can create a complete CA and sign a CSR using the newly created private key.

# Create a few required dirs and text files
echo 1000 > .\serial
echo 0100 > .\crlnumber
type nul > .\index.txt
# Generate a new private key for the CA
openssl genrsa -out ca.key 2048
# Generate a CA certificate called Partner CA
openssl req -config openssl_root.cnf -key ca.key -new -x509 -days 7300 -sha256 -extensions v3_ca -out ca.crt -subj "/C=SE/O=virot.eu/CN=CVE 2025 26647"
# Create a CRL to be uploaded
openssl ca -config openssl_root.cnf -gencrl -out out.crl
# Create a private key to be used later
openssl genrsa -out attacker.key 2048
# Create a CSR for the attacker key
openssl req -new -key attacker.key -out attacker.csr -subj "/C=SE/CN=Attacker"
# using the partner openssl_root.cnf that uses Partner CA private key to
# sign the Attacker CSR
openssl ca -in attacker.csr -out attacker.cer -config openssl_root.cnf -days 100

Certreq

PowershellYK

Since I was working with my PowerShell module for YubiKey , it is also possible to accomplish this using the module, when you sign with a private key placed on a YubiKey.

Build-YubikeyPIVSignCertificate -CertificateRequest identity.csr -Slot "Key Management" -Subjectname "CN=identity" -OutFile identity.crt -SKI "11111111"

Do I use SKI mapping?

The following PowerShell query can identify any accounts targeted in your domain:

Get-ADUser -LDAPFilter '(altsecurityidentities=*SKI*)' -Properties altsecurityidentities
Get-ADUser -LDAPFilter '(altsecurityidentities=*<SR>*)' -Properties altsecurityidentities

The solution

Microsoft patch

Microsoft has released Protections for CVE-2025-26647 (Kerberos Authentication). This page contains information about changes implemented by Microsoft. The patch will add a new registry key that allows Audit|Override possible|Enforced. Where first it will log, then it will be possible to delay then it will be enforced. All login certificate will have to chain back to the NTAuth store. This will limit the impact to own CA servers, as no others should be in the NTAuth. This will complicate things when you run outsourcing and want to use centrally issued smartcards for all customers.

My suggestion everyone running PKI

These are my suggestions if you are affected by this vulnerability:

• Avoid using SKI, as it is unsafe and can be exploited further when combined with other attacks.
• I would only use X509SHA1PublicKey if I needed to use altSecurityIdentities.
• Exercise extreme caution with the Certificate Authorities you trust on Domain Controllers and extremly careful when it comes in regards to NTAuth.

Timeline

• July 6th, 2024: Submitted vulnerability to MSRC
• July 17th, 2024: Microsoft confirms behavior
• August 22th, 2024: Microsoft requested extension of the release date to February 2025
• January 16th, 2025: Microsoft requested extension of the release date to April 2025
• April 8th, 2025: Microsoft releases CVE-2025-26647

Acknowledgements

Torbjörn Lofterud has been invaluable, from initially mentioning that the SKI was not calculated, to bouncing the MSRC submission with.

Microsoft corrections

In an draft version of this blog I suggested that the X509IssuerSerialNumber, was atleast better than SKI method, Microsoft has with a single line proved me wrong.