Microsoft Defender for Identity (MDI) has announced a new capability back in February to detect suspicious certificate usage for Kerberos authentication. It is already well-known, that Active Directory Certificate Services (ADCS) is a lucrative target for adversaries to achieve persistence in Active Directory as ADCS can be easily misconfigured resulting in an easy way to exploit those misconfigurations. In this post I want to show you how easy those misconfigurations can be abused and how and when such an attempt is detected by Microsoft Defender for Identity new detection capabilities for suspicious certificate usage.

What makes a vulnerable environment

To be vulnerable for the certificate abuse scenario I will demonstrate an environment needs to have the following conditions present:

  • ADCS Enterprise Certification Authority (CA)
  • CA certificate must be present in NTAuth store (default behaviour when an enterprise ADCS CA is installed)
  • At least one domain controller needs to have a kerberos authentication certificate enrolled
  • At least one vulnerable certificate template that meets one of the following criteria’s:
    – “specify subject name in the request” flag enabled AND granting enroll permissions to low privileged principals like domain users or domain computers (or equivalent)
    – grants modify permissions to low privileged principals like domain users or computers (or equivalent)

The first three conditions are usually present in a standard Active Directory deployment and provide key functionality for other services. Certificate templates are also a standard thing, but there it really comes down to the (mis)configuration and hardening. Specterops documents those very well and provides tools to check for potential misconfigurations¹.

For this post I will use a duplicate of the standard computer certificate template with the following settings:

  • Extended Key Usage: Client Authentication
  • Enrolee Supplies Subject Flag Enabled (Supply Subject Name in the request)
  • Domain users have enroll permissions

Weaponization

To demonstrate the attack I use the following tools provided by Spectreops on GitHub:

Both tools need to be compiled with Visual Studio or can be downloaded from other sources in precompiled formats.

As adversary we might not know about the vulnerable certificate templates but because they reside within Active Directory and Authenticated Users have read permissions on all templates by default, we can easily enumerate the vulnerable template(s) with certifiy. For all subsequent steps I use a regular domain user account, that has local admin permissions on a Windows client:

After we have found a vulnerable template, we can depending on the permissions either modify the template to set the ENROLEE_SUPPLIES_SUBJECT flag or directly profit if we have enrollment permissions on the template (that’s what I use for this demo).

Of course we want to go all in and request a certificate for the built-in Administrator account. We can do so by calling certify with the request option and specifying the subject alternate name:

The printed out RSA key pair can the be converted with openssl and exported as a PFX file. Afterwards, with the help of rubeus we can request a kerberos ticket granting ticket (TGT) for the built-in domain admin account:

We can then also use this ticket with rubeus to perform actions with the newly gained entity:

  1. Importing the obtained kerberos ticket
  2. Listing the available kerberos tickets
  3. I truncated the output but this is the TGT for the Administrator account
  4. Enumerating the c$ share of the domain controller

Pretty impressive how we elevated that fast from a regular domain user directly to a domain admin. But let’s see what Microsoft Defender for Identity observed during this attack.

Hello from MDI 🚨

After the Kerberos Ticket acquisition with Rubeus MDI fired up the awaited Suspicious certificate usage over Kerberos protocol (PKINIT) alert! After a short delay the alert got automatically correlated together with the client side events because Defender for Endpoint also noticed all the tools and actions being executed on the client (to allow the execution I enabled troubleshooting mode and disabled real time protection).

Mentionable is also, that MDI includes the certificate based on the thumbprint within the alert details. This information can be used to search for the corresponding certificate request or directly revoking the certificate.

Important to understand is, that MDI detected the acquisition of the kerberos ticket, but not the previous steps.

Can’t we detect this earlier?

Of course it is nice that MDI now detects this behaviour but I could imagine that attackers might first only want to establish persistence and gain a certificate for a privileged account before they continue their attack and take advantage of the gained privileges. In this case MDI would not trigger the “Suspicious certificate usage” or other alerts until the certificate is being used.

When advanced auditing and event forwarding for ADCS enterprise CA is enabled (if not, you should definitely consider this!²), we can already detect issuance of certificates by looking into submitted and issued certificate requests:

Unfortunately we’re missing some key information when it comes to:

  • Certificate Template Name or OID
  • Certificate Template Application Policies
  • Certificate Request Subject Alternate Name Extension

Owen Shearing describes a potential solution³ by considering additional security events from domain controllers but these also rely on the event that the certificates will be used for authentication.

Fortunately there is an upcoming enforcement planned by Microsoft, to increase the difficulty for such attacks by using stricter certificate mapping.

Upcoming Active Directory KDC Changes

Microsoft started hardening of Kerberos Key Distribution Center when it comes to the certificate mapping to Active Directory users. In this demo we saw, that just because of the subject alternate name the certificate was mapped to the builtin Administrator account of the domain. Back in spring 2022 Microsoft announced multiple enforcement steps to increase the security of certificate mapping with KB5014754⁴. The next step takes place in April 2023 that will enforce certificates to have the new OID present and the full enforcement in November 2023 will not allow weak mappings between certificates and user accounts.

That is actually a good thing because this behavior change prevents the demonstrated attack!

We can already switch to full enforcement mode by manually enforcing the strong mapping by creating the following registry entry:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
  • StrongCertificateBindingEnforcement: 2 (DWORD)

A subsequent attempt to request a kerberos TGT ticket with rubeus fails, as no strong mapping can be performed by our certificate and the user account:

The domain controller’s system event log also contains the corresponding event from the KDC service:

So by setting the value for StrongCertificateBindingEnforcement to 2 we can defend successfully against this type of attack. Although full enforcement might not be possible yet in all environments as there are still some unclear questions when it comes to certificates not enrolled online (e.g. enrolled via SCEP).

During the process of writing this post, Microsoft announced another way to achieve mapping, by using a special SAN URI for this certificates⁵, that would allow again tampering with weak certificate templates as we can supply also malicious SAN URIs when we can control subject alternate names.

🔑 Take aways and recommendations

  • Enable appropriate data source for event forwarding to Sentinel to have additional evidence for misuse of certificates: ADCS advanced auditing, and Domain Controller Security Events for kerberos authentication success and failure
  • Regularly check ADCS certificate templates for misconfigurations, e.g. via GhostPack/PSPKIAudit: PowerShell toolkit for AD CS auditing based on the PSPKI toolkit. (github.com)
  • Audit and alert on certificate template changes or configuration changes to ADCS
  • Already consider the enforcement of certificate mapping and the upcoming enforcement
  • Make sure your MDI sensors are in a healthy state and auto update is working to profit from new detection capabilities⁶
  • Ensure that all systems are onboarded to Defender for Endpoint and sensors reporting properly to detect usage and enumeration of tools to attack ADCS from domain member clients

One thing I learned while writing this post was that detecting misuse of certificate template issuance is very hard. As we’re lacking important audit data such as the subject alternate name from ADCS. If you know any way about how to get these please let me know! I already though about trying to get this data with sysmon for the certsrv process on the CA or trough sysmon on the client side but havent had the time to dive further into this.

References and further reading

This post was written based on the following information provided and referenced via superscript:

  1. SpecterOps provides a really nice guide about the different misconfigurations for ADCS and certificate templates that can be found here: Certified_Pre-Owned.pdf (specterops.io). They also offer a PowerShell toolkit to scan for potential ADCS misconfigurations and vulnerable templates.
  2. Kaido Järvemets has covered the whole ADCS event forwarding topic to Sentinel very nicely: Audit Active Directory Certificate Services using Microsoft Sentinel (kaidojarvemets.com), Microsoft Active Directory Certificate Services Event Logs (kaidojarvemets.com)
  3. Detecting AD CS subjectAltName (SAN) Abuse Using KQL: Detecting AD CS subjectAltName (SAN) Abuse Using KQL — In.security
  4. Certificate-based authentication changes on Windows domain controllers: KB5014754 — Certificate-based authentication changes on Windows domain controllers — Microsoft Support
  5. Preview of SAN URI for Certificate Strong Mapping for KB5014754: Preview of SAN URI for Certificate Strong Mapping for KB5014754 — Microsoft Community Hub
  6. Microsoft Defender for Identity Release Notes: What’s new — Microsoft Defender for Identity | Microsoft Learn

By Nicola on April 11, 2023.