A Beginner’s Guide to Auditing Active Directory Certificate Services with PSPKIAudit

By /

Active Directory Certificate Services (AD CS) represents one of the most critical—yet frequently overlooked—security components in enterprise networks. This comprehensive guide will teach you how to audit AD CS using PSPKIAudit, identify dangerous misconfigurations, and protect your organization from certificate-based attacks.

Table of Contents

Why AD CS Security Matters

Your Public Key Infrastructure (PKI) is the foundation of trust in your Active Directory environment. Certificates authenticate users, computers, and services across your network. When PKI is compromised, attackers can:

  • Impersonate any user, including domain administrators
  • Bypass multi-factor authentication
  • Maintain persistent access that survives password resets
  • Move laterally across your network undetected

Despite these risks, many organizations focus security efforts exclusively on Active Directory while neglecting their certificate infrastructure. This oversight creates dangerous blind spots that sophisticated attackers routinely exploit.

Understanding Common AD CS Vulnerabilities

PSPKIAudit detects specific “ESC” (Escalation) vulnerabilities first documented in SpecterOps’ groundbreaking research paper “Certified Pre-Owned”. Understanding these vulnerability categories is essential for effective PKI security.

ESC1: Misconfigured Certificate Templates

What it is: Certificate templates that allow requesters to specify their own subject name without proper controls.

The risk: An attacker can request a certificate claiming to be a domain administrator, then use that certificate to authenticate as that administrator.

Real-world impact: Direct privilege escalation from standard user to domain admin.

ESC2: Overly Permissive Auto-Enrollment

What it is: Certificate templates configured for automatic enrollment to overly broad security groups.

The risk: Users automatically receive certificates they shouldn’t have access to.

Real-world impact: Unintended privilege grants that can be exploited for lateral movement.

ESC3: Enrollment Agent Template Abuse

What it is: Certificate templates that allow users to act as enrollment agents without proper authorization controls.

The risk: Attackers can request certificates on behalf of other users, including high-privilege accounts.

Real-world impact: Complete identity impersonation across the domain.

ESC4: Vulnerable Certificate Template Permissions

What it is: Certificate templates where low-privileged users have “Enroll” or “Autoenroll” permissions.

The risk: Unauthorized users can issue themselves certificates with elevated privileges.

Real-world impact: Privilege escalation through self-service certificate enrollment.

ESC5: Vulnerable PKI Object Permissions

What it is: Excessive write permissions on PKI-related objects in Active Directory.

The risk: Attackers can modify PKI configuration to introduce new vulnerabilities.

Real-world impact: Persistent backdoors in your certificate infrastructure.

ESC6: Arbitrary Subject Alternative Name (SAN)

What it is: The Certificate Authority allows users to specify any Subject Alternative Name in certificate requests.

The risk: Any user can request a certificate for their own account but include a SAN for a domain administrator.

Real-world impact: Complete domain compromise through administrator impersonation.

Critical indicator: The EDITF_ATTRIBUTESUBJECTALTNAME2 flag is enabled on the CA.

ESC7: Vulnerable CA Server Permissions

What it is: Excessive permissions on the Certificate Authority object itself.

The risk: Attackers can become CA managers and control the entire PKI.

Real-world impact: Complete certificate infrastructure compromise.

ESC8: NTLM Relay via Web Enrollment

What it is: Certificate Authority web enrollment interfaces vulnerable to NTLM relay attacks.

The risk: Attackers can relay captured credentials to request certificates.

Real-world impact: Credential theft converted to persistent certificate-based access.

For detailed technical analysis of these vulnerabilities, review the SpecterOps blog post summary.

Prerequisites and Installation

System Requirements

You don’t need direct access to your Certificate Authority servers to perform audits. PSPKIAudit runs from any domain-joined workstation that meets these requirements:

  • Operating System: Windows 10/11 or Windows Server 2016+
  • PowerShell: Version 5.1 or higher
  • Domain Access: Standard domain user account with read permissions on the CA
  • RSAT Tools: Remote Server Administration Tools for Certificates and Active Directory

Step-by-Step Installation

Open an administrative PowerShell prompt and follow these steps:

1. Install Required RSAT Features

# Install Certificate Services management tools
Add-WindowsCapability -Online -Name Rsat.CertificateServices.Tools~~~~0.0.1.0

# Install Active Directory PowerShell module
Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

2. Install the PSPKI Dependency Module

PSPKIAudit requires the PSPKI module from the PowerShell Gallery:

Install-Module -Name PSPKI -Force

