Статья ADCS ESC9 – No Security Extension

Misconfigured certificate templates, particularly those affected by ESC9, pose a critical threat to Active Directory environments. By disabling the szOID_NTDS_CA_SECURITY_EXT security extension through the CT_FLAG_NO_SECURITY_EXTENSION flag, even with StrongCertificateBindingEnforcement enabled, weak or implicit certificate mappings can still be exploited. This misconfiguration enables attackers to bypass security mechanisms and potentially escalate privileges to unauthorized domain admin access.

In this article, we break down the concept of certificate mapping (implicit vs. explicit, weak vs. strong), explain the role of certificate template attributes, and highlight how ESC9 creates a dangerous security loophole in enterprise networks.

Table of Content​

• Overview the ESC9 Attack
• ESC9 Integer Attributes
• Certificate Mappings
• Prerequisites
• Lab Setup

Enumeration & Exploitation

• Method 1: Template-Based Admin Impersonation

Post Exploitation

• Lateral Movement & Privilege Escalation using certipy LDAP Shell as Administrator
• Lateral Movement & Privilege Escalation using Evil-Winrm

Mitigation

Overview the ESC9 Attack​

ESC9 is one of the escalation paths identified in Active Directory Certificate Services (ADCS) that allows an attacker to abuse misconfigured certificate templates to impersonate privileged users, such as Domain Admins.

It specifically occurs when:

• A certificate template allows users to supply Subject Alternative Names (SANs) (like UPNs), and
• The Certificate Authority (CA) honors these SANs without adequate restrictions.

As a result a low-privileged user can request a certificate for any identity (e.g., a Domain Admin), then use that certificate to obtain a Kerberos TGT via PKINIT, leading to full domain compromise.

Conditions Required for ESC9

To be exploitable, the following conditions must all be true:

• Subject name or SAN can be supplied in the request → controlled by the msPKI-Certificate-Name-Flag attribute; values like 1, 17, etc., indicate vulnerability
• CA honors SANs in requests → enabled via the EditFlags registry key (0x10000000 = EDITF_ATTRIBUTESUBJECTALTNAME2)
• Template is accessible by low-privileged users → ENROLL permission is granted to Domain Users or Authenticated Users
• No subject name enforcement → the template doesn’t restrict to only AD-resolved names
• UPN spoofing is possible → an attacker can request a certificate for any UPN, even one belonging to a Domain Admin

ESC9 Integer Attributes​

The msPKI-Certificate-Name-Flag and msPKI-Enrollment-Flag attributes in Active Directory Certificate Services (ADCS) control how certificate templates handle subject names and enrollment behaviors. Here’s an overview:

msPKI-Certificate-Name-Flag Values:

• 0x0 / 0 → Build from AD only (Safe)
• 0x1 / 1 → Supply in request (Vulnerable to ESC9)
• 0x3 / 3 → Build from AD + Supply in request (Also vulnerable)
• 0x10 / 16 → Enforce UPN in SAN (Required for ESC9 if combined with supply in request)

msPKI-Enrollment-Flag Bit Values:

• 0x1 / 1 → Include symmetric algorithms
• 0x2 / 2 → Allow key archival
• 0x10 / 16 → Remove revoked certificates from store
• 0x20 / 32 → Do not persist subject
• 0x40 / 64 → Include email in subject

Other Flags:

• flags (general) → Controls template availability, auto-enrollment, etc.
• msPKI-Template-Schema-Version

1 = Legacy Template

3 = Modern Template

If msPKI-Certificate-Name-Flag = 1 or 3 And SAN includes UserPrincipalName, ESC9 is exploitable.

Note: For more detailed information, refer to Для просмотра ссылки Войди или Зарегистрируйся on the msPKI-Certificate-Name-Flag and msPKI-Enrollment-Flag attributes

Certificate Mappings​

ESC9 is a critical misconfiguration in Active Directory Certificate Services (AD CS) that allows attackers to bypass strong authentication and impersonate privileged users.

At the heart of this issue is certificate mapping which is the process that links a certificate to an AD account. At its core, the issue revolves around certificate mapping:

• Implicit Mapping: Matches the certificate’s Subject Alternative Name (SAN) with AD account attributes like userPrincipalName. Easy to use but Vulnerable if strong enforcement is not applied (SAN spoofing risk).
• Explicit Mapping: Requires manual linking of the certificate via the altSecurityIdentities More secure but Risky if attackers can modify user attributes.

