CVE-2022-26923: Know Your AD Vulnerability

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. 

Related reading

• Active Directory Security: Top Risks & Best Practices

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)

• 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)

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).

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).

Therefore, the dNSHostName attribute can be modified by the same account that created it, simply by using PowerView’s Set-DomainObject cmdlet (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).

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).

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.

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).

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).

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).

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.

With this privilege, an attacker can clear the SPNs and change the dNSHostName attribute to match that of another computer 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).

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).

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.

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).

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).

The resulting computer account has no SPNs and does not require them to be cleared (see 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).

• Configure certificate templates to require manager 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

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).

Changing dNSHostName

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

The Changed Attributes section of this event shows the 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).

The second shows the new dNSHostName value and is of operation type 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).

Within the Attributes section of this event, the Service Principal Names are empty, as shown in 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).

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).

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).

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).

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.

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

• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923
• https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
• https://offsec.almond.consulting/authenticating-with-certificates-when-pkinit-is-not-supported.html
• https://www.netspi.com/blog/technical/network-penetration-testing/machineaccountquota-is-useful-sometimes/
• https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html