The AD CS exploration blog series will help you understanding how the AD CS works. As an attacker how you can leverage vulnerable AD CS configurations to take control of the AD server. For this part, I’m focusing on high-level configurations and will go through the environment I’m using for this blog.
I have one Windows Server 2019 setup with couple of certificate templates. And following list of roles are installed on my Windows Server 2019.
- AD CS Roles
- Certificate Authority Enabled.
Also, I have a Windows 7 Professional edition installed with SP1 Windows update. The windows 7 is a domain-joined machine. Both Windows machines are running on Oracle Virtual Box. The Oracle Virtual Box has a NAT Network setup to enabled the communication between my DC and Windows 7 machines. The primary DNS configuration in my Windows 7 machine points to my Domain Controller. The AD Users list has a user called “win7_minor_user”, Low privileged AD user use to login into Windows 7 machine.
All Right! Let’s start….
In my previous blog, Escape-HTB-Struggles-And-Walkthrough, I learn about exploiting the AD CS in a windows environment on HackTheBox, So I was bit curious to setup my own vulnerable AD environment to understand the background of the attack. However, jumping on the attack directly won’t satisfy my thrust of basics so I decided to start from the scratch on configuring the vulnerable AD environment and than take advantage of couple of similar attacks. This blog will cover a lot of initial information about AD CS and we’ll end up this blog with a little bit of certificate enumerations. The part 2 of this blog series will focus on exploiting the certificate chain and gaining unauthorized AD access.
What is AD CS and Why do we need AD CS in the AD Environment?
AD CS is a Microsoft’s Public Key Infrastructure Implementation that can integrates with the existing AD environment to enables certain functions within AD such as encrypting file systems, digital signature, user authentication etc. According to Microsoft, “Active Directory Certificate Services (AD CS) is a Windows Server role for issuing and managing public key infrastructure (PKI) certificates used in secure communication and authentication protocols.”
AD CS improvise the security posture of an environment by binding computer, person or service with the Private Key. Cost-effective way to manage identity and certificate to address the security isseus within an environment. Managing certificate includes cration and revocation of certificates for any service or person. It allows you to configure group policies to determine which users or machines need what sort of certificate as per their role based or attribute based control within the AD environment.
What are some of the key features of AD CS?
As per Microsoft’s official documentation, AD CS provides the following key features within AD environment.
- Certificate Authorities (CA) – ROOT Certificate and subordinate certificate authorities (CAs) mainly use for issuing the certificate to user, system or service and to manager certificate validity.
- Web Enrollment – Web Enrollment allow users to connect to the CA using web browser to manager certificates and Certificate Revocation List(CRLs).
- Online Responder – Online Responder decodes the revocation status request (A request made to check if the certificate is revocated or not) for specific certificate, check the status of the certificate and send the signed respond with certificate status information.
- Network Device Enrollment Service – The service helps certain network devices such as routers to obtain the certificate. These devices does not have domain accounts.
- TPM (Trusted Platform Module) Key Attestation – Certificate Authority verifies that the private key is protected by a hardware-based TPM module and the TPM is the one that CA trusts. The TPM Key attestation prevents the certificate from being exported to unauthorized devices.
- Certificate Enrollment Policy Web Service – It is a simple service that enalbes users and computers to obtain certificate enrollment policy information.
- Certificate Enrollment Web Service – It enables users and computers to perform the certificate enrollment through web serivce.
Let’s dive into some parts of the certificate. A certificate is X.509 formatted digitally signed document used for encryption (e.g: encrypting file system), digital signatures (e.g: code signing) and authentication (e.g: to AD). A certificate has some of the following fields.
- Subject – The owner of the certificate.
- Public Key – Associates the Subject with private key which is stored separetely.
- NotBefore and NotAfter dates – Validity of the certificate.
- Serial Number – An identifier for the certificate assigned by CA.
- Issuer – issuer of the certificate. Commonly CA.
- SubjectAlternativeName – one or more alternative name of Subject.
- Basic Constraint – Defines if the certificate is a CA (e.g Root CA) or an end entity. Also defines if there are any constraints when using the certificate.
- Extended Key Usage(EKUs) – Object Identifiers (OIDs) that describe how the certificate will be used.
- Signature Algorithm – Defines the algorithm used in signing the certificate.
- Signature – The signature of the certificate body made using the Root CA.
Looking at sample microsoft.com certificate in the browser.
How does certificate authorities work?
- The CA is container that defines the “trusted root CA Certificates”.
- Every single CA certificates is represented as an AD Object where the “ObjectClass” is set with “certificationAuthority” and “caCertificate” attribute.
- Microsoft Windows propogates these certificates into “Trusted Root Certification Authorities” certificate store on each windows machine.
- For AD, to map the certificate chain of authority, it is important that each certificate’s chain must ends with one of the Root CA’s in this container.
So certificates can handles the encryption, message signing and authentication purpose. To handle the authenticatoin portion for any device, service or users, AD has “NTAuthCertificates” object. This object has two properties, “certificationAuthority” and “caCertificate“. Applications, services or users can only authenticate to AD using the certificates only if “NTAuthCertificates” has signed the authenticating client certificate. So when you’re using the certificate based authentication in AD environment, your certificates has signed by the “NTAuthCertificates“. In other words, “NTAuthCertificates” is your answer when dealing with AD authentications.
To get a certificate from the AD CS, a client go through the certificate enrollment process. The following diagram shows how the certificate enrollment process works.
Let’s understand how the Certificate Template works.
AD CS Enterprise CA issue certificate with a settings defined by the certificate templates. The Certificate Templates are collection of enrollment policies and predefined certificate settings. The “pKIExtendedKeyUsage” attribute on the AD CS Certificate Template contains the list of Object Identifiers (OIDs) enabled in the template. These Object Identifiers (OIDs) defines what would be the purpose of the certificate. Couple of Object Identifiers (OIDs) can be enabled for the authentication in the AD CS certificate templates.
| Name | Object Identifiers (OIDs) |
| Client Authentications | 1.3.6.1.5.5.7.3.2 |
| PKINIT Client Authentication | 1.3.6.1.5.2.3.4 |
| Certificate Request Agent | 1.3.6.1.4.1.311.20.2.1 |
The Certificate Request Agent OID (1.3.6.1.4.1.311.20.2.1) is used for requesting the certificate on-behalf of another user. We will use abuse this techniques to request certificate on-behalf of another user in the coming section.
Certificate Enrollment Needs and Mechanism
IT Admins create certificate templates and then CA publishes the certificate for clients to enroll in. AD CS specify that certificate template is enabled on the CA server by adding the template name in the “certificateTemplates” of the AD object. We can use PowerSploit from our domain-joined machine to verify this. Using the PowerSploit installed on the Domain-Joined Windows 7 machine, you can run the following command to extract the list of templates available to enroll.
The “Get-DomainObject” command with a “-SearchBase” runs the LDAP source to search through the AD CS. Our command returns the list of certificate templates with “mspki-enrollment-service” flag set to 1. Certificate templates are enabled on the CA server with “mspki-enrollment-server” flag set to 1 and the certificate templates list in the output. IT Administrators also configure the certificate template permissions using certtmpl.msc. So we have a list of certificate templates enabled on the server. Looking at the “User” certificate template on AD, we can verify that the “Domain Users” are allow to read/Write and Enroll.
Adding permissions such as R/W/E to the certificate templates sets the registry value in the regedit at following location.
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_Name>
During the process, I experience that the low-privileged users from the domain-joined system the request this reg key using following command.
If the CA server and certificate template allowed ‘Client Certificate Enrollment privileges’ than a client can request a certificate using one of the following ways.
- Using MS-WCCE (Microsoft Windows Client Certificate Enrollment Protocol) – It is a set of Distributed Component Object Model (DCOM) interface that enables client that enable client to request services from a CA. These services enables X.509 digital certificate enrollment, issuance, revocation and property retrival. It interact with AD CS. By default the DCOM server is enabled on all the AD CS.
- Using MS-ICPR (Microsoft ICertPassage Remote Protocol) – It is a subset of MS-WCCE with the exception of only allowing client enrollment and does not allow issuance, revocation and property retrival.
- Using Web Interface – You can install the AD CS server Certificate Authority Web Enrollment services and a client to open http:///certsrv/ in the browser and processed with the enrollment.
- Using Network Device Enrollment Service (NDES) – The AD CS needs to install and configure Network Device Enrollment Service which implements Simple Certificate Enrollment Protocol (SCEP) to initiate the communication and enrollment between client and Certificate Authority. I would suggest to read This Article on AD CS – NDES on the Microsoft’s website.
For this blog, I’m going to use method #1 to enroll using MS-WCCE from our Windows 7 virtual macine. On Windown 7, open the certmgr.msc and right click on the “Personal” under certificate and select All task than click on ‘Request a new Certificate’.
Once you clicked on the Request new cert, the new box appears which looks something like this. Just hit next.
On the next screen, you will see the AD Enrollment Policy with a Policy ID under ‘Configure by your administrator’. Hit Next.
On the next screen, check “show all templates”, you will see the list of all the templates. Pick the “User” certificate and click on Details. Notice the Key Usage, Application Policies and validity of the template.
Check the “User” certificate and Click “Enroll”
Enrolling…. It might take upto one to two minutes
Enrollment Successfully Completed.
Remember that the User Certificate template was present on the Windows Server 2019.
On your Windows 7 machine, you can check the certificate from “certmgr.msc“
On the Windows Server, you can verify the same thing by opening “certsrv.msc” and click on “Issued Certificates”
You can also revoke this certificate from the certsrv.msc. AD CS distributes the revoked certificate information using the Certificate Revocation List (CRLs). The Certificate Revocation List is a list of certificate serial numbers.
Let me breakdown the above process in a simple terms. Recall the diagram posted above on how the certificate enrollment works.
- Client generates the pair of public & private key and sends the Certificate Signing Request (CSR) to the Certificate Authority using Windows Client Certificate Enrollment (MS-WCCE) protocol.
- CA server performs the checks and list out the certificate that a client is allowed to enroll. Refer the list of certificate templates.
- Client pick the certificate which is allowed for the client to enroll and hit the enroll button.
- CA server create and sign the certificate based on the certificate template’s setting and return the signed certificate to the user.
Subject Alternative Names (SAN) during Authentication
The Subject Alternative Names (SAN) is x.509v3 extension. If you bind this with a certificate, it allows to attach any additional identities with that certificate. The general use case of SAN is having a multiple hosts for HTTPS certificate. For Instance if the web server hosts contains multiple domains, each domain name can include in the SAN so that the Web Server only require a single HTTPS certificate. This use case is ideal for the Web Server content/domain management situation however, It creates a critical threat situation when it merges with the domain authentication portion.
Usually, during the certificate based authentication, AD maps out the certificate to the user account based on User Principal Name (UPN) mentioned in the SAN. Attacker have an opportunity here to specify an arbitrary SAN when requesting the certificate that has Extended Key Usage Client Authentication enabled. In this case, CA creates and sign the certificate using the SAN that attacker has provided. Hence, Attacker will have access to the domain.
Remember: The EKU object represents a single extended key usage (EKU) property of a certificate.
There are few AD CS properties that allow low privileged user to provide arbitrary SAN during the certificate enrollment process and obtain the high privileged access.
All Right, Let’s do some AD Enumerations
AD Enumerations
So far we’ve configure Certificate Templates on AD CS than we’ve request the certificate from a domain-joined machine and verify our access as well. We can use either certify or certutil to enumerate our CA server. The initial enumeration will tell us the certificate enrollment settings, vulnerable templates and enrollment policies.
In order to perform enumeration, abuse and certificate theft, we are going to use Certify as well as couple of other in-built Windows tools.
Certify’s cas command can enumerate the trusted Root CA certificate, Certificates defined in the NTAuthCertificate Object and throws a lot of information about the CA Server. You will need to install Visual Studio Code to prepare the certify.exe built. Github Readme says “Certify has been built against .NET 4.0 and is compatible with Visual Studio 2019 Community Edition. Simply open up the project .sln, choose “Release”, and build.”
Let’s run the certify.exe cas command on our domain joined Windows 7 machine.
_____ _ _ __
/ ____| | | (_)/ _|
| | ___ _ __| |_ _| |_ _ _
| | / _ \ '__| __| | _| | | |
| |___| __/ | | |_| | | | |_| |
\_____\___|_| \__|_|_| \__, |
__/ |
|___./
v1.1.0
[*] Action: Find certificate authorities
[*] Using the search base 'CN=Configuration,DC=vandan,DC=lab'
[*] Root CAs
Cert SubjectName : CN=vandan-DC_HOSTNM-CA, DC=vandan, DC=lab
Cert Thumbprint : DE8703F44C7D3E3153054603A778E6B1D7DEC6D2
Cert Serial : 576247C3BC665F8941031B2DAE8C829E
Cert Start Date : 9/3/2023 1:11:36 AM
Cert End Date : 9/3/2028 1:21:36 AM
Cert Chain : CN=vandan-DC_HOSTNM-CA,DC=vandan,DC=lab
[*] NTAuthCertificates - Certificates that enable authentication:
Cert SubjectName : CN=vandan-DC_HOSTNM-CA, DC=vandan, DC=lab
Cert Thumbprint : DE8703F44C7D3E3153054603A778E6B1D7DEC6D2
Cert Serial : 576247C3BC665F8941031B2DAE8C829E
Cert Start Date : 9/3/2023 1:11:36 AM
Cert End Date : 9/3/2028 1:21:36 AM
Cert Chain : CN=vandan-DC_HOSTNM-CA,DC=vandan,DC=lab
[*] Enterprise/Enrollment CAs:
Enterprise CA Name : vandan-DC_HOSTNM-CA
DNS Hostname : DC_HOSTNM.vandan.lab
FullName : DC_HOSTNM.vandan.lab\vandan-DC_HOSTNM-CA
Flags : SUPPORTS_NT_AUTHENTICATION, CA_SERVERTYPE_ADVANCED
Cert SubjectName : CN=vandan-DC_HOSTNM-CA, DC=vandan, DC=lab
Cert Thumbprint : DE8703F44C7D3E3153054603A778E6B1D7DEC6D2
Cert Serial : 576247C3BC665F8941031B2DAE8C829E
Cert Start Date : 9/3/2023 1:11:36 AM
Cert End Date : 9/3/2028 1:21:36 AM
Cert Chain : CN=vandan-DC_HOSTNM-CA,DC=vandan,DC=lab
UserSpecifiedSAN : Disabled
CA Permissions :
Owner: BUILTIN\Administrators S-1-5-32-544
Access Rights Principal
Allow Enroll NT AUTHORITY\Authenticated UsersS-1-5-11
Allow ManageCA, ManageCertificates BUILTIN\Administrators S-1-5-32-544
Allow ManageCA, ManageCertificates VANDAN-DC\Domain Admins S-1-5-21-1483006881-1570396664-4199689388-512
Allow ManageCA, ManageCertificates VANDAN-DC\Enterprise Admins S-1-5-21-1483006881-1570396664-4199689388-519
Enrollment Agent Restrictions : None
Enrollment Policy Web Service : https://DC_HOSTNM.vandan.lab/ADPolicyProvider_CEP_Kerberos/service.svc
NDES Web Service : http://DC_HOSTNM.vandan.lab/certsrv/mscep/
https://DC_HOSTNM.vandan.lab/certsrv/mscep/
Enabled Certificate Templates:
ClientAuth
SmartcardLogon
Workstation
IPSECIntermediateOffline
CEPEncryption
EnrollmentAgentOffline
DirectoryEmailReplication
DomainControllerAuthentication
KerberosAuthentication
EFSRecovery
EFS
DomainController
WebServer
Machine
User
SubCA
Administrator
Certify completed in 00:00:21.3689496
It list out few important things such as Root CA and NTAuthCertificate that has authentication enabled, access rights for the enrollment CAs and list of all the certificate templates.
You can enumerate the same information using certutil.exe on the domain-joined machine using the following command
certutil.exe -TCAInfo
================================================================
CA Name: vandan-DC_HOSTNM-CA
Machine Name: DC_HOSTNM.vandan.lab
DS Location: CN=vandan-DC_HOSTNM-CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=vandan,DC=lab
Cert DN: CN=vandan-DC_HOSTNM-CA, DC=vandan, DC=lab
CA Registry Validity Period: 2 Years -- 9/8/2025 1:22 AM
NotAfter: 9/3/2028 1:21 AM
Connecting to DC_HOSTNM.vandan.lab\vandan-DC_HOSTNM-CA ...
Server "vandan-DC_HOSTNM-CA" ICertRequest2 interface is alive
Enterprise Root CA
dwFlags = CA_VERIFY_FLAGS_NT_AUTH (0x10)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_NT_AUTH
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=vandan-DC_HOSTNM-CA, DC=vandan, DC=lab
NotBefore: 9/3/2023 1:11 AM
NotAfter: 9/3/2028 1:21 AM
Subject: CN=vandan-DC_HOSTNM-CA, DC=vandan, DC=lab
Serial: 576247c3bc665f8941031b2dae8c829e
de 87 03 f4 4c 7d 3e 31 53 05 46 03 a7 78 e6 b1 d7 de c6 d2
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Exclude leaf cert:
da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
Full chain:
de 87 03 f4 4c 7d 3e 31 53 05 46 03 a7 78 e6 b1 d7 de c6 d2
Issuer: CN=vandan-DC_HOSTNM-CA, DC=vandan, DC=lab
NotBefore: 9/3/2023 1:11 AM
NotAfter: 9/3/2028 1:21 AM
Subject: CN=vandan-DC_HOSTNM-CA, DC=vandan, DC=lab
Serial: 576247c3bc665f8941031b2dae8c829e
de 87 03 f4 4c 7d 3e 31 53 05 46 03 a7 78 e6 b1 d7 de c6 d2
A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478)
------------------------------------
Supported Certificate Templates:
Cert Type[0]: ClientAuth (Authenticated Session)
Cert Type[1]: SmartcardLogon (Smartcard Logon) -- No Access!
Cert Type[2]: Workstation (Workstation Authentication)
Cert Type[3]: IPSECIntermediateOffline (IPSec (Offline request)) -- No Access!
Cert Type[4]: CEPEncryption (CEP Encryption) -- No Access!
Cert Type[5]: EnrollmentAgentOffline (Exchange Enrollment Agent (Offline request)) -- No Access!
Cert Type[6]: DirectoryEmailReplication (Directory Email Replication) -- No Access!
Cert Type[7]: DomainControllerAuthentication (Domain Controller Authentication) -- No Access!
Cert Type[8]: KerberosAuthentication (Kerberos Authentication) -- No Access!
Cert Type[9]: EFSRecovery (EFS Recovery Agent) -- No Access!
Cert Type[10]: EFS (Basic EFS)
Cert Type[11]: DomainController (Domain Controller) -- No Access!
Cert Type[12]: WebServer (Web Server) -- No Access!
Cert Type[13]: Machine (Computer) -- No Access!
Cert Type[14]: User (User)
Cert Type[15]: SubCA (Subordinate Certification Authority) -- No Access!
Cert Type[16]: Administrator (Administrator) -- No Access!
Validated Cert Types: 17
================================================================
DC_HOSTNM.vandan.lab\vandan-DC_HOSTNM-CA:
Enterprise Root CA
A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478)
Online
CertUtil: -TCAInfo command completed successfully.
Along with Root CA and certificate templates, it also lists which templates have authenticated sessions allowed and which one doesn’t have it allowed. To get the detail information about the each available certificate template you can run “certutil.exe -v -dstemplate” command;
In the next part of this blog I’m going to perform Certificate Theft and we will dive into exploiting AD CS environment.
Stay Tune!
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/
- https://github.com/GhostPack/Certify
- https://posts.specterops.io/certified-pre-owned-d95910965cd2
@ringbuffer
Some of the latest posts