CVE-2022-26923 (Certifried) explained

What is CVE-2022-26923?

CVE-2022-26923, commonly referred to as Certifried, is an Active Directory domain privilege escalation vulnerability that was patched as part of Microsoft’s May 2022 security updates. 

The vulnerability, first reported by Oliver Lyak, abuses Active Directory Certificate Services (AD CS) to request machine certificates with arbitrary attacker-controlled DNS host names.

This allows any computer account in the domain to impersonate the Domain Controller, resulting in a complete domain takeover. 

Lyak’s work was inspired by Will Schroeder and Lee Christensen’s Certified Pre-Owned whitepaper (and the accompanying blog post with the same title), and by other Active Directory attacks, such as Charlie Clark’s weaponization of CVE-2021-42287 and CVE-2021-42278. 

What is AD CS?

Active Directory Certificate Services (AD CS) is a Windows Server role that provides services for issuing and managing public key infrastructure (PKI) certificates. These can then be used to authenticate users, devices, or services and for secure communication.

The main AD CS feature is the Certification Authority (CA) service, which is responsible for issuing and verifying certificates following a template-based approach. 

A certificate template is an Active Directory object that, as the name may suggest, defines enrollment policies and certificate parameters, such as how long a certificate will be valid and what the certificate can be used for. 

Default certificate templates (such as User and Machine, used to identify domain users and domain computers respectively) are available, but custom templates can be defined as well.

Clients can request certificates from the CA server by sending certificate signing request (CSR) messages.CSR messages contain the public key of the client, the subject name of the requested certificate, and additional information including a template name. 

In response, the CA server then verifies whether the client is allowed to enroll in the given certificate template. If enrollment is permitted, the server proceeds to generate a new certificate based on the template settings, signs it with its private key, and returns it to the requester. 

The enrollment process is described in more detail in the aforementioned whitepaper and in Microsoft documentation.)

User authentication vs. Machine authentication

The PKINIT Kerberos extension enables the use of public key cryptography in the initial authentication exchange of the Kerberos protocol, allowing AD CS-issued certificates to be used for authentication. 

Both user and computer account certificates are accepted by PKINIT, but the way a User and a Machine certificate identify their target account differs:

• Certificates enrolled from the User template contain the User Principal Name (UPN) of the user account, which uniquely identifies the user (the same UPN cannot be shared by multiple users).

  The UPN value of the requesting user (stored in the LDAP userPrincipalName attribute) is required by User certificates, as indicated by the CT_FLAG_SUBJECT_ALT_REQUIRE_UPN flag in the msPKI-Certificate-Name-Flag attribute.
  (This flag instructs the CA to add the value of the UPN attribute from the requestor's user object in Active Directory to the Subject Alternative Name extension of the issued certificate.)

• Since machine accounts are not associated with a UPN, the DNS host name attribute (dNSHostName) is used instead on Machine certificates, as indicated by the CT_FLAG_SUBJECT_ALT_REQUIRE_DNS flag.
  
  Contrary to User Principal Names, DNS host names are not unique. Mapping based on the DNS host name field during PKINIT works as follows:

1. The principal name of the target account (e.g. [email protected]) is supplied, together with a certificate containing a matching DNS host name [email protected] (without the $ sign at the end).

2. The KDC looks up the machine account from the given principal name, obtaining the corresponding sAMAccountName (computer01$).

3. Having obtained the target sAMAccountName, the KDC then splits the DNS host name from the certificate into two parts: computer name (computer01) and realm (htb.local).

4. If the computer name part (computer01) matches the sAMAccountName (computer01$) and the realm part (htb.local) matches the DNS domain name of the realm, mapping is successful. Otherwise, the KDC should return the KDC_ERR_CLIENT_NAME_MISMATCH error.

Vulnerability description

By default, non-admin domain users can join up to ten computers to an existing domain (this is governed by the ms-DS-MachineAccountQuota attribute).

By default, the creator of a machine account has the Validated write to DNS host name permission on the account, described as “Validated write permission to enable setting of a DNS host name attribute that is compliant with the computer name and domain name”.

This means that the DNS host name could potentially be set to any valid computer name in the domain, including the same host name as the Domain Controller (remember, as seen above, that no uniqueness constraints are imposed on the dNSHostName attribute).

What actually prevents this from happening, in the default case, is the uniqueness constraint imposed on the servicePrincipalName attribute, which is automatically updated any time the DNS host name is modified to reflect the name change. 

Attempting to set the DNS host name of a newly added machine to the same name as an existing machine in the domain will therefore result in an error because of an indirect violation of the SPN uniqueness constraint.

However, as Lyak discovered, only the SPN entries that contain the dNSHostName value are subject to this restriction, and such entries can be simply removed from the SPN before attempting a dNSHostName change. 

This allows users to set the dNSHostName of a self-joined machine to match the value of the DNS host name of the Domain Controller. Once this is done, a new Machine certificate can be requested, which will embed the DNS host name of the DC. 

When the certificate is used for authentication, PKINIT will map the request to the Domain Controller account (following the process described above), effectively resulting in authentication as the DC machine account. 

Having obtained DC privileges, an attacker can then (for example) perform a DCSync attack to dump user hashes and obtain access as the Domain Administrator.

Using Certipy to exploit CVE-2022-26923

As shown in Lyak’s article, the Certipy tool (from the same author) allows you to automate the process of creating a new computer account with a given name and setting the dNSHostName to a different name (e.g. the DC host name). 

This can be accomplished by running the account create command with the following syntax:

certipy account create -u username@domain -p password -user <Account Name> -dns <dNSHostName> [-dc-ip <DC IP>]

After the machine account has been created, a new certificate can be requested by running the req command and specifying the -template Machine option:

certipy req -u username@domain -p password -ca <CA Name> -template Machine

Authentication is performed with the auth command, which receives the certificate file name (e.g. dc.pfx) as the -pfx parameter:

certipy auth -pfx dc.pfx -dc-ip <DC IP>

The NT Hash of the dc$ computer object is returned. 

Finally, a DCSync attack can be performed by running the secretsdump Impacket script:

secretsdump 'domain/DC$dc.domain' -hashes :<NT Hash>

In addition to what is shown above, Certipy implements all the domain escalation techniques from Schroeder and Christensen’s whitepaper, and much more.

Mitigating CVE-2022-26923

The May 2022 Security Update for Windows systems includes a patch for CVE-2022-26923. Two major changes were implemented to mitigate the vulnerability:

1. A new Object ID, named szOID_NTDS_CA_SECURITY_EX (OID = 1.3.6.1.4.1.311.25.2), which contains the objectSid value of the Active Directory object used to construct the certificate subject, is now added to certificates generated by patched Certification Authorities.
   
   Attempting to authenticate with a certificate containing a forged DNS host name will now return a KRB_AP_ERR_CERTIFICATE_MISMATCH when object SIDs don’t match.
   
   Additionally, a new enrollment-attribute flag CT_FLAG_NO_SECURITY_EXTENSION was added to the msPKI-Enrollment-Flag table, which instructs the CA to not include the szOID_NTDS_CA_SECURITY_EX extension in generated certificates. Certificate templates containing this flag may still be vulnerable to the attack.

2. The “Validated write to DNS host name” permission no longer allows users to change the dNSHostName attribute to a name that doesn’t match the sAMAccountName of the machine account.

This effectively prevents the basic attack described above, where a new machine is added to the domain by an unprivileged user, which automatically inherits “Validated write to DNS host name” rights to the account. However, a user with higher privileges (like GenericWrite) on any machine account would still be able to add a custom dNSHostName value.

Stay ahead of threats with Hack The Box

In response to this vulnerability, we’ve released a Machine called Certifried for HTB Enterprise users. This gives teams the chance to train on real-world, threat-landscape-connected scenarios in a safe and controlled environment.  

Play the machine

Hack The Box provides a wide range of scenarios to keep your team’s skills sharp and up-to-date. Organizations like Toyota, NVISO, and RS2 are already using the platform to stay ahead of threats with hands-on skills and a platform for acquiring, retaining, and developing top cyber talent. Talk to our team to learn more. 

Author bio: Marshall Livingston (Tr33), Head of Sales Engineering, Hack The Box Marshall has nearly ten years of experience in various facets of cyber security that are supported by multiple industry-accredited certifications. His areas of interest extend to cyber security training, network security, and penetration testing. Prior to his association with Hack The Box, he conducted over 150 penetration tests for a diverse clientele while managing his own business based in Illinois and Colorado.  Marshall's journey with HTB began in 2017 as a community member since its inception. In 2021, he came on board as the first sales engineer and has since then been promoted to direct Head of Sales Engineering. Feel free to connect with him on LinkedIn.