Know Your AD Vulnerability: CVE-2022-26923

By Semperis Research Team August 02, 2022 | Active Directory

On May 10, 2022, a vulnerability within Active Directory (AD) and Active Directory Certificate Services (AD CS) was disclosed and patched. This AD vulnerability can lead to privilege escalation. In default installations of AD CS, a low-privileged user can exploit the vulnerability by requesting an authentication certificate and then using that certificate to impersonate another computer account, resulting in a full domain takeover. What’s this AD vulnerability all about? Read on for a comprehensive guide to CVE-2022-26923.

What leads to this AD vulnerability?

AD was first released in 1999 by Microsoft as a centralized identity management system consisting of a set of processes and services. AD contains several protocols that can be used for authentication and authorization of identities across an enterprise. Most commonly, AD is used to easily manage users, groups, and computers within an enterprise. AD has since become the most popular identity management system, used to manage the identities in the vast majority of corporations.

In Windows Server 2008, Microsoft introduced AD CS, which provided the ability to easily create and manage Public Key Infrastructure (PKI) certificates. These certificates can be used for digital signing, protocol protection and authentication.

When certificates from AD CS are used for authentication within an AD environment (PKINIT), many new attack paths are opened, including both misconfigurations and vulnerabilities. In June 2021, Will Schroeder and Lee Christensen published a whitepaper detailing several misconfigurations that might result in privilege escalation. Some of these misconfigurations were default within AD CS upon installation and can lead to full domain takeover. These misconfigurations are independent of the vulnerability described in this post. 

Privilege escalation with the CVE-2022-26923 AD vulnerability

CVE-2022-26923 is a privilege escalation vulnerability discovered by Oliver Lyak. Exploitation relies on two primary actions:

  1. Changing of a computer account’s dNSHostName to match that of another computer account.
  2. Requesting a certificate for the computer account, using a template that is configured with the SubjectAltRequireDns

The SubjectAltRequireDns flag for certificate templates means that certificates requested using this template have a certificate Subject matching the dNSHostName attribute of the requesting AD account.

Both these actions are possible in a default installation of AD and AD CS.

By requesting a certificate using a computer account that has the same dNSHostName as another computer account, attackers can authenticate as the target computer account and escalate privileges. This vulnerability can be used to target any active computer within AD.

Changing machine account dNSHostName

In a default AD installation, any Authenticated User can add machine accounts. This action is governed by the following settings:

  • The Add workstations to domain user right in the Domain Controller policy, which defines who is granted privileges to add computer accounts to the domain (set to Authenticated Users by default; Figure 1)
"Add workstations to domain" user right
Figure 1
  • The ms-DS-MachineAccountQuota attribute on the naming context (NC) head, which defines the number of computer accounts that low-privileged users are allowed to add (set to 10 by default; Figure 2)
ms-DS-MachineAccountQuota attribute
Figure 2

With these default settings, any low privileged account can easily create up to 10 computer accounts on the domain by using Powermad’s New-MachineAccount cmdlet to add a computer account named LowPrivComputer (Figure 3).

Adding computer accounts
Figure 3

The Discretionary Access Control List (Dacl) for this new computer account shows that the creator account has the Validated write to DNS host name permission (Figure 4).

Validated to write to DNS host name permission
Figure 4

Therefore, the dNSHostName attribute can be modified by the same account that created it, simply by using PowerView’s Set-DomainObject cmdlet (Figure 5).

Modified dNSHostName
Figure 5

Certificate template with SubjectAltRequireDns flag

In a default AD CS installation, several certificate templates have the SubjectAltRequireDns flag set. For example, the Machine template is used by default to enroll computer accounts for certificate authentication. PowerView’s Get-DomainCertificateTemplate cmdlet is used to view the Machine template’s msPKI-Certificate-Name-Flag attribute (Figure 6).

Certificate template
Figure 6

Using the previously created machine account, it is possible to request a certificate using this template for the LowPrivComputer account with the modified dnshostname (somethingelse.f105-d01.lab). For this, the Python tool Certipy is used (Figure 7).

Request a certificate
Figure 7

Abuses of the CVE-2022-26923 AD vulnerability

As already mentioned, this method can be used to escalate privileges within an AD domain. One common attack path is to target a domain controller (DC). After creating the computer account (LowPrivComputer), attackers first change the account’s dNSHostName attribute to the same as the DC (F105-D02-DC01.f105-d01.lab), as shown in Figure 8.

