How to check for Active Directory Certificate Services misconfigurations

I read with interest about Active Directory Certificate Services (AD CS) misconfigurations and the risks they present to my network. Security firm SpecterOps have developed an audit toolkit, written in PowerShell and dubbed PSPKIAudit, and will release two offensive tools, Certify and ForgeCert, in early August during the upcoming Black Hat USA 2021 conference. However, I wanted to get a head start to see if my domain was vulnerable to attacks that could result in account or domain takeover.

Steps to find AD CS misconfigurations

I followed these steps:

1. With an elevated PowerShell prompt, install the Remote Server Administration Tools Certificate Services and Active Directory features with the command: Get-WindowsCapability -Online -Name "Rsat.*" | where Name -match "CertificateServices|ActiveDIrectory" | Add-Windows
2. Download PSPKIAudit and extract it to the folder PSPKIAudit with the commands: cd PSPKIAudit Get-ChildItem -Recurse | Unblock-File
3. Import PSPKIAudit with the command: Import-Module .PSPKIAudit.psm1 You may need to add the -Verbose parameter as you might receive this message: “WARNING: The names of some imported commands from the module ‘PSPKIAudit’ include unapproved verbs that might make them less discoverable.” To find the commands with unapproved verbs, run the Import-Module command again with the -Verbose parameter. PS C:PSPKIAudit> Import-Module .PSPKIAudit.psm1 -Verbose For a list of approved verbs, type “Get-Verb”. You will then be alerted to verbs that are less discoverable.
4. Run this command or export it to a .csv file to review your organization: Invoke-PKIAudit [-CAComputerName CA.DOMAIN.COM | -CAName X-Y-Z]  It performs auditing checks for your existing AD CS environment, including enumerating various certificate authority (CA) and certificate template settings. Or you can merely type in Invoke-PKIAudit and review the output provided.

How to remove unneeded certificate authority values

The output will also inform you if you have any leftover CA values that are no longer in your network. In my case, it flagged two servers that used to be in my Active Directory that provided certificate services in the network that were no longer in the network. These should be removed from the network as they no longer serve any purpose.

It then flagged that a CA for a server on my network has a potentially vulnerable template. The good news in my case was that the main domain certificate had no issues. Rather other certificate templates for specialty servers had the issues. Two of these templates were ESC1 – Misconfigured Certificate Templates:

Susan Bradley

To fix this:

1. Right-click the affected certificate template in the Certificate Templates Console (certtmpl.msc)
2. Select “Properties”.
3. Remove the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag via “Subject Name” by unchecking “Supply in Request”. This prevents arbitrary SAN specification in the CSR. Unless alternate names are needed for this template, this is probably the best fix.

   Susan Bradley

4. Remove the “Client Authentication” or “Smart Card Logon” EKUS via “Extensions” -> “Application Policies”. This prevents domain authentication with this template.

   Susan Bradley

5. Enable “CA Certificate Manager Approval” in “Issuance Requirements”. This puts requests for this template in the “Pending Requests” queue that must be manually approved by a certificate manager.

   Susan Bradley

6. If any automation is connected with this template and you enable CA certificate manager approval, you may impact the automation and scripting in your network. Review the impact accordingly.
7. Enable “Authorized Signatures” in “Issuance Requirements”, which forces CSRs to be co-signed by an enrollment agent certificate. This removes the ability for low-privileged users from enrolling in this template via “Security” and removing the appropriate enroll privilege. Again, review for automation or scripting that is reliant on this certificate that may impact your network operations.

Certificates are a key part of a network infrastructure. With a CA, you can provide authentication and clients can request these certificates. Start by treating certificate authority servers in the same category as domain controllers. They should be limited as to who accesses them and what accounts they use to log in. If a certificate has been used maliciously in a breach, not only do you need to wipe the workstation and rebuild it but trace back all certificates issued to the user and revoke them in AD CS.

If you feel your CA server has been compromised, consider your certificate authority compromised as well. It’s recommended to follow Microsoft’s guidance to rebuild and revoke all suspect certificates.

Bottom line, review your Active Directory Certificate Services infrastructure and take the time to review if your existing infrastructure has been deployed using the current recommended security guidance.