3. Download PSPKIAudit

Visit the PSPKIAudit GitHub releases page and download the latest release ZIP file.

4. Extract and Unblock Files

# Extract to your preferred location
Expand-Archive -Path "C:\Downloads\PSPKIAudit.zip" -DestinationPath "C:\Tools\PSPKIAudit"

# Navigate to the extracted directory
cd C:\Tools\PSPKIAudit

# Unblock all PowerShell files to comply with execution policy
Get-ChildItem -Recurse | Unblock-File

Verify Installation

Confirm everything is properly installed:

# Import the module
Import-Module PSPKIAudit

# Check available commands
Get-Command -Module PSPKIAudit

If the module imports without errors, you’re ready to begin auditing.

Running Your First Automated Audit

Basic Automated Scan

The Invoke-PKIAudit command performs comprehensive automated analysis of your AD CS environment:

# Import the module in your current session
Import-Module PSPKIAudit

# Run the automated audit
Invoke-PKIAudit

This command automatically discovers all Certificate Authority servers registered in Active Directory and analyzes each one for known misconfigurations.

Targeting Specific Certificate Authorities

For environments with multiple CAs, target specific servers:

# Target by computer name
Invoke-PKIAudit -ComputerName "CA-SERVER-01"

# Target by CA name
Invoke-PKIAudit -CAName "Enterprise-Root-CA"

# Target multiple CAs
Invoke-PKIAudit -ComputerName "CA-SERVER-01", "CA-SERVER-02"

Interpreting Audit Results

Clean Results

If no vulnerabilities are detected, you’ll see output where the Misconfiguration column is empty for all Certificate Authorities. This indicates the automated scan didn’t find any of the common, known ESC vulnerabilities.

However, this doesn’t guarantee complete security—manual analysis may still reveal subtle issues.

Vulnerability Detected

When PSPKIAudit identifies a vulnerability, it displays:

  • CA Name: The affected Certificate Authority
  • Misconfiguration Type: The specific ESC vulnerability (e.g., ESC4)
  • Affected Object: The template, permission, or configuration causing the issue
  • Details: Additional context about the finding

Example: ESC4 Vulnerability Found

CA Name: CORP-CA-01
Misconfiguration: ESC4
Template: HighPrivilegeTemplate
Issue: Authenticated Users have Enroll permissions

Verifying ESC4 Findings Manually

When PSPKIAudit reports an ESC4 vulnerability, verify the finding:

  1. Open Certificate Templates Console: Press Win + R, type certtmpl.msc, press Enter
  2. Locate the Template: Find the template named in the audit results
  3. Check Permissions: Right-click → Properties → Security tab
  4. Examine ACLs: Look for overly broad groups like:
    • Authenticated Users
    • Domain Users
    • Domain Computers
  5. Confirm the Risk: If these groups have “Enroll” or “Autoenroll” permissions checked, the vulnerability is confirmed

Why this matters: Any member of these broad groups can enroll for the certificate, potentially gaining privileges they shouldn’t have.

Exporting Results for Documentation

Save audit results for compliance documentation or tracking remediation progress:

Invoke-PKIAudit | Export-Csv -Path "C:\Audits\PKI-Audit-$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation

Advanced Manual Analysis Techniques

Automated scans detect known vulnerability patterns, but manual analysis reveals subtle weaknesses, unusual patterns, and emerging threats that don’t fit standard signatures.

Examining the Certificate Database

The Get-CertRequest command queries the CA’s database directly, allowing you to examine every certificate ever issued:

Get-CertRequest

Performance tip: In large environments with 10,000+ certificates, always export to CSV for analysis:

Get-CertRequest | Export-Csv -Path "C:\Audits\All-Certificates.csv" -NoTypeInformation

Critical Manual Analysis: Detecting ESC6

ESC6 (arbitrary SAN) is one of the most dangerous vulnerabilities because it allows any user to impersonate any other user in your domain.

How to Detect ESC6

Look for certificates where the requester differs from the Subject Alternative Name (SAN):

# Get all certificates
$certs = Get-CertRequest

# Filter for certificates with SANs that don't match the requester
$certs | Where-Object { 
    $_.RequesterName -and 
    $_."User Principal Name" -and 
    $_.RequesterName -ne $_."User Principal Name"
}

Example of ESC6 Abuse

Requester: DOMAIN\mehdi
Subject Alternative Name: [email protected]

This pattern shows user “mehdi” successfully requested a certificate with a SAN for the domain administrator account—a clear indicator of ESC6 vulnerability.