Targeting a DC
Figure 8

For this attack path, the contents of the servicePrincipalName (SPN) needs to be cleared. When the dNSHostName attribute is updated, any SPN entries are also updated to match the new name. This conflicts with the SPN entries for the genuine account (F105-D01-DC01), and the change fails.

After the dNSHostName change, a certificate for this new name can be requested (Figure 9).

Requested certificate for new name
Figure 9

After the certificate is retrieved, the dNSHostName needs to be changed again (Figure 10) so that when the certificate is used and the DC looks up the client name, there is only one match (the genuine DC account).

Changing dNSHostName again
Figure 10

Now, it is possible to authenticate as the DC computer account. Rubeus provides a /getcredentials switch to the asktgt command, which uses a user-to-user (U2U) request. When a certificate is provided for authentication, the requesting accounts NT hash can be retrieved because of the NTLM_SUPPLEMENTAL_CREDENTIAL PAC credential data PAC_INFO_BUFFER (Figure 11).

/getcredentials switch to the asktgt command
Figure 11

This NT hash can be used to further authenticate as the DC (using pass-the-hash or overpass-the-hash) or Silver Tickets can be forged.

Attack path variations

Aside from the attack path shown in the previous examples, several slight variations can be used to exploit this AD vulnerability.

First, an attacker with some control over an existing computer object does not require the ability to create a computer account. Figure 12 shows that the low-privileged user account has the GenericWrite permission over the DatabaseServer computer object.

GenericWrite permission
Figure 12

With this privilege, an attacker can clear the SPNs and change the dNSHostName attribute to match that of another computer account (Figure 13).

Changing dNSHostName to match another account
Figure 13

Two things are worth noting here:

  • A non-DC system is being targeted. This vulnerability can be used to target any domain-joined system, not only DCs.
  • This part of the attack can be performed on fully up-to-date DCs. When the account making the change has specific GenericAll or GenericWrite permissions, the dNSHostName can be modified to match that belonging to another computer account. (This is not possible when the Validated write to DNS host name permission is granted to the creator of a computer account.)

With the dNSHostName changed, a certificate can be requested using the target DNS host name (Figure 14).

Certificate request
Figure 14

With the dNSHostName changed back, as in the previous attack path, the attacker can now use the acquired certificate to authenticate as the target computer account.

Another difference between the previous attack path and this one: The attacker does not need to use the certificate to authenticate to Kerberos and request a ticket granting ticket (TGT) for the target account. The attacker can use the certificate to authenticate directly to some services. The following example uses the certificate to connect directly to LDAP and configure resource-based constrained delegation (RBCD) on the target computer object (Figure 15).

Connecting to LDAP
Figure 15

Note that configuring RBCD is just one example of what an attacker can do by using the certificate to authenticate directly against services. WinRM, RDP, and IIS all support client authentication using certificates, so there are many more possibilities. Other actions, such as configuring shadow credentials, can be taken over LDAP, depending on the environment and permissions of the compromised computer account.

To finish the attack path, the attacker can use the Service-for-User (S4U) Kerberos extension to obtain a service ticket to the target system as an administrative user (providing the administrative user has not been protected against delegation), as shown in Figure 16 and Figure 17.

Finishing the attack path (1)
Figure 16
Finishing the attack path (2)
Figure 17

The attacker can use the resulting service ticket to access the service on the target system as the impersonated user. A good demonstration is to use WinRM/PowerShell Remoting to output the value of “whoami”, which requires a service ticket for the HTTP service on the target system (Figure 18).

Using the service ticket
Figure 18

ServicePrincipalNames

For both these demonstrated attack paths, the SPNs needed to be cleared before changing the dNSHostName. This might seem like a hard requirement of exploitation of the vulnerability, but it isn’t. Using the MS-SAMR protocol to create a computer account using the SamrCreateUser2InDomain method, an attacker can create a computer account without any SPNs, simply by using impacket’s addcomputer.py example script to create a computer account called NoSPNComputer (Figure 19).

Using MS-SAMR
Figure 19

The resulting computer account has no SPNs and does not require them to be cleared (see Figure 20).

No SPNs
Figure 20

Mitigating factors

Restricting the ability of low-privileged users to create machine accounts, either by setting the ms-DS-MachineAccountQuota attribute on the NC head to 0 or by changing the Add workstations to domain user right in the Domain Controller policy to a specific group rather than Authenticated Users, reduces the viable attack paths for this vulnerability. Other actions to reduce the exploitation potential:

  • Change any certificate templates from using “DNS name” to something like “User principal name (UPN)” (Figure 21).
