Windows Active Directory Exploitation ADCS

Attacking AD Certificate Services – Part 3

September 23, 2023 Exploiting AD

I hope you’re enjoying this series of AD CS attack. This blog is inspired by the research papier published on specterops.io and couple of other resources listed in the references sections. As I’m writing this blog, I am also doing the same experiments in my own lab environment. All the screenshots and outcomes are from my lab machines. In Part-2 of this blog series, we learned about the certificate theft. Now we are going to focus on User Credentials Theft. At the end of this blog, I will demonstrate how you can harvest the credentials for the AD users.

Active User Credentials Theft through Certificate aka PERSIST1

If the enterprise CA server is present in the organization then a user can request a certificate for any certificate template available to them for the enrollment. The end goal here is to request a certificate for the template that will allow us the authentication to the AD server as that user. We can achieve this goal with a certificate template that has the following properties.

A certificate template should be published for the enrollment.
At least one of the user rights (domain users, domain admins, enterprise users etc.) should be allowed in the Security tab for that certificate template.
The certificate template should have at least one of the following Extended Key Usage Object Identifiers (EKU-OID) allowed which enables the domain authentication.
- Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
- Client Authentication (1.3.6.1.5.5.7.3.2)
- PKINIT Client Authentication (1.3.6.1.5.2.3.4)
- Any Purpose EKU (2.5.29.37.0)
- No EKU set. For instance: The (subordinate) CA certificate
The ‘Authorized Signature’ box should be unchecked under the Issuance Requirements in the Certificate Template Properties.

Using certify.exe find /vulnerable command we’re going to get the list of certificate which has all the above attributes applied.

[!] Vulnerable Certificates Templates :

CA Name                               : WIN-*******.vandan.lab\vandan-WIN-*******-CA
Template Name                         : User
Schema Version                        : 1
Validity Period                       : 1 year
Renewal Period                        : 6 weeks
msPKI-Certificate-Name-Flag          : SUBJECT_ALT_REQUIRE_UPN, SUBJECT_ALT_REQUIRE_EMAIL, SUBJECT_REQUIRE_EMAIL, SUBJECT_REQUIRE_DIRECTORY_PATH
mspki-enrollment-flag                 : INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS, AUTO_ENROLLMENT
Authorized Signatures Required        : 0
pkiextendedkeyusage                   : Client Authentication, Encrypting File System, Secure Email
mspki-certificate-application-policy  : <null>
Permissions
  Enrollment Permissions
    Enrollment Rights           : VANDAN-DC\Domain Admins       S-1-5-21-1483006881-1570396664-4199689388-512
                                  VANDAN-DC\Domain Users        S-1-5-21-1483006881-1570396664-4199689388-513
                                  VANDAN-DC\Enterprise Admins   S-1-5-21-1483006881-1570396664-4199689388-519
  Object Control Permissions
    Owner                       : VANDAN-DC\Enterprise Admins   S-1-5-21-1483006881-1570396664-4199689388-519
    WriteOwner Principals       : VANDAN-DC\Domain Admins       S-1-5-21-1483006881-1570396664-4199689388-512
                                  VANDAN-DC\Domain Users        S-1-5-21-1483006881-1570396664-4199689388-513
                                  VANDAN-DC\Enterprise Admins   S-1-5-21-1483006881-1570396664-4199689388-519
    WriteDacl Principals        : VANDAN-DC\Domain Admins       S-1-5-21-1483006881-1570396664-4199689388-512
                                  VANDAN-DC\Domain Users        S-1-5-21-1483006881-1570396664-4199689388-513
                                  VANDAN-DC\Enterprise Admins   S-1-5-21-1483006881-1570396664-4199689388-519
    WriteProperty Principals    : VANDAN-DC\Domain Admins       S-1-5-21-1483006881-1570396664-4199689388-512
                                  VANDAN-DC\Domain Users        S-1-5-21-1483006881-1570396664-4199689388-513
                                  VANDAN-DC\Enterprise Admins   S-1-5-21-1483006881-1570396664-4199689388-519

Certify completed in 00:00:01.4838858

Look at the highlighted “pkiextendedkeyusage : Client Authentication” for the template “User“. The ‘pkiextendedkeyusage‘ field indicate that ‘Client Authentication‘ is allowed which means ‘Client Authentication (1.3.6.1.5.5.7.3.2)‘ is enabled on this certificate template. Also, the “Authorized Signatures Required : 0” is set to zero which means no ‘Authorized Signature‘ required. Looking at the Enrollment Permission, ‘Domain Admins’, ‘Domain Users’ and ‘Enterprise Admins‘ are allowed to enrolled using this certificate. The default ‘User‘ teamplte does have these settings enabled but most AD Admin keep it disabled. In my case, I’ve created this vulnerable template for the purpose of the demonstration. You can also use “certify.exe find /clientauth” command to find the certificate template which has the ‘Client Authentication‘ OID enabled. It is important to note that if an attacker gain an ability to enroll using this certificate template than even if the user credentials changed but attacker will still have the access as long as the certificate template is valid. If we have an ability to run the certifiy on a target host, we can request the certificate using certifiy as well. “Certify.exe request /ca:CA_Server\CA_Name /template:Template_Name“

The result of the above command is the certificate and private key. you can copy this into .pem file and use the following openssl command to convert it into .pfx file and later can use with Rubeus to request a Ticket Granting Ticket (TGT) for the enrolled user. I did the same thing while solving Escape.htb machine on HTB. Let’s do it here again.

