Active Directory Penetration Testing Case Study: A Legacy Certificate Template Exposed a Privilege Escalation Path

This grey box internal penetration test started from a standard domain account and examined Active Directory and Active Directory Certificate Services (AD CS) at an industrial distributor. It found a legacy certificate template that a broad user group could still use to request authentication certificates with requester-supplied identity information, and a controlled test in an isolated copy of the environment confirmed authentication as a prepared account with administrative privileges.

Engagement	Details
Scope	Internal network, Active Directory, and Active Directory Certificate Services
Approach	Grey box, starting from a standard domain account
Effort	8 tester-days, plus 2 tester-days for retesting
Retest	Two weeks later: confirmed the demonstrated path was closed and that valid certificate enrollment and authentication workflows still worked

Key takeaways

• No password was cracked and no encryption was broken: the issue was which identities the certificate infrastructure allowed a requester to represent.
• The template, left behind by a retired access solution, was still published, allowed requester-supplied identity information, and issued authentication certificates without additional approval.
• Privileged authentication was demonstrated only in an isolated copy, and the report did not claim that a production domain controller had been compromised.
• The template was removed from publication, and two weeks later the retest confirmed the demonstrated path was closed.

What did the client need tested?

An industrial distributor commissioned an internal penetration test after reviewing administrator accounts and strengthening endpoint protection.

The starting position was a standard domain account with access to the employee network segment. The organization wanted to understand how far an attacker could progress from that position without knowing an administrator’s password.

The scope included one domain, selected servers, and Active Directory Certificate Services. Industrial control systems, social engineering, large-scale password cracking, and disruptive activity were excluded.

Any validation requiring a privileged identity would take place in an isolated copy of the relevant environment, rather than against production systems.

What did the Active Directory penetration test find?

The initial review covered delegated permissions, administrative relationships, and certificate-service configuration.

A certificate template left behind by a retired access solution stood out. It was still published, a broad user group retained enrollment permissions, and the configuration allowed requester-supplied identity information.

Certificates issued through the template could be used for authentication, and issuance did not require an additional approval.

On the second day of testing, the relevant configuration was reproduced in the isolated environment, including its certificate-to-account mapping behavior. A controlled test confirmed authentication as a prepared account with administrative privileges.

No password was cracked and no encryption was broken. The issue was which identities the certificate infrastructure allowed a requester to represent.

The report explicitly separated the unsafe configuration confirmed in the organization’s domain from the privileged authentication demonstrated in its isolated copy. It did not claim that a production domain controller had been compromised.

Why didn’t earlier reviews and the network scanner catch it?

Previous reviews focused on patching, endpoint protection, and membership of administrative groups.

The certificate infrastructure was treated primarily as a supporting service. It had not been assessed as a system capable of issuing authentication credentials for privileged identities.

The existing network scanner did not evaluate the necessary combination of template settings, enrollment permissions, and authentication behavior. Specialized AD CS assessment tools could have highlighted the configuration, but they had not been part of the earlier review.

How was the certificate template fixed and retested?

The organization confirmed that the template was no longer needed and removed it from publication.

The remaining templates were reviewed for excessive enrollment permissions and unnecessary requester control over identity information. Certificates generated during the demonstration were revoked.

Available issuance logs were examined for suspicious activity. The absence of suspicious entries was not presented as proof that the weakness had never been exploited.

Changes were introduced in stages to avoid disrupting legitimate certificate-dependent services.

Two weeks later, retesting confirmed that the demonstrated path was closed. Valid certificate enrollment and authentication workflows were also tested to ensure that the remediation had not interrupted normal operations.

Each finding’s retest status is recorded in the report, as in section 7 of our sample penetration test report.

Key takeaway

A review of privileged access must include systems that can issue credentials for privileged identities, not just the accounts and groups that already hold administrative permissions.

Need the same test for your Active Directory?

This engagement was a grey box internal test of one domain, selected servers, and AD CS: 8 tester-days, plus 2 tester-days for retesting. It sits within our wider network and infrastructure penetration testing. For the outside-in view, our external penetration testing case study shows how direct server access bypassed an SSO gateway.

Internal tests at Pentestica are quoted individually in tester-days; see how tester-days translate into a fixed price, or request a pentest quote with your domains, starting position, and any systems to exclude.