Root Cause

This vulnerability exists when the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is enabled on the Certificate Authority. Check the flag status:

certutil -config "CA-SERVER\CA-Name" -getreg policy\EditFlags

If the output includes EDITF_ATTRIBUTESUBJECTALTNAME2, your CA is vulnerable to ESC6.

Attack Implications

With ESC6 enabled, attackers can:

  • Authenticate as any user via Kerberos
  • Bypass access controls by impersonating administrators
  • Access sensitive resources as privileged accounts
  • Create “golden certificates” for persistent access
  • Authenticate via LDAPS as any service account

Analyzing Certificate Request Origins

Understanding how certificates are requested helps identify unauthorized or suspicious enrollment activity.

Grouping by Request Process

# Get all certificate requests
$requests = Get-CertRequest

# Group by the process that submitted the request
$requests | Group-Object RequesterProcessName | Sort-Object Count -Descending

Expected vs. Suspicious Processes

Expected in production environments:

  • mmc.exe (Certificate snap-in)
  • certreq.exe (Standard certificate request tool)
  • sccm.exe or custom enrollment agents (if you use SCCM or other automation)

Suspicious in production environments:

  • certsrv (Web enrollment interface, unless specifically authorized)
  • powershell.exe or powershell_ise.exe (Ad-hoc manual requests)
  • Certify.exe (Penetration testing tool—clear indicator of potential attack)
  • Unknown executables from temp directories
  • Processes running from unusual paths

Red Flags for Security Teams

If you see certificate requests from:

  • Certify.exe: This is a well-known offensive security tool. Investigate immediately.
  • Web enrollment (certsrv): If your policy requires automated enrollment only, web requests may indicate unauthorized activity.
  • PowerShell: Unless you have authorized automation scripts, manual PowerShell requests deserve scrutiny.

Identifying Anomalous Certificate Validity Periods

Unusually long certificate lifetimes can indicate:

  • Misconfigured templates
  • Attempts to establish persistent access
  • “Golden certificate” creation for long-term compromise

Finding Long-Lived Certificates

# Find certificates valid for more than 3 years
Get-CertRequest | Where-Object { 
    $_.NotAfter -gt (Get-Date).AddYears(3) 
} | Select-Object RequesterName, NotBefore, NotAfter, CommonName

Best Practice Validity Periods

Microsoft recommends:

  • User certificates: 1 year
  • Computer certificates: 1-2 years
  • Root CA certificates: 10-20 years
  • Subordinate CA certificates: Half the parent CA’s lifetime

Certificates exceeding these guidelines warrant investigation.

Detecting Unauthorized Enrollment Agent Usage

Enrollment agents can request certificates on behalf of other users—a powerful privilege that must be strictly controlled.

Finding Enrollment Agent Certificates

Get-CertRequest | Where-Object { 
    $_.CertificateTemplate -like "*EnrollmentAgent*" 
} | Select-Object RequesterName, NotBefore, NotAfter

Verification Steps

For each enrollment agent certificate found:

  1. Verify the requester is an authorized enrollment agent
  2. Check if the requesting account still requires this privilege
  3. Confirm the certificate hasn’t been compromised
  4. Review certificates issued using this enrollment agent certificate

Analyzing Top Certificate Requesters

Identify accounts requesting unusually high numbers of certificates:

Get-CertRequest | Group-Object RequesterName | 
    Sort-Object Count -Descending | 
    Select-Object -First 20 Name, Count

Warning signs:

  • User accounts with hundreds of certificate requests
  • Service accounts requesting certificates for different subjects
  • Terminated employee accounts still requesting certificates
  • Guest or temporary accounts with certificate enrollment activity

Building a Sustainable PKI Security Program

PKI security isn’t a one-time project—it requires ongoing attention, monitoring, and improvement.

Establish Regular Audit Cadence

Weekly Tasks:

  • Run automated Invoke-PKIAudit scans
  • Review alerts for new certificate enrollments
  • Check for certificates with unusual SANs

Monthly Tasks:

  • Export and analyze certificate database (Get-CertRequest)
  • Review certificate request origins
  • Audit enrollment agent usage
  • Verify template permissions haven’t changed

Quarterly Tasks:

  • Comprehensive manual analysis
  • Review all certificate templates
  • Audit CA permissions and configuration
  • Update baseline documentation
  • Test incident response procedures

Create Baseline Documentation

