Exploiting AD Certificate Templates
Explanation on exploiting AD Certificates
In this blog we will understand what is AD Certificates Templates and how it can be exploited in an Active Directory environment in a TryHackMe room.
Setup
Login with the credentials provided in the room. You can use any remote desktop application to get access to the environment. In this we used remmina.
A Brief Look At Certificate Templates
Windows Active Directory (AD) is not just for identity and access management but provides a significant amount of services to help you run and manage your organisation. A lot of these services are less commonly known or used, meaning they are often overlooked when security hardening is performed. One of these services is the Active Directory Certificate Services (AD CS).
When talking about certificates, we usually only think about the most common ones, such as those used to upgrade website traffic to HTTPS. But these are usually only used for applications that the organisation exposes to the internet. What about all those applications running on the internal network? Do we now have to give them internet access to allow them to request a certificate from a trusted Certificate Authority (CA)? Well, not really. Cue AD CS.
AD CS is Microsoft's Public Key Infrastructure (PKI) implementation. Since AD provides a level of trust in an organisation, it can be used as a CA to prove and delegate trust. AD CS is used for several things such as encrypting file systems, creating and verifying digital signatures, and even user authentication, which makes it a promising avenue for attackers. What makes it an even more dangerous attack vector, is that certificates can survive credential rotation, meaning even if a compromised account's password is reset, that would do nothing to invalidate the maliciously generated certificate, providing persistent credential theft for up to 10 years.
The diagram above shows the flow of certificate requests and generation.Since AD CS is such a privileged function, it normally runs on selected domain controllers. Meaning normal users can't really interact with the service directly. On the other side of the coin, organisations tend to be too large to have an administrator create and distribute each certificate manually. This is where certificate templates come in. Administrators of AD CS can create several templates that can allow any user with the relevant permissions to request a certificate themselves. These templates have parameters that say which user can request the certificate and what is required. The catch is that specific combinations of these parameters can be incredibly toxic and be abused for privilege escalation and persistent access.There are some basic terminologies we need to keep in mind.
PKI - Public Key Infrastructure is a system that manages certificates and public key encryption
AD CS - Active Directory Certificate Services is Microsoft's PKI implementation which usually runs on domain controllers
CA - Certificate Authority is a PKI that issues certificates
Certificate Template - a collection of settings and policies that defines how and when a certificate may be issued by a CA
CSR - Certificate Signing Request is a message sent to a CA to request a signed certificate
EKU - Extended/Enhanced Key Usage are object identifiers that define how a generated certificate may be used
Certificate Template Enumeration
Now that we've understood the basics of AD CS, we can move forward towards enumeration. Luckily, Windows has some awesome built-in tools that can be used to enumerate all certificate templates and their associated policies. The most common approach is to use certutil. If we have access to a domain-joined computer and are authenticated to the domain, we can execute the following command in a cmd window to enumerate all templates and store them in a file.
The output will be in a text file.
The command will provide a bunch of output that may be difficult to read, but we are looking for some key indicators that will tell us that one of the templates is vulnerable. In the output, each template is denoted by Template[X] where X is the number. This can be used if you want to split the output from a single template.The specific toxic parameter set that we are looking for is one that has the following:
A template where we have the relevant permissions to request the certificate or where we have an account with those permissions
A template that allows client authentication, meaning we can use it for Kerberos authentication
A template that allows us to alter the subject alternative name (SAN)
Parameter 1: Relevant Permissions
We need to have the permissions to generate a certificate request in order for this exploit to work. We are essentially looking for a template where our user has either the Allow Enroll or Allow Full Control permission.
You will probably never find a certificate where you have the Allow Full Control permission. It is not as simple as just grepping through the output for the keywords Allow Enrolland your AD account, since certificate template permissions are in most cases assigned to AD groups, not directly to AD users.
So you will have to grep for all Allow Enrollkeywords and review the output to see if any of the returned groups match groups that your user belongs to. If you need to find your own groups, you can use this command.
There are two groups that will be fairly common for certificates:
Domain Users - This means in most cases that any authenticated users can request the certificate
Domain Computers - This means that the machine account of a domain-joined host can request the certificate. If we have admin rights over any machine, we can request the certificate on behalf of the machine account.
Parameter 2: Client Authentication
Once we've shortened the list to certificate templates that we are allowed to request, the next step is to ensure that the certificate has the Client Authentication EKU. This EKU means that the certificate can be used for Kerberos authentication. There are other ways to exploit certificates, but for this EKU will be the primary focus.
Therefore, for now, we are only interested in certificates that allow Client Authentication, meaning the certificate will be granted, given that we are the authenticated user on the machine requesting the certificate.
To find these, we need to review the EKU properties of the template and ensure that the words Client Authentication is provided. Other templates that do not match this, for now, we can discard.
Parameter 3: Client Specifies SAN
Last but definitely not least, we need to verify that the template allows us, the certificate client, to specify the Subject Alternative Name (SAN). The SAN is usually something like the URL of the website that we are looking to encrypt. For example: wix.com. However, if we have the ability to control the SAN, we can leverage the certificate to actually generate a kerberos ticket for any AD account of our choosing!To find these templates, we grep for the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT property flag that should be set to 1. This indicates that we can specify the SAN ourselves.
Answer the following questions
1. What AD group will allow all AD user accounts to request a certificate?
Domain Users
2. What AD group will allow all domain-joined computers to request a certificate?
Domain Computers
3. Which EKU allows us to use the generated certificate for Kerberos authentication?
Client Authentication
4. Which certificate template is misconfigured based on the three provided parameters?We need to find an account that matches all the perquisites mentioned above.
Answer - UserRequest
Generating A Malicious Certificate
There are two methods to generate a malicious certificate. First via command line and other one is using manually using Microsoft Management Console.
To request a new certificate, we will use the Microsoft Management Console. Load up the console by typing mmc in a run window.
This will open up the main panel.
Navigate to File -> Add/Remove Snap-in
In this window, you want to add the Certificates snap-in.
Click OK and return to main panel. Right-click on Personal, select All Tasks, and click on Request New Certificate.
For the first option, just select Next twice, since we are using the default CA, you should see the following screen showing available templates.
As you can see from the screen, we need to complete the information for our certificate before we can enroll it. Click the "More information is required to enroll this certificate." link to start the process.
On this screen, we need to be very specific about the information that we provide. In order to ensure that the certificate can be exploited for a Kerberos ticket of a privileged user, we require the User Principal Name of the user we wish to impersonate. This can be found using the AD-RSAT tools or something like the PowerView scripts.
For this example, we will impersonate one of the DA users in this domain. Let's target the svc.gitlab account since it is a service account, meaning Kerberos authentication is likely expected from this account. The UPN of this account is svc.gitlab@lunar.eruca.com. Using this information we can complete the certificate properties.
First, we change the Subject name Type to Common Name and provide the name we want for this certificate. Then, we alter the Alternative name Type to User principal name and provide the UPN of the account we want to impersonate. Add these values.
Then click on Apply. Close the panel, we can see that we're allowed to enroll this certificate.
Complete the enrollment of the certificate. Once enrolled you will be able to view the certificate under your personal certificates.
Double click on the vulncert certificate and check the details.
If we review the details of the certificate, you will see that the SAN now specifies the UPN we want to impersonate, definitely not the SAN of our web server.
Click on export and then next.
Then click on the yes option.
Generate a password --> test123
Save the certificate with a filename. The extension for this will be .pfxNow the certificate is ready for exploitation.
Answer the questions. 1. In which field do we inject the User Principal Name of the account we want to impersonate?
Subject Alternative Name
2. If we had administrative access, when adding the snap-in, which option would we select to use the machine account of the host instead of our authenticated AD account for certificate generation?
Computer account
User Impersonation
Now after generating the AD Certificate we can finally impersonate a user. There are two steps into it.
Use the certificate to request a Kerberos ticket granting ticket (TGT)
Load the Kerberos TGT into your hacking platform of choice
For the first step, we will be using Rubeus. An already compiled version is available in the C:\THMTools\ directory. Open a command prompt window and navigate to this directory. We will use the following command to request the TGT.
Breaking down the command.
/user - This specifies the user that we will impersonate and has to match the UPN for the certificate we generated
/enctype -This specifies the encryption type for the ticket. Setting this is important for evasion, since the default encryption algorithm is weak, which would result in an overpass-the-hash alert
/certificate - Path to the certificate we have generated
/password - The password for our certificate file
/outfile - The file where our TGT will be output to
/domain - The FQDN of the domain we are currently attacking
/dc - The IP of the domain controller where we are requesting the TGT from. Usually it is best to select a DC that has a CA service running
We now need to use this TGT to gain access. This can be done using your favorite hacking framework like metasploit, cobaltstrike, or covenant. However, for the purpose of this walkthrough, we will be using Rubeus again. We will use the ticket to alter the password of one of the domain administrators. This will allow us to use the DA's credentials to log into the Domain Controller as administrator to recover the final flag. Open the Active Directory Users and Computers application and explore the domain structure, looking for the DAs.
Select any one the DAs listed. And type this command.
We've successfully impersonated a Domain Admin that will gives access to the Domain Controller. To run command on the Domain Controller use the runas command utility.
Get the final flag
Mitigation
Some good defensive technique to prevent this type of persistent attack
Review all the certificate templates in your organisation for poisonous parameter combinations. You can use PSPKIAudit to assist with this.
In cases where poisonous parameter combinations cannot be avoided, make sure that there are stopgaps such as having to require Admin Approval before the certificate will be issued.
Update your playbooks. Most organisations' playbooks will include something along the lines of resetting the credentials for a compromised account. As pointed out here, that's not really going to remedy the persistent access. Therefore, reviewing certificates that were issued would be required and the malicious certificate will have to be revoked.
In the above blog, we have gone through understanding basics concepts of AD Certificate and its templates. Then in the end we learned how some mis-configurations can be leveraged to perform persistent attacks to get command execution on the Domain Controller.\
Thank You for reading ☺️
Last updated