Yaamlabs
Case study 06

Domain takeover through a certificate template

Financial services

A large financial enterprise asked us to assess its internal network from a standard low-privilege starting point: a single ordinary account, no special access, the position an attacker reaches after one foothold.

Network penetration test, Financial enterprise, severity CRITICAL, reported 2025

At a glance

  • Challenge. A certificate template let the enrollee name the subject, so an ordinary account could request a certificate speaking for the most trusted identity.
  • Approach. We worked quietly below lockout thresholds, confirmed the naming convention, mapped over-privileged accounts and audited the certificate templates.
  • Result. The template was constrained, the excess rights reduced and the password convention replaced, then the path was retested.
  • Impact. An attacker starting from one ordinary account could reach domain-level authority, and so control every account the directory governs.
  • Classification. CWE-269 Improper Privilege Management, MITRE ATT&CK: T1649 Steal or Forge Authentication Certificates. Component: Active Directory certificate template.

The challenge

The domain controllers were patched and the perimeter was sound. The weakness was not a missing update; it was a chain of ordinary conditions that were each acceptable on their own. A predictable account-naming and password convention. A service account with more certificate rights than its job required. A certificate template that let the requester choose who the certificate spoke for.

A public key infrastructure exists to answer one question with authority: is this identity who it claims to be. A template that lets the enrollee name the subject turns that authority against the directory, because a certificate is trusted precisely because the infrastructure issued it. The individual settings pass review because each one has a legitimate use. The combination is what grants a path from an ordinary account to the identity the whole domain trusts most.

None of it is visible from the endpoint list or a vulnerability scan. It is visible only when the certificate authority’s templates are read as configuration that grants authority, which is what they are.

Our approach

We worked the way an internal attacker does, deliberately quiet, staying below the thresholds that would trip account lockout or alert the operations centre, because a finding that only holds under laboratory conditions is not a finding.

The assessment moved in stages:

  • Confirm the naming and password convention, and how far a small, slow set of guesses reached across the directory
  • Map which of the reachable accounts held rights they did not need, and where those rights led
  • Audit the certificate templates for the ability to name an arbitrary subject
  • Establish the shortest path from the entry account to domain authority, and stop at proof rather than impact

Delivered as the full path with each condition that made the next step possible, so remediation could break the chain at more than one point rather than patch a single symptom.

From finding to fix

  1. Started from one low-privilege account
  2. Found a permissive certificate template
  3. Reached domain-level authority
  4. Constrained the template, retested

The outcome

The vulnerable template was constrained so an enrollee can no longer name an arbitrary subject, the over-privileged rights were reduced to what the account’s function required, and the naming and password convention was replaced with enforced uniqueness and complexity. Each change breaks the chain independently, so no single reversion re-opens the path.

Detection for slow, low-volume credential guessing was added so a repeat of the entry step is visible. We retested the path after remediation. Reported as CRITICAL in 2025. Retest included in the engagement.

Check your own system

  • Audit certificate templates for any that let the enrollee supply the subject or an arbitrary alternative name.
  • Reduce service account certificate rights to what the account's function actually requires.
  • Enforce unique account names and strong passwords so a small, slow set of guesses gains no foothold.
  • Add detection for slow, low-volume credential guessing so a repeat of the entry step is visible.

Read more case studies, see Network Penetration Testing, or tell us about your system on the contact page.