Move on Up: An Analysis of the Privilege Escalation Vulnerability CVE-2022-26923

This article provides an analysis of CVE-2022-26923, a vulnerability at the intersection of Active Directory (AD) and Active Directory Certificate Services (AD CS) that was privately discovered and reported by Oliver Lyk through the Zero Day Initiative. was done and patched on May 10th. 2022, which allowed a less-privileged attacker to elevate his privileges through impersonating another computer account under the guise of the requested authentication certificate.
As the go-to directory service from Microsoft for Windows domain networks, Active Directory (AD), or more formally Active Directory Domain Services (AD DS), is a prime target for attackers who want to access resources on the network. want to recive.

In essence, AD serves as both a distributed data store and an access control mechanism for the organizations that use it, including not only the users and groups within its scope but also others such as servers, printers and computers within the network. Contains objects – that is, what network resources access needs to be controlled. Offering fairly simple hierarchical organization, AD makes it easy for domain administrators (often a centralized identity and access management team within the organization) to control access to resources; It enables authorized network users to navigate and query for information about other users and network resources in their organization.


Let’s start with an assumption: You’re a user with normal, non-administrative permissions on the network – or maybe you’re not, but you’ve acquired the identity of someone who is.

Conan is wearing a disguise

How you can use Active Directory, as described above, (probably .) ahead) elevate your privileges and access a resource on a network that you do not currently have access to?

First, privilege escalation would be a bit difficult without visibility of whose privilege level should be targeted. Of course, as previously mentioned, AD provides the ability for an authorized domain user to query data for information such as usernames, email addresses, group memberships, etc., which is one way that visibility can be achieved. Is . However, we’ve seen that with a tool like Bloodhound, the same domain user (or someone impersonating them on the network) can automatically get a graphical visualization (built with a great graph data platform called Neo4j) ) shows not only who the domain administrators are within AD, but also what the shortest path to privilege escalation is for each of those administrators – all essentially at the click of a button.

Basically, any domain user can get this information about their domain by logging into AD, running SharpHound to collect data in JSON format, and then piping that collected data into the Neo4j-based Bloodhound visualizer . From that point on, it’s a matter of following the yellow brick road – that is, mapping the route to the target with the desired privileges by following the graph edges that reveal useful vulnerabilities. Graph theory, permissions, membership, oh my.

Wizard of Oz;  follow the Yellow Brick road

As an example, you may want to access a domain administrator’s account, and you see in the Bloodhound graph that a non-admin has permissions to force change the passwords of one or all domain administrators within AD , so you identify that non-administrator as the next target for impersonation.

Now, let’s say you have identified a target for impersonation-based privilege escalation. Assuming that the target is a computer or server account (not a user account), CVE-2022–26923 was a vulnerability that offered a way to carry out that impersonation.

a pause for a while

Introduced in Windows Server® 2008, Active Directory Certificate Services (AD CS) is another AD server role that leverages the public key infrastructure (PKI) to provide domain users with the ability to generate digital certificates. Such digital certificates can be used for general encryption to protect data privacy, to generate digital signatures to protect message integrity during transmission, or even for authentication against AD. , which is the focal use case for the purpose of this analysis because successful privilege escalation is all about false positives when authenticating via impersonation.
As with the public key infrastructure upon which AD CS is built, one of the broad ideas is that as with any public-private key pair, the private key is kept truly private by the owner and thus to that owner. Can be used to identify and authenticate (which has additional non-repudiation implications). If that owner signs (encrypts) something with his private key, the only way to decrypt it is with the corresponding public key; More importantly, any message decrypted with the public key can only arrive with the private key belonging to the owner. This principle underlying PKI opens the door to digital certificate-based authentication.

By associating or binding digital certificates with accounts on the network in the AD (whether computer accounts, user accounts, or device accounts), AD CS allows those accounts to authenticate against the AD using their respective digital certificates. Certificate-based authentication is an interesting process in itself that relies on password entry in addition to digital signature verification, but this paper will avoid diving down that rabbit hole. Note that this process of binding a digital certificate to an identity that is being used to authenticate them must be done in such a way that other identities cannot create that binding. This was the problem behind CVE-2022–26923 – AD CS allowed digital certificates to be bound to identities via an attribute (dNSHostName), which could be arbitrarily reused for other identities.

Using CVE-2022-26923 to elevate privileges

As documented by the Semperis research team in August of 2022, there were ultimately two main steps that needed to be completed to exploit the CVE-2022-26923 privilege escalation vulnerability. First, the attacker must change the dNSHostName of his computer account to match the dNSHostName value of the target computer or server account (for example, that of a domain controller computer account). Then, the attacker needs to obtain a digital certificate associated with his or her own falsely identified computer account by requesting a template configured with the SubjectAltRequireDns flag. This flag essentially sets the subject of the digital certificate to the dNSHostName value of the requesting computer account (without any form of verification), where the subject ultimately identifies the computer account tied to the public key. Note that for the first step, it was actually a prerequisite for the attacker to create his computer account as the logged in user in AD (a feature enabled by default in AD), since the dNSHostName attribute can only be modified on computer accounts created by the editor.
The presence of this vulnerability meant that an attacker with access to AD could pick and choose active AD computer accounts and use a default, built-in component of AD to arbitrarily target any desired target through false digital certificate authentication. can be replicated.


easiest, most sledgehammery (look there, I made up a term) The fix for this problem would probably be to not run AD CS within a windows domain network, as AD CS is the root of the CVE-2022-26923 rot. This would prevent digital certificate-based authentication altogether, but of course flipping such a pervasive switch has equally broad implications at an enterprise scale, which could include, for example, on machines. Interruption of service for running services that use certificate-based authentication. purpose.

boy flipping a breaker

Fortunately, Microsoft made an announcement very quickly in response to a vulnerability disclosure about a new change in the way Windows domain controllers handle certificate-based authentication. The announcement included explicit actions that were required to protect the domain environment, namely the application of the May 10, 2022 update that moved AD devices into compatibility mode primarily designed to generate audits prior to the recommended switch to full enforcement mode. which, in essence, will begin to block certain authentication attempts that do not meet the updated digital certificate criteria.
Those criteria focused on the idea of ​​certificate mapping, or the previously mentioned binding, where a mapping between a digital certificate and an account is considered weak or insecure if it relies on an identifier that can be reused by other accounts. can be done (ie, the dNSHostName attribute). Weakly mapped certificates to identities will consequently generate audit events in compatibility mode for checking and fixing, and will completely fail to authenticate those identities when full enforcement mode of updates is enabled.


In short, CVE-2022-26923 was a critical vulnerability within the Active Directory Certificate Services server role that allowed attackers to take advantage of weak bindings between identities and their digital certificates, so that one could access the public-key infrastructure by simply requesting can completely bypass security (and obtain) a digital certificate that identifies them as their desired target in AD. Upon its discovery and disclosure on May 10, 2022, this was quickly addressed by an update to the AD CS Server role that required strong, unforgiving The bond between the digital certificate and the AD identity.

Leave a Comment