Change template name
Figure 21
  • Configure certificate templates to require manager approval for enrollment (Figure 22).
Configure approval for enrollment
Figure 22

DSP detection of this AD vulnerability

As this exploit comprises only two mandatory actions, Semperis Directory Services Protector (DSP) has two opportunities to detect it:

  • When the dNSHostName change happens
  • When the certificate is requested

DSP already collects the AD change data, so the obvious choice is to detect an attempt to exploit this vulnerability was when the dNSHostName is changed. The DSP indicator does this first by monitoring for a change to a computer account’s dNSHostName attribute.

When such a change is detected, DSP makes an LDAP query for any computer accounts with that dNSHostName value, excluding the object distinguished name (DN) of the account that triggered the LDAP query. DSP flags each result as an indicator of compromise (IoC). This flag should catch any attempt to exploit this vulnerability, regardless of whether the full attack was successful. As shown in Figure 23, the IoC returns information that includes:

  • The account that made the change
  • The DNs of both computer accounts involved
  • The original dNSHostName of the account that had its attribute changed
  • The dNSHostName attribute of the account being targeted
DSP flags
Figure 23

Other detections of CVE-2022-26923

Several relevant Windows events can also be used to help identify attempts to exploit this vulnerability.

Clearing SPNs

When an attack path requires clearing of the SPNs of the computer account used in the attack, a 5136 event for each of the configured SPNs is created with the operation type Value Deleted (Figure 24).

5136 events
Figure 24

Changing dNSHostName

When the dNSHostName attribute is changed, a 4742 event is created (Figure 25).

4742 event
Figure 25

The Changed Attributes section of this event shows the new DNS Host Name value (Figure 26).

New DNS Host Name value
Figure 26

Along with the 4742 event, two 5136 events are created. The first shows the original dNSHostName value and is of operation type Value Deleted (Figure 27).

Value Deleted
Figure 27

The second shows the new dNSHostName value and is of operation type Value Added (Figure 28).

Value Added
Figure 28

Computer creation without SPNs

As mentioned previously, attackers can create computer accounts without any initial SPNs by using MS-SAMR. When they do, an 4741 event is created (Figure 29).

4741 event
Figure 29

Within the Attributes section of this event, the Service Principal Names are empty, as shown in Figure 30.

Empty Service Principals Names
Figure 30

Request certificate

When a certificate is requested, a 4887 event is created on the certificate authority (CA). This event shows the name of the requesting account (Requester). The value of the dNSHostName attribute is shown as the Subject (Figure 31).

Requesting account
Figure 31

AD vulnerability remediation

A patch for this vulnerability was released as part of the May 2022 security updates. This patch introduced a few changes:

  • Accounts with the Validated write to DNS host name permission are no longer able to change the dNSHostName attribute to match that of another account on patched DCs. Attempts to do so result in a constraint violation (Figure 32).
Constraint violation
Figure 32

Note: As mentioned previously, even after this patch, attackers can change a computer account’s dNSHostName attribute to match that of another computer account, even thought that action now requires higher permissions such as GenericAll/GenericWrite.

  • Certificates requested from patched CAs contain the new szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2.1) OID (Figure 33).
New OID
Figure 33

This field contains an ASCII string (in hex) of the SID of the account that requested the certificate. When a certificate used to take advantage of this vulnerability is used to authenticate against a patched DC, a CERTIFICATE_MISMATCH error is returned (Figure 34).

Returned error
Figure 34

Note: If this certificate is used to authenticate against an unpatched DC, authentication will be successful and the vulnerability exploitable (Figure 35). Therefore, it is very important to update all DCs and CAs are updated with the relevant patch.

Using an unpatched certificate
Figure 35

Learn more

To learn more about this AD vulnerability and how to protect your organization, see the following references and resources.

Resources

Learn more about Semperis Directory Services Protector (DSP)

Learn more about Purple Knight Active Directory security assessment tool

References

About the author
Semperis Research Team
Semperis Research Team
The Semperis Research Team continuously studies the ways cyber criminals are plotting to compromise organizations' information systems—particularly by exploiting vulnerabilities in Active Directory—now and in the future. Their work provides guidance for the security community in protecting against AD-related attacks and informs the development of products that help organizations increase their cyber resilience. Linkedin
Unlock cyber resilience. Get a demo