growtika UyvnmroVRW4 unsplash

Active Directory’s Real Weak Point Isn’t Code but Configuration

Most conversations about Active Directory security start with patching. Apply the update, close the hole, move on. But some of the most damaging attack paths in AD environments don’t come from unpatched code at all, they come from how the system is configured by default, and how those defaults quietly clash with newer security features. Nothing illustrates this better than looking at the CVE-2022-26923 vulnerability explained in the context it actually occurred: not as a coding flaw, but as a configuration mismatch between Active Directory Certificate Services and the way Windows maps certificates to accounts.

Understanding this case matters beyond the specific bug. It’s a useful lens for thinking about why Active Directory environments keep getting compromised even when organizations are diligent about patch management.

What CVE-2022-26923 Actually Involves

CVE-2022-26923 is a privilege escalation vulnerability affecting Active Directory Certificate Services (AD CS), the role that issues digital certificates used for authentication inside a Windows domain. Microsoft addressed it in the May 2022 Patch Tuesday release, and it was documented publicly by security researcher Oliver Lyak, who also built the Certipy tool used to explore AD CS attack paths.

The core issue centers on how a certificate gets tied to an Active Directory identity. When a certificate is used to authenticate, the domain controller has to map that certificate back to a specific user or computer account. One of the attributes historically used in that mapping process is the DNS hostname of a machine account. The problem is that a standard, low-privileged domain user is normally allowed to create new computer accounts in a domain, a default AD behavior that has existed for decades, and that user also has the ability to modify certain attributes on the computer account they just created, including its DNS hostname.

With the CVE-2022-26923 vulnerability explained step by step, the attack sequence becomes clearer: 

  • A low-privileged user creates a new computer account, which AD permits by default through the “add workstations to domain” right.
  • The user then changes the DNS hostname attribute on that new machine account to match the hostname of an existing, higher-privileged machine, such as a domain controller.
  • The user requests a certificate for that computer account through AD CS.
  • Because the certificate mapping process trusts the DNS hostname attribute, the resulting certificate can be used to authenticate as the impersonated machine.
  • With a certificate that authenticates as a domain controller, the attacker can extract credential material and move toward full domain compromise.

None of these steps require exploiting a memory corruption bug or bypassing an access control list through unintended code execution. Each step uses a legitimate AD capability, applied in a sequence the system wasn’t designed to anticipate.

Why This Is a Configuration Problem, Not a Code Problem

It’s worth pausing on that distinction, because it changes how defenders should think about risk. A code vulnerability usually has a clear lifecycle: a flaw exists in software, a patch is released, the flaw is closed. CVE-2022-26923 does have a patch, Microsoft updated how certificate mapping validates identity, adding stronger mapping checks tied to a security identifier rather than relying solely on the DNS hostname.

But the underlying condition that made the attack possible, ordinary users being allowed to create computer accounts and edit their attributes, is a decades-old default setting, not a bug. Many organizations still run with that default in place because changing it can affect legitimate provisioning workflows, and because it was never flagged as risky in isolation. The vulnerability only became dangerous when combined with the assumptions AD CS made about hostname-based certificate mapping.

This is the recurring pattern behind many serious Active Directory compromises. Individually reasonable settings, permissive account creation rights, legacy authentication protocols, broad delegation permissions, weak certificate templates, become dangerous only when chained together. Security researchers who study AD attack paths, including those behind tools like BloodHound, have long pointed out that most real-world domain compromises rely on combining several “normal” misconfigurations rather than a single dramatic exploit.

Where This Fits in the Broader Certificate Services Landscape

AD CS has become a recurring source of privilege escalation research since 2021, when a body of work known informally as the “Certified Pre-Owned” research catalogued a range of certificate template and enrollment misconfigurations that allow privilege escalation. CVE-2022-26923 sits alongside that research as one of the more severe findings because it didn’t require an administrator to have misconfigured a certificate template poorly — it exploited a mapping assumption baked into how AD CS interacted with standard domain permissions.

Microsoft’s response reflected the scale of the issue. The May 2022 update introduced stronger certificate mapping enforcement, and Microsoft later moved toward requiring stricter mapping by default in subsequent updates, phasing out weaker compatibility modes over time. That phased rollout itself signals how disruptive tightening these defaults can be for organizations that depend on legacy mapping behavior.

For defenders, a few practical takeaways follow directly from this case:

  • Audit who can create computer accounts in the domain, and reduce that permission where it isn’t operationally necessary.
  • Review AD CS certificate templates for overly permissive enrollment rights or subject name flexibility.
  • Apply the May 2022 security updates and monitor for Microsoft’s guidance on strong certificate mapping enforcement timelines.
  • Treat certificate-based authentication with the same scrutiny given to password and Kerberos-based authentication paths.

Final Analysis

The CVE-2022-26923 vulnerability explained in full context isn’t really a story about a single flawed function in Windows code. It’s a story about how default permissions, legacy compatibility settings, and newer authentication mechanisms can interact in ways nobody explicitly designed. Active Directory has accumulated decades of default behaviors, many of which made sense in isolation when they were introduced. The risk today isn’t that these defaults are broken, it’s that they were never re-evaluated against each other as the environment around them changed.

Patching closes the specific hole. But the deeper lesson from CVE-2022-26923 is that configuration review deserves the same ongoing attention that vulnerability management gets. Code gets fixed once. Configuration has to be checked continuously, because it’s rarely one setting that causes the breach, it’s the combination.

About The Author