On May 10th 2022, Microsoft disclosed a severe vulnerability affecting Active Directory environments in all versions of Windows Server. The vulnerability was found by the security researcher Oliver lyak and has been assigned as CVE-2022-26923, which was fixed by Microsoft in the updates described on that page (different KB articles for different operating systems).
The vulnerability can be exploited by attackers impersonating another machine account and issuing a certificate on behalf of that account in AD environments where Active Directory Certificate Services (AD CS) is also installed, resulting in computer account take-over and even domain controller take-over, which effectively grants an attacker a clear path for full domain credentials compromise.
This vulnerability consists of a logical flaw and affects all non-patched Windows versions from the date of this publication. In this blog, we will give the required background for understanding the vulnerability and the detection logic that Microsoft Defender for Identity uses to alert security teams when a potential attacker may be attempting to use this exploitation. Let's start by explaining the vulnerability.
PKINIT Kerberos
As the vulnerability exploitation depends on AD CS, it is essential to understand how the Kerberos authentication protocol works with digital certificates and how these certificates are enrolled for a specific user or computer.
The Kerberos authentication protocol is a major protocol used for domain authentication. Kerberos takes place when an entity (user or computer in this instance) tries to access network resources that require proof of the user’s identity, usually in the form of proving the knowledge of a shared secret – a password. But passwords are just one of many forms of proving the identity of a certain entity as other methods such as biometrics and smartcards are widely used today. For example, when dealing with smartcards, the user connects the smartcard device, enters a PIN code and that allows for the authentication process to complete. So, how does Kerberos differ depending on the identity proof method?
Behind the scenes, when a smartcard user (or biometrics user) invokes Kerberos authentication, the proof of identity that is sent to the domain controller (DC) is based on a digital certificate that was enrolled to the originating user. In order to adapt Kerberos (symmetric encryption-based authentication protocol) to support certificate-based authentication (which relies on asymmetric encryption) some adjustments have to be made. Those adjustments are referred to as “Public Key Cryptography Initial Authentication in Kerberos”, or in short – the PKINIT extension for Kerberos. This extension enables the smartcard user to send a different Kerberos AS_Req packet, or to be more precise, a different pre-authentication value. In a “regular” Kerberos authentication request, the data that is meant to prove the user identity (referred to as pre-authentication data) is a timestamp encrypted with the user’s hashed password. In PKINIT Kerberos, the pre-authentication data is a digital certificate accompanied with an authenticator (a digital signature) that proves the certificate ownership by the user.
Let’s observe how the two differ over the wire in Kerberos AS_Req packets.
Pre-authentication of pA-ENC-TIMESTAMP type in a standard Kerberos authentication:
Figure 1 - Encrypted timestamp for pre-auth
Pre-authentication of pA-PK-AS-REQ type in PKINIT Kerberos authentication:
Figure 2 - Certificate and digital signature pre-auth
The user certificate that is used in the pre-authentication data holds a couple of fields that are crucial for the authentication and authorization process to occur. Firstly, the certificate is paired with a private key whose corresponding public key is kept in the certificate. Secondly, the certificate subject indicates that the certificate was issued to User1, and they can use it to authenticate.
Figure 3 - Certificate details highlighting the subject and if it's paired to a private key
When the DC receives an AS_Req of the pA-PK-AS-REQ type, the following checks are performed:
- The DC verifies that the certificate was signed by a Certificate Authority (CA) defined by the NTAuthCertificates list (a trusted CA).
- The DC validates the certificate in terms of expiry date, path, revocation status, etc.
- The DC verifies the authenticator that is sent. The authenticator should be a digital signature with the original private key and this verification is done using the public key from the certificate.
If the checks are successful and the certificate is indeed valid, the DC will look up the object from its NTDS.DIT database using the subject name of the certificate. The certificate’s subject to entity mapping is done quite differently for a user account compared to a computer account:
- User certificate – the mapping is done by the UPN attribute. A lookup is done with subject name of the certificate, looking for a user with this value in its UPN attribute.
- Computer certificate – the mapping is done by the SamAccountName attribute. The DC parses the subject name, verifies the domain name, and performs a lookup for the computer account.
After the entity mentioned in the certificate is found, the DC will generate a ticket granting ticket (TGT) for it and send it back to the client. After the TGT is issued, the subsequent TGS_Reqs work the same as in regular Kerberos.
Certificate Enrollment
As stated above, the user certificate is issued by a trusted CA Server, commonly implemented in AD environments as a Windows server with AD CS role installed.
CA Server – Certificate Authority, a server that functions as a “Source of truth” for issuing digital certificates for all kinds of usage. All the entities on the organization in which the CA Server is deployed trust the CA Server, so the certificates it issues may be used as authenticity proof, optionally creating a trust model across other CA for other networks.
Common usage: HTTPS Certificates, Authentication Certificates (both users and computers)
Every certificate issued by the CA is based upon a certificate template. A certificate template is a set of certificate settings and policies (expiry date, cryptographic algorithms, certificate usage, etc), that the issued certificate will be generated with. To issue a certificate, the requesting user must have enrollment permissions to the template it’s requesting, and the request is done by sending a certificate signing request (CSR) to AD CS.
If the CSR is indeed, the AD CS should issue a certificate based on the requested template. The subject of the certificate is determined in one of two ways, depending on the template settings.
Figure 4 - Permissions on the "Computer" template and the subject name creation method
If the template settings indicate that the subject name is built upon AD information, then the AD CS server will send an LDAP query to the DC to get full details of the subject who the certificate is created for.
This query can be observed, and we can see which attributes the CA is asking for witnessing what’s populating the subject field in the certificate.
Figure 5 - ADCS queries for issued user details
After this query is answered, the certificate is created according to the settings described in the certificate template. The field which associates the certificate with the owner is the public key that the client submitted in the CSR. Afterward, the client will use the issued certificate and the private key to initiate PKINIT Kerberos Request, as described above.
The vulnerability
From the description above, certificates are an alternative way of carrying Kerberos authentication and they can be utilized by users as well as by computers. There are some differences between a user certificate and a computer certificate, as they originate from two different templates. One main difference is the way that the subject name is constructed, and we will focus on how the subject name is created for computer certificates, as the vulnerability lies there.
As you will recall, when an entity submits a certificate signing request, the CA server should assemble the subject name from Active Directory data, which is done with an LDAP query. Earlier, we saw the generic query that is sent regarding the entity the certificate is issued to, but the response is different for computers than it is for user.
Here we can observe the DC’s LDAP answer, in which it indicated the DnsHostName attribute of the computer that requested to own the certificate. Using the DnsHostName attribute as the subject of the certificate, the CA creates the certificate and on later usage of it for authentication purposes, the subject name will be used by the DC to perform the certificate-to-entity mapping – generating the TGT accordingly.
Figure 6 - The ADCS gets its answer
This means that if an attacker is able to control the value that is written to the DnsHostName attribute of any computer in Active Directory, they can control the subject name of a certificate issued by the CA, potentially resulting in a certificate that is able to impersonate other computer account identities in the domain.
The security flaw that has been presented in CVE-2022-26923 by Oliver lyak showed that it is possible to control the value of the DnsHostName attribute, under some circumstances.
In an organization where the ms-DS-MachineAccountQuota attribute is different than 0 (default value is 10), an attacker can create a new computer account. Even though the attacker has just created the new computer account, they can’t edit the DnsHostName in an arbitrary manner, as the permission for this attribute is “Validated write to DNS host name”. This means that any modification attempt is checked against the ServicePrincipalName attribute, preventing any mismatch between these two attributes. That obstacle can be bypassed by deleting the SPNs that are registered with an FQDN, or alternatively, by creating the computer account with no SPNs registered – possible with SAMR protocol.
Figure 7 - Before and after the SPN change
After omitting the SPNs registered with FQDN, it is possible to change the value of the DnsHostName attribute. The computer account that an attacker is likely to target is one of the Domain Controllers - An attacker will edit the DnsHostName attribute to one of a DCs, and the validation will pass successfully.
Figure 8 - After DnsHostName edit
The next step is issuing a certificate from AD CS. We emphasized earlier on the importance of the DnsHostName attribute, and how it affects the PKINIT authentication process. Let’s look at what the certificate Client1$ issues looks like:
Figure 9 - Certificate Client1$ issued
That certificate can be used for PKINIT Kerberos and in the certificate-to-entity mapping the DC will search for an entity with the samAccountName of DC1$, resulting in finding the DC and creating TGT to it. With the TGT of a DC, the attacker can compromise all Active Directory, (which can be detected by Microsoft Defender for Identity separately) or alternatively gain local admin privileges on the Domain Controller.
Detection in Microsoft Defender for Identity
Microsoft is applying a hotfix to Microsoft Defender for Identity version 2.179 so this detection is available immediately. This hotfix (2.179.15243) includes a new security alert: Suspicious modification of a DnsHostName attribute (CVE-2022-26923 exploitation).
The detection identifies a computer with an anomalous DnsHostName, which is the first stage in an attempt to impersonate a domain controller.
The security alert Microsoft Defender for Identity raises contains further details about the exploitation attempt, indicating the actor and further victim details for speedy resolution purposes.
Figure 10 - Alert in Microsoft Defender for Identity
How to best protect against this vulnerability
As stated above, this vulnerability affects all organizations using AD CS, and because of that, it is of high severity. Here are the main steps you need to take to make sure you are protected from this recently identified threat:
- Apply the recent patches to all Domain Controllers servers in your organization. For further details on how to apply the patch refer to this Microsoft advisory.
- Microsoft Defender for Identity customers have protection from this vulnerability through detection and alerting for the attack in its early phases, as part of our aspiration to respond rapidly to complex threats in the identity realm.
- Set the ms-DS-MachineAccountQuota attribute to 0 if possible, making the attack more complex to exploit for an attacker.
- Adjust certificate template permissions and approval according to your organization's needs.
- If an exploitation attempt succeeds, Microsoft Defender for Identity provides security teams with detailed alerts, making it easier to investigate and provides all required information for a rapid response.
Additional resources
- For further information about the vulnerability and its exploitation refer to the blogpost that the author of this vulnerability has published.
- Learn more about Microsoft Defender for Identity, and begin a trial for Microsoft Defender for Identity here.
- Learn about Microsoft Defender for Identity's new feature - Response Actions.
Posted at https://sl.advdat.com/39TtYDzhttps://sl.advdat.com/39TtYDz
