ADCS
Notes on Active Directory Certificate Services (ADCS) I made during CESP-ADCS course
Last updated
Notes on Active Directory Certificate Services (ADCS) I made during CESP-ADCS course
Last updated
Certificate Formats
• X.509 digital certificates are primarily used by AD CS.
• Some commonly used X.509 certificate formats used by AD CS are:
PEM: A Base64-encoded DER certificate commonly used as .pem, .crt, .cer, or .key extensions to store multiple private keys and certificates without password protection.
DER: binary form of a PEM certificate.
PFX/P12 (PKCS#12): binary form used to store multiple private keys and certificates with password protection.
P7B (PKCS#7): used to store multiple chain certificates (it doesn’t store a private key).
• Some commonly used EKU OIDs and their corresponding use cases are as follows:
Server Authentication (1.3.6.1.5.5.7.3.1): intended for server authentication, allowing the certificate to be used for authenticating servers in SSL/TLS communication.
Client Authentication (1.3.6.1.5.5.7.3.2): allows the certificate to be used for verifying the identity of clients accessing secure services.
Code Signing (1.3.6.1.5.5.7.3.3): used for signing executable code, scripts, and macros. It verifies the integrity and authenticity of software or code by ensuring that it hasn't been tampered with since it was signed.
Secure Email (1.3.6.1.5.5.7.3.4): used for digitally signing and encrypting email messages, ensuring the confidentiality and integrity of email communications.
Encrypting File System (1.3.6.1.4.1.311.10.3.4): allows for the encryption and decryption of files and folders on NTFS volumes.
• With appropriate privileges, it is possible to request | import | export the user or machine certificates from a machine. There are several ways we can accomplish this interactively (Windows Certificate Manager) or using Crypto WINAPIs.
• To request | import | export using Crypto WINAPIs we can use tools such as Certify and CertUtil.
• Request Certificate in pem format
• Import Certificate into User Certificate Store
• Export Certificate from User Certificate Store using Certificate Serial
• To request | import | export certificate interactively we can also use the Windows Certificate Manager or MMC.
• Pass-the-Cert (PTC) is a pre-authentication technique that uses a certificate (with private key) to obtain a TGT (Certificate-based Authentication).
• This technique is primarily used for User/Computer account impersonation for domain authentication similar to OverPass-the-Hash and Pass-the-Ticket techniques.
• To perform PTC operations, it is required that the certificate used has the Client Authentication EKU set.
• PTC can be used with PKINIT and Schannel protocols.
PTC using PKINIT
• Public Key Cryptography for Initial Authentication (PKINIT) is a pre-authentication protocol for Kerberos which uses X.509 certificates to request a TGT.
• With a certificate valid for authentication (Client Authentication EKU set), it is possible to request a TGT using the PKINIT protocol. We will be using this technique for user/computer impersonation for majority of the lab.
PTC using Schannel
• If PKINIT is not supported by the DC, LDAPS can be abused to Pass-the-Cert using the PassTheCert tool.
• LDAPS support Schannel Security Service Provider that implements SSL and TLS authentication protocols.
• We can use the PassTheCert tool for authentication as follows:
• If we manage to gain a privileged user context in the domain, then we can primarily use the PassTheCert tool to configure and abuse RBCD/Reset Password/DCSync and more in Active Directory.
• In this technique, if we have a PKINIT TGT (certificate keypair) for a user, we can recover the NTLM hashes of the target user.
• Similar to Shadow Credentials but unlike that, does not require GenericWrite on an object.
• When a certificate is used to request a TGT using PKINIT, the KDC includes PAC_CREDENTIAL_INFO structure in the ticket. The structure contains NTLM hashes of the authenticating user.
• These NTLM hashes can be recovered by requesting a service ticket through User-to-User authentication (U2U) so that the user can decrypt the service ticket.
• S4U2self (Service ticket to itself on behalf of a user) can then be used to impersonate any user including a DA.
Example -
• An example command to perform the UnPAC the Hash attack using Certipy is as follows:
• "S4U2Self (Service for User to Self) is an extension that allows a service to obtain a service ticket (TGS) on behalf of a user to itself."
• By default, machine accounts cannot access machines remotely. To gain remote admin access we can abuse the S4U2Self attack or DCSync (if applicable).
• Using target user or machine account credentials, we can use S4U2Self to get a TGS for a service (Ex: CIFS, HOST, HTTP) impersonating any user including a DA. An example is as follows:
• Look for AD CS containers using the AD Module -
• Based on ObjectClass -
• Enumerate CA -
• Find Templates -
• Perform tgtdeleg Attack to get a TGT
• Perform S4U2Self Attack to gain CIFS admin access
• “Windows Hello for Business replaces passwords with strong two-factor authentication on devices. This authentication consists of a type of user credential that is tied to a device and uses a biometric or PIN.”
• How WHfB works:
On enrollment, TPM (Trusted Platform Model) firstly generates a private-public key pair for the user's account and then stores the public key in a new Key Credential object called the msDS- KeyCredentialLink attribute of the account.
The private key is protected by a PIN, which Windows Hello allows replacing with a biometric authentication factor, such as fingerprint or face recognition.
Windows uses this private key to perform PKINIT authentication where validation occurs when the DC can decrypt the raw public key present in the client’s msDS-KeyCredentialLink attribute.
Once pre-authentication is successful, the Domain Controller can exchange a session using one of the supported methods.
• If an attacker has control over a user or machine account (GenericAll/GenericWrite) it can be abused to compromise the target by adding Shadow Credentials.
• This is done by adding Key Credentials to the msDS-KeyCredentialLink attribute of the target object.
• This would allow us to request a TGT and also the NTLM hash (UnPAC-The-Hash) for the target user or machine account.
• Shadow Credentials also serves as a good persistence mechanism since these credentials would persist even if the user/computer change their password.
• Whisker (https://github.com/eladshamir/Whisker) aids red teams to abuse Shadow Credentials using the msDS-KeyCredentialLink attribute in red team operations.
• This tool generates a certificate and an asymmetric key and stores them in the msDS-KeyCredentialLink attribute. The generated certificate could be used with Rubeus in order to request a TGT for the target.
• A sample command to add this misconfiguration using Whisker is as follows:
• Additionally, this attack can also be carried out in a non-domain joined Linux machine using coerced authentication and a ntlmrelayx module called --shadow- credentials. A sample command to do this is as follows:
• Shadow Credentials is an alternative to PasswordReset, Kerberoasting and RBCD (all need GenericWrite).
• However, Shadow Credentials abuse does result in events which can be used for telemetry/detection.
• Windows Defender Application Control (WDAC), formerly known as Device Guard, is one of Microsoft’s allowlisting solutions.
• WDAC “allows organizations to control which drivers and applications are allowed to run on their Windows clients”.
• It allows only ‘known good code’ to run and prevents the execution of untrusted code, drivers, and scripts.
• All WDAC policies apply to the managed computer as a whole and affect all users on the device.
• WDAC can be setup locally (vulnerable to admin access) or using Group Policy (secure).
• As per Microsoft docs, WDAC rules can be defined based on:
Attributes of the codesigning certificate used to sign an app and its binaries.
Attributes of the apps binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file.
The reputation of the app as determined by Microsoft's Intelligent Security Graph.
The identity of the process that initiated the installation of the app and its binaries.
The path from which the app or file is launched.
The process that launched the app or binary.
• WDAC example policies exist on Windows by default at: C:\Windows\schemas\CodeIntegrity\ExamplePolicies
• An easy way to manage or edit WDAC policies is by using the WDAC Policy Wizard.
• WDAC once enforced puts a Policy Engine as a .p7b file at: C:\Windows\System32\CodeIntegrity
• A simple way to disable WDAC if setup locally is to delete the .p7b file and reboot the machine (needs admin privileges).
• However, this wouldn't be applicable if WDAC was setup using GPO because the WDAC configuration is applied again on reboot.
• Code Signing ensures that files weren't tampered and are verified by a Trusted Authority. Microsoft implements this using Authenticode Signatures.
• "Authenticode identifies the publisher of Authenticode-signed software. Authenticode also verifies that the software has not been tampered with since it was signed and published."
• A Code Signing certificate can be used to sign scripts, binaries, files etc. for trusted execution. A Code Signing template can be configured in AD CS to distribute and manage Code Signing certificates. For this the template requires: Code Signing --> 1.3.6.1.5.5.7.3.3 EKU is enabled.
• Code signing with WDAC User-Mode Code Integrity (UMCI) allows to validate user mode executables and scripts based on their Certificate Signatures.
• Only signed code from trusted publishers will be allowed to execute.
• If we can compromise a Code Signing certificate trusted by WDAC, it would be possible to run such signed code (scripts, binaries etc.) on the target machine.
• An example to sign files using a Code Signing certificate with signtool (part of .NET framework) is as follows:
• “Just Enough Administration (JEA) is a security technology that enables delegated administration for anything managed by PowerShell.”
• JEA provides a PowerShell Remoting endpoint with:
Virtual accounts - temporary local accounts which are local admin on member machines and DA on DCs but no rights to manage resources on network.
Ability to limit the cmdlets and commands which a user can run through Role Capabilities.
• Limits number of administrators and allows limited admin tasks to be done by non-admins.
• A JEA endpoint uses Role Capability to determine what someone can do in a JEA session.
• Multiple options are available:
Visible PowerShell cmdlets and Parameters to allowed cmdlets
Visible external commands and scripts
Visible PowerShell Providers (FileSystem, Registry etc.)
PowerShell modules that will be automatically imported in the JEA session
• A poorly configured Role Capability (uses wildcard * in visible commands and/or allows commands that can be used to make changes - like net, Start-Process, Add- LocalGroupMember etc.) may lead to compromise of the target machine as the commands run with admin privileges.
• A JEA endpoint is registered using a Session Configuration file.
• Major Session Configuration options:
Who has access to the JEA endpoint (Role definition)
Name of the JEA endpoint
Identity used by JEA endpoint (virtual accounts, domain groups, local groups, gMSAs etc.)
PowerShell LanguageMode (only 8 helper cmdlets allowed in the NoLanguage Mode)
• A poorly configured Session Configuration (Overly permissive role definition, high privilege identity etc.) may lead to compromise of the target machine.
• CredSSP is (wrongly) used by organizations to address the Kerberos double hop issue.
• "CredSSP authentication delegates user credentials from the client to a remote computer to further allow the remote computer to reuse the credentials to authenticate to a third computer."
• However, it is not recommended to use CredSSP because if the machine is compromised credentials cached by CredSSP can be extracted in clear-text.
• In the lab CredSSP is configured on the cb-signsrv server.
• "Encrypted File System (EFS) is a Microsoft technology that lets you encrypt data on your computer, and control who can decrypt, recover and view the data."
• Encrypting a file with EFS denies access to unauthorized users/an attacker who has access to the computers data even if the user is a high privilege user.
• To use EFS for encryption, an EFS certificate is required to be imported into the current user’s Certificate Store and permission to modify the target file is required.
• A recovery agent is required to read or recover data encrypted using EFS - The default DA is a recovery agent in a domain.
• Two types of certificates play a role in EFS:
Encrypting File System certificates --> 1.3.6.1.4.1.311.10.3.4: This type of certificate uses EFS to encrypt and decrypt data and is called as an EFS certificate.
File Recovery certificates --> 1.3.6.1.4.1.311.10.3.4.1: This type of certificate allows to recover all encrypted files and folders (domain or offline) no matter who encrypted them and is called as an EFS DRA (Data Recovery Agent) certificate.
• Microsoft details two methods to perform decryption operations:
Retrieve the original EFS certificate used to encrypt the file and import it in the target computer certificate store.
Use an EFS DRA certificate to restore an EFS encrypted file if the original EFS certificate used to encrypt the file is lost.
• Secure Shell (SSH) supports multiple authentication methods:
Password (using username and password)
Public key-based (using public and private key pairs) – Certificate-based (using CA signed certificates)
• SSH Certificate-based authentication offers the following features:
Certificates are tied to user identities.
Certificates automatically expire.
Certificates include metadata which can be used to enable role-based access control.
The user and host certificates signed by the same CA establish trust. This eliminates the need for Trust On First Use which is common with Public-key based authentication.
• Setting up SSH Certificate-based authentication:
A SSH CA is setup with private and public keys.
The private key of the SSH CA is used to sign user and host (SSH server) certificates and are distributed to users and hosts, respectively.
The public key of the SSH CA is copied to the SSH server, which is used to verify the user's certificate used for authentication.
• Using SSH Certificate-based authentication:
A SSH client presents the signed user certificate to the SSH server for each SSH connection.
SSH server validates the client certificate using CA public key and check so expiry etc.
Access is granted upon successful validation of the certificate.
• To integrate SSH Certificate-based Authentication in Active Directory tied to Domain principals we can use the following solutions:
Store SSH Certificates as attributes.
SSH authentication with AzureAD.
Using the HashiCorp SSH Signer and SSH Vault CA.
Use 3rd party seperate SSH CAs.
• In the lab, SSH authentication with Active Directory principals has been setup using HashiCorp Vault.
• HashiCorp Vault is an open-source tool that provides secure storage and access to secrets such as passwords, API keys, and other sensitive information. It also provides services to manage PKI related architecture like VPNs, SSH CAs and much more.
• Vault uses a technique called key sharing to split the master encryption key into multiple parts, known as unseal keys. Vault unseal keys are essentially pieces of the master encryption key that are required to unlock the vault and access its contents.
• By default, Vault is sealed when it starts up. In order to unseal the vault and gain access to its contents, you need to provide a certain number of unseal keys (minimum 2), which are distributed among different individuals or stored in secure locations.
• Once logged in, Vault provides an access token which is subject to access token policies. Vault Policies enforce ACLs over users to view, modify or update content on the HashiCorp vault.
• Even with root access to the machine hosting HashiCorp vault the only way to compromise HashiCorp vault is through a valid token generated using a valid authentication method such as ldap, user-pass, tokens etc.
• When authentication is done using the Vault CLI tool, a ".vault-token" file is placed in the home directory of current user. If this token file is compromised for a high privileged vault user, it could be used to escalate privileges.
• HashiCorp Vault supports SSH CA capabilities for Signed SSH Certificates.
• For SSH authentication:
The client first submits the public key setup by the target SSH server to the Vault SSH CA Signer.
A Signed SSH Certificate is returned by Vault.
The client can then use this Signed SSH Certificate (with the corresponding private key setup by the target SSH server) for secure authentication.
• Certificates can be used for mutual authentication between VPN Servers and Clients.
• These certificates do not contain information specific to a VPN implementation rather are used to ensure secure authentication. They are most commonly X.509 certificates.
• “A common VPN certificate configuration begins by both the server and client authenticating by first verifying that the presented certificate was signed by the same CA, and then other checks present in the configuration are performed.”
• Linux uses /etc/ssl directories or flat NSS SQLite database files to store certificates.
• Network Security Services (NSS) is a set of libraries designed to support cross- platform development of security-enabled client and server applications.
• Applications built with NSS can support SSL v2/v3, TLS, PKCS #5, PKCS #7 etc.
• On Linux, certutil and pk12util are two tools that can be used to manage private keys and certificates using NSS databases and NSS tokens.
• We can use certutil to view and initialize a NSS database for certificate storage . To import/export certificates from a NSS database we can use pk12util.
• To create and initialize a NSS database use certutil as follows:
• To import and export certificates use pk12util as follows:
Exporting certificates and their private keys using Window’s Crypto APIs
• It is possible to export user/machine certificates from the Windows Certificate Manager if the user has appropriate privileges. We can accomplish this interactively or using Crypto WINAPIs (THEFT1).
• Once a user/computer certificate is extracted we can exfiltrate the certificate and reuse it to Pass-the-Cert and authenticate to Active Directory.
• Certificates can be exported in a .pem/.cer or .pfx format. Usually when exporting as a .pfx, there are two methods to protect the certificate - AD Principals or passwords.
• If the certificate is password protected, it could be vulnerable to brute force/password guessing attacks.
• It is possible to list and export certificates from the Windows Certstore using built-in tools like CertUtil, built-in PowerShell Cmdlets and external tools like CertStealer, CertifyKit. An example using CertUtil is as follows:
Extracting User certificates and private keys using DPAPI
• Data Protection API (DPAPI) provides the means for encrypting and decrypting (CryptProtectData() and CryptUnprotectData()) data blobs using cryptographic keys associated with user or computer accounts.
• DPAPI is useful protecting data like Browser Cookies, Login Data, Windows Credential Manager, Vault and certificates/private keys.
• DPAPI is also used to protect certificate private keys. Different storage locations are used for user and machine private keys.
• To obtain a user certificate and its private key using DPAPI manually, we need to:
Map the target certificate in the user’s certificate store and get the key store name.
Find and Extract the DPAPI masterkey needed to decrypt the associated private key.
Combine the private key and certificate to a .pfx to use for domain authentication.
• Some useful registry entries to note for user certificates and private keys are:
Certificates: HKEY_CURRENT_USER\SOFTWARE\Microsoft\SystemCertificates; %APPDATA%\Microsoft\SystemCertificates\My\Certificates\
Private Keys: %APPDATA%\Microsoft\Crypto\RSA<User SID>\
• To obtain a specific DPAPI masterkey in plaintext (using mimikatz) we can perform one of the following:
One way to do this is using a domain’s DPAPI backup key. This key can decrypt any domain user’s masterkey file. If an adversary obtains domain admin (or equivalent) privileges, the domain backup key can be stolen and used to decrypt any domain user masterkey in plaintext.
Another way is to decrypt the masterkey using the corresponding user's password.
• An example command to use SharpDPAPI to decrypt discoverable masterkeys using the domain backup key is as follows:
Extracting Computer certificates and private keys using DPAPI
• This is like THEFT2 except that we target the Machine certificate store. We cannot use the domain DPAPI backup key to decrypt Machine Keys.
• We need to use the DPAPI_SYSTEM LSA secret on the target machine which is accessible only to the SYSTEM user.
• Some useful registry entries to note for Machine certificates and private keys are:
Certificates: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates; %APPDATA%\Microsoft\Crypto\RSA\MachineKeys
Private Keys: %APPDATA%\Microsoft\Crypto\RSA\MachineKeys
• An example command for extracting Machine certificate abusing DPAPI (using mimikatz) is as follows:
• To perform the same automatically using SharpDPAPI we can use the following command:
Theft of existing certificates on-disk
• It is possible that certificates and their associated private keys are found on disk (not just in certificate stores) due to careless handling of such sensitive files.
• To search for such files, we target recursively searching for common certificate file extensions on disk.
• We can use manual PowerShell and CMD search queries or use tools such as Seatbelt to automate the searching process to save time.
• We can enumerate for the following critical extensions that may help us find and compromise certificates/private keys on disk.
.key: Contains just the private key
.crt/.cer: Contains just the certificate
.csr: Certificate signing request file. This does not contain certificates or keys
.jks/.keystore/.keys: Java Keystore. May contain certs + private keys used by Java applications
.pem: Contains certificate and associated private key (unprotected)
.pfx/.p12: Contains certificate and associated private key (protected)
• An example PowerShell query to search for such certificate files recursively based on files extension is shown below.
• Ovpn file could be of much interest as they may contain Private key of a client to provide password-less experience (server configuration must support that).
• With access to any such config file, we can connect to a protected or a private network.
• Look for ovpn files in %USERPROFILE%/OpenVPN/Config and %PROGRAMFILES%/OpenVPN/Config directories.
User account persistence using new certificate requests
• A certificate remains valid even if the target user account password is changed.
• If we compromise a user who has enrollment rights to an AD CS template that has the Client Authentication EKU enabled, we can request and use a certificate that will be valid until the expiry specified in the template.
• An example command to request such a certificate to maintain User Persistence using Certify is as follows:
Computer account persistence using new certificate requests
• With SYSTEM rights on a domain joined machine and enrollment rights to a certificate template with Client Authentication EKU, we can request a certificate for the machine account that will be valid even if there is a password change, system wipe etc.
• An example command to request a machine certificate using Certify is as follows:
• DC account can be targeted after DA priv escalation, since with its privileges it is possible to DCSync or perform a S4U2Self attack to ultimately compromise the entire domain.
User/Computer Account persistence by certificate renewal before expiration
• We can renew compromised/requested certificates before they expire. Note the Validity Period of a certificate!
• This can function as an extended persistence approach that prevents additional ticket enrollments from being requested, which leave additional artifacts on the CA server.
• An example to renew a certificate using certreq using its Serial Number is as follows:
• An example to renew a certificate and generate a new key using certreq with its Serial Number is as follows:
Enrollee can request cert for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Client Authentication/Smart Card Logon EKU)
• We can escalate to higher domain privileges using ESC1 when the following conditions are present on a template:
Smart Card Logon --> 1.3.6.1.4.1.311.20.2.2/PKINIT authentication --> 1.3.6.1.5.2.3.4/Client Authentication --> 1.3.6.1.5.5.7.3.2 EKU is enabled for AD Authentication.
Enrollment Rights are enabled for a user that we control.
ENROLLEE_SUPPLIES_SUBJECT attribute is enabled: allows the certificate requestor to specify any subjectAltName (SAN) to request a certificate as any user including a Domain or Enterprise Administrator.
• Target that user(s) that are required to complete goals of your operation or assessment. Domain Admin logons are more susceptible to detection.
• Because of the CBA patch in Full Enforcement mode in the lab, when a request for ENROLLEE_SUPPLIES_SUBJECT certificate for an alternate user is made, the SID within the szOID_NTDS_CA_SECURITY_EXT extension is checked against the SID of the target user.
• Standard ESC1 abuse would break if there is no match with the SID of the target user.
• Certify has incorporated a specific Pull Request with the /sidextension argument, and Certipy too has a Pull Request implementing the -extensionsid argument.
• These versions of Certify/Certipy build the szOID_NTDS_CA_SECURITY_EXT extension with a supplied SID to include it with a certificate request for a template with ENROLLEE_SUPPLIES_SUBJECT flag enabled.
• An example to abuse ESC1 bypassing the CBA patch using Certify is as follows:
Enrollee can request cert for ANY user (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT + Any Purpose EKU or no EKU)
• ESC2 is very similar to the ESC1 abuse in which the following conditions must be met on a template:
Any Purpose EKU --> 2.5.29.37.0 or no EKU is is enabled for AD Authentication.
Enrollment Rights are enabled for a user that we control.
ENROLLEE_SUPPLIES_SUBJECT attribute is enabled.
• The only difference between ESC1 and ESC2 is the difference in EKUs.
• The Any Purpose EKU primarily allows an attacker to get a certificate for any purpose like Client Authentication, Server Authentication, Code Signing, etc.
• A certificate with no EKUs (SubCA certificate) can be abused for any purpose as well. It could also be used to sign new certificates.
• An example to abuse ESC2 (Any Purpose EKU) bypassing the CBA patch using Certify is as follows:
Request an enrollment agent certificate (Application Policy - Certificate Request Agent) and use it to request a cert on behalf of ANY user (Certificate Request Agent EKU)
For ESC3 we require 2 certificate templates with the following configuration:
• Template 1: Provides Enrollment Agent Certificate
Certificate Request Agent EKU --> 1.3.6.1.4.1.311.20.2.1 is enabled.
Enrollment Rights are enabled for a user that we control.
• Template 2: Allows Enrollment Agent Certificate to use on-behalf-of
Client Authentication EKU --> 1.3.6.1.5.5.7.3.2 is enabled.
Application Policy Issuance Requirement with Authorized Signatures Required enabled and set to 1 along with Certificate Request Agent EKU enabled.
Enrollment Rights are enabled for a user that we control.
• The Certificate Request Agent EKU aka Enrollment Agent allows a principal to request a certificate on behalf of another user.
• We can enroll in such a template that has the Certificate Request Agent EKU set (Template 1) to receive an Enrollment Agent Certificate.
• Use the Enrollment Agent certificate to enroll in a template (Template 2) on behalf of another user:
Vulnerable ACLs (GenericWrite) over AD CS Certificate Templates
• Like so many other things in Windows world, certificate templates are securable objects - they have ACLs.
• A certificate template that has overly permissive ACLs can be abused to modify security settings of the template to introduce misconfigurations like ESC1, ESC2, ESC3 etc. - this is ESC4!
• The following rights are critical to abuse:
Owner - Full Control
FullControl - Full Control
WriteOwner - Modify Owner for grant Full Control
WriteDacl - Modify access control for grant Full Control
WriteProperty - Edit any properties
• If we have WriteProperty or equivalent privileges over a template, some example commands to configure the ESC1 vulnerability over it using StandIn:
ENROLLEE_SUPPLIES_SUBJECT:
Certificate-Enrollment Permission:
Client Authentication EKU:
• We can also abuse ESC4 using a few other EKUs other than the Client Authentication EKU.
Smart Card Logon (OID: 1.3.6.1.4.1.311.20.2.2)
PKINIT Client Authentication (OID: 1.3.6.1.5.2.3.4)
Any Purpose (OID: 2.5.29.37.0)
No EKU
• By configuring the Smart Card Logon EKU, we can impersonate any user by enrolling for a smartcard logon certificate for that user.
• If smartcards are not in used in the target environment, we can use virtual smartcards to authenticate.
• We can use the SmartCardLogon EKU to abuse ESC1, ESC2, ESC3 etc.
• StandIn and Certipy only allows adding the Client Authentication EKU for ESC1 abuse.
• An example for SmartCardLogon ESC4 Abuse using CertifyKit’s /alter option is as follows:
Poor Access Control (GenericWrite) on CA Server Computer Object
• Overly permissive ACLs on privileged AD CS objects like the CA server computer object, AD CS Containers is ESC5.
• Some possibilities of compromise include:
Compromising the CA server's computer object using a technique such as RBCD/Shadow Credentials to gain admin access.
ACLs misconfigured for a descendant AD object (the Certificate Templates container, Certification Authorities container, the NTAuthCertificates object) allowing for Domain Persistence.
The CA server’s RPC/DCOM server to configure AD CS misconfigurations for later abuse.
• Compromising the CA server allows to control PKI and maintain domain persistence.
• Sample command to abuse RBCD (Resource-based Constrained Delegation) to gain admin access to a CA is as follows:
• Once we have admin access on the CA server, some possibilities for further abuse:
(Mis)Configure templates to setup the previously described template ACL attacks like ESC4 (DPERSIST3).
Forge certificates by stealing and using the RootCA to perform a Golden Cert Attack (DPERSIST1)
Vulnerable Certificate Authority Access Control Roles (ManageCA and ManageCertificate)
• Like other Securable Objects, CA may also have overly permissive ACL.
• In ESC7, a low privilege user is granted the ManageCA (CA Administrator) and ManageCertificates (Certificate Manager) rights over the CA.
• These permission allow us to accomplish the following:
ManageCA: allows a user to change the CA’s configuration to turn on SAN (Subject Alternative Name) to all the templates enabling the EDITF_ATTRIBUTESUBJECTALTNAME2 attribute allowing for the ESC6 attack path (fixed).
ManageCertificates: allows a user to issue certificates that are pending approval. We can approve such certificates using the ManageCA rights.
• If we don’t have the ManageCertificates right, we can just add ourselves as a new officer using existing ManageCA rights (An officer is a user with the ManageCertificates rights).
• Since the Certificate-based Authentication (CBA) patches are installed in the lab, the normal ESC6 attack using ManageCA rights can’t be used (because of strong certificate mapping checks).
• However, two alternate attack paths are still applicable to bypass the CBA patch in FullEnforcement:
Abusing SubCA template to approve a failed request using ManageCertificates rights (ESC7.1): https://www.tarlogic.com/blog/ad-cs-esc7-attack
Abusing CRL Distribution Points (CDPs) and using them to deploy SYSTEM webshells to CA servers respectively (ESC7.2): https://www.tarlogic.com/blog/ad-cs-manageca-rce/
• An example command to abuse ESC7.1 with Certify to approve a failed request (bypassing the CBA patch using ManageCertificate rights) is as follows:
• If we don’t have the ManageCertificates right, we can just add ourselves as a new officer using existing ManageCA rights with certipy as follows:
• If the SubCA template too isn't enabled, we can enable it using existing ManageCA access rights with certipy as follows:
NTLM Relay ANY domain computer to AD CS HTTP Endpoints
• AD CS enables users and computers to enroll using HTTP(S) endpoints through multiple server roles like -
HTTP - Web Enrollment (HTTP)
HTTPS - Certificate Enrollment Web Service (CES), Certificate Enrollment Policy Web Service, Network Device Enrollment Service (NDES).
• The web enrollment interfaces used by the above roles are vulnerable to NTLM relay attacks in their default configurations. We target the web enrollment interface found at: http://cb-ca.cb.corp/certsrv/certsnsh.asp
• We can coerce NTLM authentication from the target machine account to our listener and relay it to the vulnerable web interface to request a certificate from a template that allows domain computer enrollment and client authentication (like the default Machine template or Domain Controller Authentication when targeting DC).
• We can then use the certificate to request a TGT or retrieve its NTLM hash (UnPAC- The-Hash/THEFT5).
• Since the latest anti-PetitPotam Microsoft Patches (disabled coercion over WebDAV) and Spool Sample Patches (Windows Print Spooler Vulnerability) it has become harder to coerce authentication to relay using tools like SpoolSample/PetitPotam.
• However, it is possible to use tools like Coercer to coerce authentication using alternate new methods. An example to abuse ESC8 using Coercer is as follows:
NTLM Relay ANY domain computer to AD CS ICertPassage Remote Protocol (ICPR) RPC Endpoints
• This technique is similar to ESC8 except that we relay authentication over the RPC interface of the Certificate Authority instead of the HTTP one.
• RPC endpoints support NTLM authentication. The ICertPassage Remote Protocol (ICPR) can be used to request certificates for Windows Client Certificate Enrollment.
• If the IF_ENFORCEENCRYPTICERTREQUEST flag is set on a CA (that is packet privacy is enabled), relaying using RPC will not be possible. This flag is set by default on Windows Server 2012 and higher.
• The flag may be removed for backward compatibility for older Windows clients.
• As in ESC8, we will be using Coercer to coerce authentication using alternate methods to bypass the WebDAV and latest anti-PetitPotam patches.
• We will also be using a specific forkof Certipy and impacket to perform the ESC11 abuse.
• Sample commands for ESC11 abuse are as follows:
Forge ANY domain certificate using stolen CA Root certificate and private keys
• Once we have local admin rights on the CA (e.g using misconfigured ACLs), we can forge valid user/computer certificates by stealing and using the RootCA certificate and private key.
• This is also called the Golden Cert attack and is quite similar to the Golden Ticket Attack (steal KRBTGT hash).
• To maintain Domain Persistence, the Golden Cert attack is relatively new and is a good alternative to the more heavily fingerprinted Golden Ticket attack.
• Two forests can be configured to share the same CA for Cross Forest Certificate Enrollment using a bidirectional cross forest trust. In such a case the RootCA certificate is added to the target forest sharing the source forest CA.
• Only the RootCA certificate needs to added, but careless handling results in storing the RootCA along with the private key.
• We can add a rogue self-signed CA certificate to the NTAuthCertificates container (DPERSIST2). It can be abused to forge certificates for any domain user (DPERSIST1).
• If we manage to compromise a RootCA or add a self-signed CA certificate and private key pair, it is possible to forge certificates as mentioned in DPERSIST1 | DPERSIST2 to escalate privileges or persist.
• Hence, make sure to audit CA certificates in all AD CS containers.
Backdoor CA server using malicious misconfigurations like ESC4 that can later cause a domain escalation
• It is possible to maintain Domain Persistence by configuring vulnerable templates (ESC4) after compromising a CA.
• Add WriteOwner permission to a target template for a principal under our control. We can then reconfigure it (ESC4) to other misconfigurations such as ESC1, ESC2, ESC3 etc.
• We can then abuse this template in future to execute any of the techniques and get DA or EA privileges on-demand!
• "Azure Certificate-based Authentication is a method used to authenticate users or services in Microsoft Azure using digital certificates in which, instead of using traditional username and password authentication, the user or service is required to provide a digital certificate that has been signed by a trusted Certificate Authority."
• If we manage to compromise a trusted Certificate Authority (AD CS CA or any 3rd Party CAs) that is trusted by an Azure AD Environment, we can forge certificates and impersonate any user in the target Azure AD tenant.
• In AD CS environments, CBA can be used to authenticate in Active Directory using only a Certificate without any password (if MFA isn’t enabled). Azure AD Certificate- based Authentication works similarly.
• With a compromised Root CA trusted by the target Azure AD, we can forge a certificate for any user that is a part of CBA.
• We can use the certificate for CBA and persist in Azure AD as long as the certificate does not expire.