Normally, strong mappings are enforced when a certificate includes a special security extension (szOID_NTDS_CA_SECURITY_EXT). This extension ensures that only certificates issued by trusted certificate authorities (CAs) can authenticate users securely.

However, when a certificate template has the CT_FLAG_NO_SECURITY_EXTENSION flag set, that critical extension is excluded. This disables strong mapping, even if the system is configured to enforce it (StrongCertificateBindingEnforcement = 1).

As a result, weak mapping is allowed, and attackers can:

• Enroll a certificate based on a vulnerable template
• Modify an AD account’s altSecurityIdentities attribute
• Use that certificate to authenticate as any user, even a Domain Admin

This is the core of ESC9: by exploiting misconfigured certificate templates, an attacker can turn weak mappings into a powerful path for privilege escalation.

Prerequisite​

• Windows Server 2019 as Active Directory that supports PKINIT
• Domain must have Active Directory Certificate Services and Certificate Authority configured.
• Kali Linux packed with tools
• Tools: Evil-Winrm, certipy-ad

Lab Setup​

Step 1: Open the Certificate Templates Console​

• Firstly, open Certification Authority (certsrv.msc).
• Then, Right-click on Certificate Templates → Click Manage.

Step 2: Duplicate the ‘User’ Template​

• Locate the User
• Then, Right-click → Select Duplicate Template.

Note: When creating or duplicating a certificate template, choose Windows Server 2016 (or a compatible version) for Template Compatibility. This determines available features, such as support for Subject Alternative Names (SANs).

Step 3: Configure General Template Info​

Under the General tab:

• Change Template Display Name to ESC9.
• Then, Set validity/renewal period as needed.
• Check Publish certificate in Active Directory.

And Click Apply then OK.

Step 4: Configure Subject Name — Default (Secure) State​

Then, go to the Subject Name tab: Ensure

• Build from this Active Directory information is selected.
• Include e-mail name in subject name is not checked.
• User principal name (UPN) is checked under SAN.

Note: This is the default configuration. It restricts impersonation.

Step 5: Return to Certification Authority Console​

Back in certsrv.msc, right-click Certificate Templates → New → Certificate Template to Issue.

Step 6: Confirm ESC9 Is Now Issued​

• Verify ESC9 appears under the Certificate Templates node in the CA console.
• From the list, select the newly created ESC9 template.
• Click OK.

Step 7: Open ADSI Edit​

Then launch ADSI Edit (adsiedit.msc).

Step 8: Select Connect to… and choose Configuration context.​

Step 9: In the Connection Settings window:​

Under Select a well known Naming Context, choose: Configuration

Click OK.

Step 10: Navigate through the following path:​

Inside CN=Certificate Templates, find:

The object: CN=ESC9This confirms your template is now visible in the Active Directory Configuration Partition.



Note: Certificate templates are stored in the AD Configuration partition, not on the CA, allowing inspection of template GUIDs (which can be relevant in request abuse scenarios), Access Control Lists (ACLs) that may be leveraged in abuse chaining, and advanced attributes like msPKI-Template-Schema-Version, msPKI-Certificate-Name-Flag, and msPKI-Enrollment-Flag.

Step 11: In the Attribute Editor tab:​

• Scroll to find: msPKI-Enrollment-Flag
• Double-click to edit.

Step 12: Set Value: 0x80000​

The 0x80000 (PEND_ALL_REQUESTS) flag means all certificate requests need manual CA approval, useful for auditing or access control testing.

Note: This sets the flag to Remove revoked certificates from store (used in some real-world templates)

Step 13: Ensure its value is 524288 (or includes it, if combined with other flags).​

Click Ok

Step 14: Still in ADSI Edit → CN=ESC9 → Properties​

• Click Security tab → Click Add…
• Enter username: sanjeet
• Select user and under Permissions, check: Write
• And Click OK

Note: If we have write permissions on a vulnerable template, we can modify its settings (e.g., add SANs, escalate privileges), which is a key step in ADCS attacks like Для просмотра ссылки Войди или Зарегистрируйся and ESC9.

Step 15: In the CA server, open: regedit.exe​

• Navigate to: ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceskdc
• Find or create a DWORD value:

Step 16: Set value: Hex: 0x10000000​

• And Click Ok

Note: The flag 0x10000000 (268435456) = EDITF_ATTRIBUTESUBJECTALTNAME2, allows the SAN field in certificate requests to be honored, crucial for ESC9 abuse in ADCS attacks.

Enumeration & Exploitation​

Method 1: Template-Based Admin Impersonation​

In this method, we exploit two key weaknesses: we identify misconfigured certificate templates that allow user-controlled fields like UPN/SAN (via CT_FLAG_NO_SECURITY_EXTENSION), and we observe weak certificate mapping enforcement, where systems in Active Directory accept authentication based solely on the UPN in a certificate, regardless of whom it issues the certificate to. This attack doesn’t rely on stealing credentials or hashes, but instead, we abuse AD’s PKI trust model by manipulating how certificates map to user identities.

Discover Vulnerable Templates​

To exploit ESC9, first identify vulnerable certificate templates using Certipy:


This checks for templates with the CT_FLAG_NO_SECURITY_EXTENSION flag that allow users to set identity fields like UPN. These misconfigured templates enable weak certificate mapping and form the core of ESC9, making it possible to impersonate privileged users without credentials.



After running Certipy, open the generated .txt file to review certificate authority details:

This confirms the CA name (ignite-DC1-CA), and shows key settings like Web Enrollment: Disabled, Request Disposition: Issue, and most importantly, that User Specified SAN is disabled, which aligns with ESC9 characteristics, relying only on the spoofable UPN field.



Scroll down in the same .txt output to inspect individual template details, especially those marked as vulnerable:

Look for:

• Template Name: ESC9
• Enrollment Flag: NoSecurityExtension
• Enrollment Rights: Includes Domain Users
• Vulnerabilities: Marked explicitly as ESC9

This demonstrates that any user in the Domain Users group (like raj) can enroll a certificate from this template and that no certificate security extensions enforce any rules. These conditions are exactly what one needs to proceed with an ESC9-based impersonation.

Inject Shadow Credential into Proxy Account​

Next, gain access to a writable account (proxy) by injecting a shadow credential:


This injects a shadow credential into the sanjeet account, enabling authentication without knowing the password. This step prepares a proxy identity that we’ll use to impersonate the Administrator when requesting a certificate.

Spoof UPN of Proxy Account​

Then, spoof the UPN of the proxy account to match the Administrator:


This changes the User Principal Name (UPN) of sanjeet to Administrator. When StrongCertificateBindingEnforcement is set to 0, Active Directory maps certificate logins based only on UPN, enabling this impersonation trick.

Request Certificate as Administrator​

With the UPN spoofed, request a certificate using the vulnerable template:


The administrator enrolls a certificate using the ESC9 template. Since this template disables security checks and trusts the UPN field, the CA issues a certificate trusted by AD even though Sanjeet requested it.

Revert Proxy UPN to Original​

After the certificate is issued, revert the proxy account’s UPN for stealth:


This restores sanjeet’s UPN to its original value, making it harder to detect the attack. The issued certificate remains valid for Administrator, but the change hides the manipulation of the proxy account.

Authenticate as Administrator​

Authenticate as Administrator using the issued certificate:


This uses the forged certificate to perform certificate-based authentication (PKINIT). Since the certificate contains Administrator as the UPN and AD allows UPN-only mapping, it grants a TGT for the real Administrator account.

Post Exploitation​

Lateral Movement & Privilege Escalation using certipy LDAP Shell as Administrator​

Use your Administrator access to launch an LDAP shell:


This opens an interactive LDAP session authenticated as Administrator. You can now execute powerful operations like DCSync, change group memberships, or establish persistence across the domain.

Lateral Movement & Privilege Escalation using Evil-Winrm​

If you’ve captured the Administrator’s NTLM hash, connect using Evil-WinRM:


This launches a full interactive remote shell on the domain controller. At this point, you have achieved complete domain compromise through the ESC9 abuse chain.

Mitigation​

• Set StrongCertificateBindingEnforcement = 2
• Remove CT_FLAG_NO_SECURITY_EXTENSION from all active templates
• Limit who can enroll in templates with Client Authentication EKUs
• Audit certificate issuance (Event ID 4886/4887)
• Monitor UPN changes and usage of shadow credentials

Для просмотра ссылки Войди или Зарегистрируйся