Now that we’ve pfx file, we’re going to use Rubeus to request a TGT for enrolled user and it will be valid as long as the certificate is valid. The default certificate timeline is one year.

As the certificates are the independent primary authentication credentials, this certificate will be usable even if user change their password. This technique bypass Local Security Authority Subsystem Service (LSASS). The LSASS service handles the users logging on to a Windows computer or server, handles password changes, and creates access tokens.

Let’s quickly recap using our newly domain joined windows 10 machine. First I will uses certify to grab the ‘User’ template. Then I will make a .pfx cert from it and will use Rubeus to obtain TGT for enrolled User.

Domain Escalation

So far we’ve got a good understanding on how the certificate template works and how you can request a vulnerable template and enroll with Domain Controller. Let us dig deeper in the exploration. AD CS is not inherently vulnerable. It’s human made configurational decision that makes it more vulnerable. Let’s dive into couple of exploration techniques.

ESC1 – Misconfigured Certificate Template

The certificate templates needs to have a specific settings enabled in order to be vulnerable for ESC1. Attacker would need to have at least initial authentication with the domain controller even with a low privilege account. Once we gets the initial foothold, we can use tools like Certify to enumerate a specific certificate template which has all the following attributes.

The CA server grants the enrollment rights to the low privileged users.
Manager approval is set to disabled.
No Authorized Signature Required.
Allowing enrollment rights to the low privileged users
The certificate template has one of the following EKU allowed.
- Client Authentication – OID 1.3.6.1.5.5.7.3.2
- PKINIT Client Authentication – OID 1.3.6.1.5.2.3.4
- Smart Card Logon – OID 1.3.6.1.4.1.311.20.2.2
- Any Purpose – OID 2.5.29.37.0
Certificate Template allowed request to specify the Subject Alternative Name (SAN) in the Certificate Sign-In Request (CSR).

These configurations will allow low-privileged users to request a certificate with arbitrary SAN and will allow them to authenticate as any principal in the domain via Kerberos. The ability to specify arbitrary SAN is one of the major issue. If the requester can specify the SAN in the CSR than a requester can request a certificate as anyone. Moreover, often times IT administrator will just prepare a duplicate certificate which copy the configuration settings. The default Web Server template in AD CS has CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag enabled and then IT Admins tends to provide certain EKU such as ‘Client Authentication’ which makes it vulnerable to ESC1. Putting all these things together, if there are a published certificate templates that allow for this settings, an attacker can request a certificate as anyone in the environment including as a domain admin and an attacker can then obtain a valid kerberos TGT for that user. That’s how an attacker increase their foothold within the AD network. In the following example, my Windows 10 powershell is enumerating the vulneralbe certificate which has most of the above settings have applied. Following to that we are going to obtaing kerberos TGT fot that user as well. Using the command we’re going to enumerate the vulnerabler certificate template. We’ve created ‘Vuln_VandanLabTemplate‘ certificate template for the purpose of this exercise. This command explicitly mentioned certain EKUs to enumerate the vulnerable certificate template.

Command:  Get-ADObject -LDAPFilter '(&(objectclass=pkicertificatetemplate)(!(mspki-enrollment-flag:1.2.840.113556.1.4.80
4:=2))(|(mspki-ra-signature=0)(!(mspki-ra-signature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2
) (pkiextendedkeyusage=1.3.6.1.5.2.3.4))(mspki-certificate-name-flag:1.2.840.113556.1.4.804:=1))' -SearchBase 'CN=Configuration,DC=vandan,DC
=lab' | Format-List -Property DistinguishedName,Name,ObjectClass

Following to that, I’m going to check the enrollment rights using our certify.exe find /vulnerable command for the ‘Vuln_VandanLabTemplate’ certificate template.

Note that the ‘Vuln_VandanLabTemplate’ certificate template has CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag enabled, also it has ‘Client Autnentication’ EKU OID assigned and low-privileged users (Domain Users) are allowed to Enroll. Moreover, no authorized signature or manager approval required. Now we’re going to reuqest a certificate from this template and we will specify the arbitrary SAN in our Certificate Signing Request (CSR).

Command: .\Certify.exe request /ca:WIN-VCOR12E8DFB.vandan.lab\vandan-WIN-VCOR12E8DFB-CA /template:Vuln_VandanLabTemplate /altname:administrator

Note that our altname “administrator” has been supplied to our CSR and we have obtained the Private Key and Certificate. Now we’re going to use openssl to convert this certificate into .pfx file.

The Enter Password prompt will be any password. I have just hit enter without any password. After the openssl convert, let us request a Kerberos TGT for ‘administrator’ which we can later used to access our domain controller.

We have successfully requested TGT for the user administrator from our win10_minor_user account on Win 10. Let’s perform pass-the-hash attacker on the ticket we’ve just obtained. Let’s use Certipy to get the NTLM hash for this user.

Command: certipy auth -pfx Vuln_1.pfx -dc-ip 10.0.6.4 -domain vandan.lab

Once we got the NTLM hash, we can use Hashcat to crack it.

We were able to crack the NTLM hash using Hashcat. In a real-world environment, RDP or other remote services may be enabled that you can leverage and use this credentials for.

@ringbuffer

Credits goes to where it’s due!

https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
https://ethicalchaos.dev/2020/10/04/attacking-smart-card-based-active-directory-networks/

Some of the latest blogs