I decided to investigate the Windows Kerberos Elevation of Privilege vulnerability, CVE-2025-26647. It's a vulnerability related to Active Directory authentication with a CVSS v3 base score of 8.8, which gives off a pretty dangerous vibe, yet it hasn't gotten much attention. I'd like to explore why that might be.
Target Audience
This article is for those who enjoy the technical details and vulnerabilities surrounding Active Directory, PKI, and certificate authentication. My main goal is to share information with fellow enthusiasts, as there isn't much out there about this particular vulnerability. I'll be skipping detailed explanations of specialized terms and procedures 🙇.
If you're only interested in whether this is a useful attack vector (or just want an exploit script), I think you can safely ignore CVE-2025-26647.
If you want to know if your environment is affected and what countermeasures to take, the Japan Microsoft corporate blog has an excellent and detailed post, so please check that out 🙏.
What is CVE-2025-26647?
Since I couldn't find any information from the vulnerability's discoverer, I'll start by trying to understand what it is from official sources.
- Microsoft Japan Windows Technology Support Blog: CVE-2025-26647 への対応とその影響について (Japanese)
- MSRC: Windows Kerberos Elevation of Privilege Vulnerability
- The Japanese translation has some errors, so I recommend setting your browser's language to English.
- Microsoft Support: Protections for CVE-2025-26647 (Kerberos Authentication)
- NVD: CVE-2025-26647 Detail
Here's a quick summary:
- An elevation of privilege vulnerability in Active Directory Domain Services (AD DS) Kerberos authentication.
- The CVSS score suggests it's easy to attack with high impact, but the likelihood of exploitation is low.
- It affects systems where the
altSecurityIdentitiesattribute is configured on an Active Directory user account.
Many of you might be wondering, "What on earth is the altSecurityIdentities attribute?"
If you want to know more, the Japan Microsoft blog is again the best source (those folks are amazing 💪).
altSecurityIdentities is an attribute used to map certificates to user accounts, intended to enhance security.
In recent years, certificate authentication in Active Directory has been strengthened, making it mandatory to either map a certificate to an account (via the altSecurityIdentities attribute) or map account information into the certificate.
However, it seems that having the altSecurityIdentities attribute configured could make you vulnerable to CVE-2025-26647, potentially leading to privilege escalation.
Furthermore, looking at the description for the patch, KB5057784, the term "NTAuth store" comes up. The NTAuth store is an independent store for certificate authentication, distinct from the OS's certificate store that holds CA certificates normally trusted by Windows. Certificates used for authentication must be issued by a CA whose certificate is in the NTAuth store. You can't just use a client certificate issued by a CA in the OS's main certificate store and expect authentication to work. If the NTAuth store mechanism didn't exist, any client certificate issued by a CA that Windows trusts by default could potentially be used to authenticate against any Active Directory, which would be dangerous.
For those who have read the official info, you might have noticed something.
It seems that KB5057784 is a fix to properly check the NTAuth store's certificate chain, and CVE-2025-26647 is basically saying, "Oops, we weren't checking the NTAuth store chain if the altSecurityIdentities attribute was set." This sounds like it could lead to the dangerous situation I just described.
For anyone with a taste for PKI, this is the kind of story that makes you do a spit-take...😗💦 I just had to check it out for myself!
Verification
I performed the verification with the following steps:
- Set up AD DS on a Windows Server 2022 before the CVE-2025-26647 patch, KB5057784, was applied.
- Built three PKIs with OpenSSL and configured trust in AD DS as follows:
- ca1: A CA trusted in both the OS certificate store and the NTAuth store.
- ca2: A CA trusted only in the OS certificate store.
- ca3: An untrusted CA.
- Issued a domain controller certificate from ca1 and installed it on the AD DS.
- This is necessary for certificate authentication but isn't critically important for this particular verification.
- Created a domain user account.
- Let's call it
user1.
- Let's call it
- Issued a client certificate for
user1from ca1. - Configured the
altSecurityIdentitiesattribute ofuser1in AD DS with the information from the client certificate issued by ca1. - Issued client certificates from ca2 and ca3 that mimic the
altSecurityIdentitiesattribute ofuser1. - Attempted to log in to AD DS via certificate authentication using the client certificates issued by ca1, ca2, and ca3.
- Applied KB5057784 and repeated step 8.
Step 7 is the key part of this verification, so let me explain a bit.
For example, let's say we decide to use the X509SKI format for the altSecurityIdentities attribute, and the Subject Key Identifier (SKI) of the client certificate from ca1 is 8300551F715CE58581CF06636FC8DF64B4EB1276.
In this case, the altSecurityIdentities attribute for user1 would be set to X509:<SKI>8300551F715CE58581CF06636FC8DF64B4EB1276.
Then, when issuing client certificates for user1 from ca2 and ca3, we set their SKI to be 8300551F715CE58581CF06636FC8DF64B4EB1276.
The SKI is normally calculated from the public key, but it's possible to set an arbitrary value using OpenSSL or a custom program.
The CVSS rating of "easy to attack" is likely because this is all it takes.
The values of the altSecurityIdentities attribute can be easily enumerated over the network with just domain user credentials.
For attributes that are difficult to set with OpenSSL, I was able to easily create a program for this by giving instructions to a generative AI.
Verification Results
Here are the results when using the X509SKI format for the altSecurityIdentities attribute.
As expected, before applying KB5057784, certificate authentication succeeded even with the client certificate from ca2, which is not trusted by the NTAuth store.
| PKI | OS Cert Store | NTAuth Store | Before KB5057784 | After KB5057784 |
|---|---|---|---|---|
| ca1 | Trusted | Trusted | Auth Success | Auth Success |
| ca2 | Trusted | Untrusted | Auth Success | Auth Failure |
| ca3 | Untrusted | Untrusted | Auth Failure | Auth Failure |
Other Formats
I also tried the X509IssuerSerialNumber format.
For the altSecurityIdentities attribute, two pieces of information need to match ca1:
- The issuer of the client certificate.
- The serial number of the client certificate.
The serial number can just be copied, but this means we have to issue a certificate from ca2 that claims its issuer is ca1. After some trial and error, I found that even before applying KB5057784, the spoofed certificate from ca2 failed to authenticate. It might be possible if the issuer names of ca2 and ca1 were truly identical, but that seems unlikely in a realistic scenario, so I stopped there.
Three other mapping formats are mentioned as potentially affected. I haven't tested them, but here are some thoughts:
X509SHA1PublicKey: Would require forging a public key, which I believe would fail.X509IssuerSubject: Similar toX509IssuerSerialNumber, would require forging the issuer name, which seems practically difficult.X509SubjectOnly: Seems like it could be vulnerable to spoofing.
Another mapping method, X509RFC822, was likely excluded because it's no longer a supported format. I inferred this from the specification of the CertificateMappingMethods registry setting.
Summary and Thoughts
It's a shame I wasn't the one who discovered this vulnerability, but I got to have my spit-take moment, so I'm satisfied 😗💦. I'll wrap up with a bit of speculation.
First, why was this vulnerability introduced in the first place?
While a lack of developer awareness was likely a factor, I suspect there was a decision that skipping the NTAuth store check when altSecurityIdentities is set would be advantageous from a performance perspective.
However, it seems to me that if the validation process had been designed to only use the NTAuth store from the beginning, instead of the OS certificate store, this vulnerability wouldn't have been created, and performance wouldn't have been a concern.
Maybe there's a reason, but I can only think it's due to the historical baggage of AD DS development. It's a mystery.
Next, why hasn't this vulnerability gotten much attention?
Bypassing the NTAuth store validation is certainly dangerous, but as the official information states, the likelihood of exploitation is low. This is likely because the conditions are very specific.
An attacker would need to clear a significant prerequisite, like being able to issue an arbitrary client certificate from a CA that is trusted by the Windows OS, either a default one or an internal private CA.
Also, while it's common for AD to support certificate authentication via Active Directory Certificate Services (AD CS), which can expose it to related vulnerabilities, few organizations probably use the altSecurityIdentities attribute unless they are seriously managing a full-fledged PKI and certificate-based authentication. Paradoxically, this might mean that organizations affected by this vulnerability have reasons to require a very high level of security, and for an attacker, they might be valuable targets worth overcoming significant hurdles to attack.
Finally, the altSecurityIdentities attribute isn't the bad guy here.
It was unlucky enough to be the trigger this time, but when used properly, it's a useful mechanism for enhancing security.
Later! 👋