by Bhabesh Raj Rai, Security Research
In this month’s patch Tuesday, Microsoft fixed a high severity privilege escalation
vulnerability (CVE-2022-26923) in AD domain services having a CVSS score of 8.8 which is close to critical. This vulnerability allows a lowprivilege authenticated user to acquire a certificate of privileged accounts such as domain controllers from AD Certificate Services, enabling elevation of privilege.
A day after patch Tuesday, Oliver Lyak—the researcher who discovered the vulnerability—released technical details of the vulnerability in his blog. He has also updated the certipy tool to facilitate easy exploitation of this vulnerability.
To exploit this flaw, there should be an Active Directory Certificate Services (AD CS) server present in the domain. AD CS is Microsoft’s answer for public key infrastructure (PKI). Domain users can request a certificate from the AD CS server based on a predefined certificate template. That certificate can be used for various purposes most importantly client authentication. That means users can request Kerberos TGT using the certificate as the authentication medium.
AD CS has separate certificate templates for users and computers and both can be used for client authentication. In the case of user authentication via certificate, the domain controller tries to map the UPN from the certificate to a user whereas, in the case of computer authentication via certificate, the domain controller tries to map dNSHostName instead, since computer accounts do not have a UPN. The creator of the computer account has the rights to change the dNSHostName property value. Also, unlike UPN, dNSHostName need not to be unique in a domain. But when we change the dNSHostName value, the servicePrincipalName value is also updated to reflect the new dNSHostName value. So, if we update the dNSHostName property of a computer account to mirror a domain controller, the domain controller tries to update the servicePrincipalName, which would then conflict with the domain controller’s own servicePrincipalName thus giving us an indirect constraint violation.
However, the creator of the computer account also has permission to change the servicePrincipalName. The new values must be compliant with the dNSHostName. We can beat this constraint check if we just delete the servicePrincipalName values that contain the dNSHostName. Finally, the domain controller will allow us to update the dNSHostName of the newly created computer account to one of the domain controllers. The domain controller has no need to update the servicePrincipalName, since we just deleted the values that contained the dNSHostName value.
Now, we can request a certificate for the newly created computer account to the AD CS server using the Machine template, and the domain controller should embed the dNSHostName property as identification. We can then authenticate using that certificate to the domain controller to obtain the hash of the domain controller machine account. Using that hash either we can directly use DCSync attack to dump all hashes from the domain controller or obtain the Kerberos TGT of the domain controller.
The final part of this attack chain looks very similar to the Petitpotam relay attack where adversaries relay the obtained hash of an entity to an AD CS server and obtain that entity’s certificate. Let’s see how we can detect exploitation of this privilege escalation vulnerability in Logpoint.
Log sources needed
- Windows AD
- Windows AD CS
Administrators should ensure they have enabled the following settings because they are disabled by default.
- Certificate Services audit subcategory
- “Issue and manage certificate requests” auditing in the AD CS server
Detecting exploitation in Logpoint
Analysts should look for new computer account creations where the dns_host value is set to spoof one of the domain controllers. WINDOWS_DC is a list that must contain all the FQDNs of the domain controllers operating in your domain.
1norm_id=WinServer label=Computer label=Account label=Create dns_host IN WINDOWS_DC
Searching for new computer account creations
Analysts can also hunt for odd SPN values in computer account creations that adversaries set to bypass dNSHostName validation check as described before.
1norm_id=WinServer label=Computer label=Account label=Create 2
Searching for SPN manipulations
Next, look for a mismatch between computer and dns_host values in computer account creation events. In the query below, the domain name is knowledgebase.local. Analysts should replace that value with their own domain name before using this query.
1norm_id=WinServer label=Computer label=Account label=Create dns_host=* 2
| process eval("computer_name=rtrim(computer, '$')") 3
| process eval("dns_name=rtrim(dns_host, '.knowledgebase.local')") 4
| process compare(computer_name, dns_name) as result 5
| search result=*
Searching for a mismatch between computer and dns_host values in computer account creation events
We advise analysts to review successful certificate requests for Machine template around the new computer account creation timeframe.
1norm_id=WinServer label=Certificate label=Request label=Approve 2
Searching for successful certificate requests for Machine template
We can correlate the two events by raising an alert when a newly created computer account, that is spoofing a domain controller, is successful in requesting a Machine template certificate.
1[ norm_id=WinServer label=Computer label=Account label=Create dns_host IN WINDOWS_DC ] as s1 2
followed by [ norm_id=WinServer label=Certificate label=Request label=Approve attributes="CertificateTemplate:Machine" 3
| norm on requester \<requester_account:'\S+'> ] as s2 4
within 1 hour on s1.computer=s2.requester_account 5
| rename s1.log_ts as account_creation_ts, s1.computer as computer, s1.user as user, s1.service as service, s1.dns_host as dns_host, s2.subject as certificate_subject 6
| chart count() by account_creation_ts, computer, user, service, dns_host, certificate_subject
Correlating computer account creation with successful Machine template certificate request
Adversaries can directly use DCSync attack to dump all hashes from the domain controller after obtaining its hash. Analysts can use Zeek to look for directory replication traffic originating from systems that are not domain controllers. WINDOWS_DC_IPS is a list that must contain all the IP addresses of the domain controllers operating in your domain.
1norm_id=Zeek event_category=dce_rpc endpoint=drsuapi 2
operation IN ["DRSGetNCChanges", "DRSReplicaSync"] -source_address IN WINDOWS_DC_IPS
Searching for DCSync artifacts in Zeek events
Deploy the patches and mitigations as soon as possible
We advise administrators to read Microsoft’s guidance (KB5014754) on fully remediating this vulnerability. We strongly advise administrators to patch all servers that run Active Directory Certificate Services and Windows domain controllers that service certificate-based authentication with the May 10, 2022 update. After the May update, systems will be in Compatibility Mode. If a certificate can be strongly or weakly mapped to a user, authentication will occur as expected. However, a warning will be logged unless the certificate is older than the user. If the certificate is older than the user, authentication will fail, and an error will be logged.
After patching, Microsoft has advised administrators to watch for any warnings that might appear after a month or more. If there are no warnings, Microsoft strongly recommends enabling Full Enforcement Mode on all domain controllers using certificate-based authentication. Microsoft will update all devices to Full Enforcement Mode by May 9, 2023.
Incident response on true positive
Administrators can take the following steps upon detecting a true positive alert.
- Identify the compromised user account.
- Identify the affected domain controller and CA server.
- Investigate traces of DCSync attack.
- Investigate new user creations around the timeframe for persistence.
Customers can run their SOAR playbooks to remediate compromised user accounts and clean up affected systems.
Isolate Host playbook in Logpoint SOAR
If the attackers managed to compromise the domain, administrators need to clean and rebuild their entire Active Directory from scratch. Doing this is a complicated and manual task and normally cannot be completely automated. To rebuild AD, administrators can implement the following remediation steps.
- Create fresh credentials for all accounts.
- Initiate procedures for resetting KRBTGT account password.
- Check for changes in group policy (GPO) and logon scripts.
- Promote fresh new servers to DCs and move the FSMO roles to them so that the old DCs can be decommissioned.
Recently, there have been lots of privilege escalation vulnerabilities affecting both Windows and Linux. Ransomware actors are usually quick to use them to minimize their ransomware deployment time. We advise enterprise defenders to identify whether their AD environment is vulnerable and apply necessary patches and mitigations.
Customers can download the Windows application from the help center that comes with useful detection content.