Document the following:

  1. Approved Certificate Templates
    • Template names and purposes
    • Intended usage scenarios
    • Authorized enrolling groups
    • Validity periods and renewal processes
  2. Authorized Enrollment Agents
    • Account names and business justifications
    • Approval dates and reviewers
    • Scope of authority (which templates they can use)
  3. Expected Request Sources
    • Approved enrollment processes (MMC, certreq, automation tools)
    • Authorized service accounts
    • Legitimate enrollment locations (IP ranges, OUs)
  4. Security Contacts
    • PKI administrators
    • Security team escalation points
    • Incident response procedures

Implement Continuous Monitoring

Key Metrics to Track:

  • Number of certificates issued per day/week
  • Certificates with Subject Alternative Names
  • Certificate requests from unusual processes
  • Template modification events
  • CA configuration changes
  • Failed enrollment attempts

Alerting Priorities:

Critical (Immediate Response):

  • Certificates with SANs issued to unexpected accounts
  • Template permissions modified
  • CA configuration changes
  • Enrollment from offensive security tools (Certify.exe)

High (Within 24 Hours):

  • Unusual spike in certificate requests
  • Enrollment agent certificates issued
  • Certificates with excessive validity periods
  • Requests from unauthorized processes

Medium (Within 1 Week):

  • New certificate templates created
  • Changes to template ACLs
  • Unusual enrollment patterns

Prioritizing Remediation

When vulnerabilities are identified, remediate based on severity and exploitability:

Critical Priority (Fix Immediately)

ESC6 – Arbitrary SAN:

# Disable the vulnerable flag on the CA
certutil -config "CA-SERVER\CA-Name" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

ESC8 – Web Enrollment NTLM Relay:

  • Disable web enrollment if not required
  • Implement Extended Protection for Authentication (EPA)
  • Require certificate-based authentication for web enrollment

High Priority (Fix Within Days)

ESC1 – Misconfigured Templates:

  • Remove “Supply in request” option from subject name configuration
  • Configure proper subject name requirements

ESC3 – Enrollment Agent Abuse:

  • Review all enrollment agent templates
  • Restrict enrollment agent usage to authorized accounts
  • Implement Application Policies restrictions

ESC4 – Template Permission Issues:

  • Remove Enroll permissions from overly broad groups
  • Grant permissions only to specific, authorized security groups

ESC7 – CA Permission Issues:

  • Audit CA security permissions
  • Remove unnecessary ManageCA and ManageCertificates rights

Medium Priority (Fix Within Weeks)

ESC2 – Auto-Enrollment Issues:

  • Review auto-enrollment configurations
  • Restrict auto-enrollment to appropriate groups

ESC5 – PKI Object Permissions:

  • Audit Active Directory PKI container permissions
  • Remove unnecessary write permissions

Measuring Program Effectiveness

Track these metrics to demonstrate security improvement:

  • Number of high/critical vulnerabilities over time
  • Average time to remediate findings
  • Percentage of templates with proper ACLs
  • Reduction in certificates with unusual attributes
  • Coverage of automated monitoring

Additional Resources

Essential Reading

Foundational Research:

Attack Path Visualization:

Microsoft Official Documentation

Security Hardening:

Tools and Software

Auditing Tools:

Alternative Assessment Tools:

  • Certipy – Python-based AD CS enumeration and abuse tool
  • Certify – C# tool for AD CS reconnaissance

Community Analysis and Guides

Practical Guides:

Key Takeaways

Your PKI infrastructure deserves the same security attention as Active Directory itself. Certificate-based attacks bypass traditional security controls, evade standard monitoring tools, and provide persistent access that survives password resets.

Remember:

  1. Start with automated scans using PSPKIAudit to identify known vulnerabilities quickly
  2. Perform manual analysis regularly to detect subtle misconfigurations and emerging threats
  3. Document your baseline to track changes and measure improvement
  4. Monitor continuously rather than relying on point-in-time assessments
  5. Prioritize remediation based on exploitability and business impact
  6. Treat PKI security as an ongoing program, not a one-time project

The investment in regular PKI auditing far outweighs the cost of a certificate-based compromise, which can undermine trust across your entire domain and provide attackers with persistent, difficult-to-detect access.

Begin your PKI security journey today with PSPKIAudit’s automated scans, develop expertise through manual analysis, and build sustainable processes that protect this critical infrastructure component.

About This Guide: This comprehensive tutorial was created to help security professionals and system administrators understand and secure their Active Directory Certificate Services infrastructure. For questions, corrections, or contributions, visit the PSPKIAudit GitHub repository.

Last updated: January 2026

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top