You built a proper PKI. I want to say that first, because it is rare enough that it deserves saying.

Somewhere around 2019 somebody finally got budget and did it right. Offline root, kept powered off in a safe. A subordinate issuing CA underneath it. Templates reviewed. Autoenrollment scoped. It is the architecture every consultant draws on a whiteboard and almost nobody gets funded, and you got it funded.

The thing you replaced was a single enterprise root CA that had been installed on a domain controller in 2016 by a contractor who is not answering emails. You migrated off it. You ran the removal wizard, the role came off cleanly, the server got powered down, and eventually somebody deleted the VM. The change ticket says decommissioned and the change ticket is not wrong.

Here is what I did on a Tuesday afternoon with a domain user account and no special rights at all:

certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example?cACertificate?base?objectclass=certificationAuthority"

Two certificates came back. One of them is your current issuing CA, which is correct. The other one is a CA that has not existed since 2019.

I did not need to be an administrator to read that. The Configuration partition is readable by every authenticated user in your forest, which is by design, because clients need to find this. So do I.

Understand what that object is. NTAuthCertificates is the list of CAs your domain controllers will accept certificate authentication from. It is not a record of history. It is not an inventory. It is a live authorization list, and your dead CA is still on it, and it has been for seven years.

It is also still in the Certification Authorities container next door, which is how it got into the Trusted Root store on every machine you own, and it is still there too. Both objects had to be deleted by hand. Neither was.

That is half of what I need. The other half is the key.

The key was never gone

You did not throw it away. Nobody throws it away. Throwing it away feels irresponsible, so instead there is a backup, and the backup is somewhere reasonable, and that is worse.

In your case it is a folder on a file share called PKI Migration 2019, which the infrastructure team created, used for six weeks, and never touched again. It contains the export a careful engineer made before running the removal wizard, exactly as the runbook told him to, because you do not uninstall a CA without a backup first. It is a p12 file. Next to it is the runbook. The runbook contains the password, because where else would you put it.

If it had not been there I would have looked at your backup sets, because a decommissioned CA server usually sits in retention long after the VM is gone, and a system state restore gives me the same material. I have opinions about backups being the softest copy of everything you own, and I have written them down before.

The point is that a private key does not get decommissioned. It gets copied.

What I do with it

Nothing that touches your infrastructure.

I do not submit a request. There is no CSR, no template, no enrollment right, no approval, no CA to talk to, and nothing on your network that observes any part of this. I take the old CA certificate and its key, and I sign a certificate myself, offline, on hardware you have never seen.

Since I am the one writing it, I decide what goes in it.

Subject: whichever account I want. There is no template constraining the subject, because there is no template. There is no enrollment permission, because there is no enrollment.

Extended key usage: client authentication.

The SID extension, OID 1.3.6.1.4.1.311.25.2, containing the real objectSid of a real Domain Admin. I know you tightened this. Your KDC has been in Full Enforcement since February 2025 and it is right to be. Full Enforcement asks whether the certificate carries the account's SID. This one does. I typed it. I am the certification authority, and a certification authority is a thing that asserts identity, and nobody checks the assertions of a CA you already told your domain controllers to trust.

CRL distribution point: none. There is no CA left to publish a CRL, so I do not give the validator anywhere to look. That is also why revocation is not your answer here. The certificate has a serial number I invented, it was never in any CA database, and there is no CA database anymore. You cannot revoke a row that does not exist.

Validity: I pick the dates. I gave it five years, which is more than I need, and I will come back to that.

Then I authenticate. PKINIT, forged certificate, Kerberos TGT for a Domain Admin. Your domain controller builds the chain, finds the issuer in NTAuth, finds a strong mapping, and issues the ticket. Every check passed. The domain controller was correct at every step.

Event 4768. Tuesday afternoon. Certificate issuer: a CA that was decommissioned before some of your current staff were hired.

Nobody looks at the issuer field. There is nothing in your SIEM that would know the difference.

Before I go. Sort your 4768 events by certificate issuer and find the ones that did not come from a CA you currently operate. There will be a small number of them and they will all be mine. One of them has a subject I filled in myself.

It says Hiro.

Hiro out.

If you are a defender, here is what just happened, plainly.

There is no ESC number on this one either. No template misconfiguration, no relay, no vulnerable enrollment right, no unpatched CA. There was no CA at all. Every component behaved exactly as designed, and the design says that a certificate signed by a key in NTAuthCertificates is a valid statement of identity. The failure was that a trust decision made in 2016 was never withdrawn in 2019.

This is DPERSIST1 in Certified Pre-Owned, by Will Schroeder and Lee Christensen at SpecterOps, June 2021. The tooling is ForgeCert from GhostPack, and Certipy's ca -backup and forge commands, which have carried a -sid flag for a while now specifically so that forged certificates satisfy strong mapping. SpecterOps models it in BloodHound as the GoldenCert edge. None of it is new and none of it is subtle. What is new is that a lot of organizations spent 2022 through 2025 hardening certificate mapping, correctly, and none of that work touches this, because this attack agrees with every rule you enforced.

Three honest caveats.

First, this is persistence and escalation, not initial access. Somebody has to reach the key material once. If your old CA backup is genuinely gone and every copy with it, the story stops before it starts, and if the key ever lived in a TPM or an HSM it very likely stops there too. Software KSP on a 2016 CA installed by a contractor is the case I keep finding.

Second, the window is not infinite. The forged certificate has to chain, and the retired CA certificate has its own expiry. Once that date passes, the chain fails on validity and the forged certificates stop working on their own. That is a real backstop and it is also the reason this is worth doing now rather than next year, because most people have no idea what that date is.

Third, I cannot give you a number for how often a decommissioned CA is left in NTAuth. I find it regularly in assessments, and so does everyone else doing this work, but that is a practitioner impression and not a statistic I can source.

Three things to check this week

One: read your NTAuth store and attribute every certificate on it. From any domain-joined machine, certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=your,DC=forest?cACertificate?base?objectclass=certificationAuthority", or the NTAuthCertificates tab under Manage AD Containers in the Enterprise PKI console. Every certificate in there must map to a CA you currently run and can name the owner of. While you are looking, write down the notAfter on each one, because that date is the outer edge of your exposure if the matching key has ever been copied. Removal is certutil -viewdelstore against the same path with Enterprise Admin rights, and it is exactly as disruptive as it sounds if you remove the wrong one, so confirm what authenticates with it first. Microsoft's decommissioning guidance covers the rest of the objects that get left behind: AIA, CDP, Certification Authorities, and Enrollment Services.

Two: go find every copy of a CA private key you have ever made. Migration folders, decommissioning runbooks, p12 and pfx files on file shares, system state backups of retired CA servers, VM images and snapshots kept for retention, and the disaster recovery export somebody made in 2018 and put somewhere sensible. Then find where the passwords are, which is usually the same document that tells you how to use the file. A CA key protected by a TPM or an HSM cannot be copied out this way, and that is the durable fix for the CAs you run today. For the CAs you retired, the only question is how many copies exist and who can reach them.

Three: make the issuer field something you actually look at. Every legitimate certificate logon in your environment corresponds to an issuance on a CA you operate. Turn on CA auditing so issuance is recorded at all, which is the AuditFilter on each CA plus Object Access audit policy on the server, and you get 4886 and 4887. Then alert on the mismatch: an Event 4768 with certificate information whose issuer is not one of your operating CAs, or a certificate logon with no corresponding issuance anywhere. In a healthy environment that alert never fires, which makes it cheap to run and loud when it matters.

Decommissioning a certification authority is two separate jobs. Turning off the service, and withdrawing the trust. Only the first one has a wizard, and the second one is the one that was ever protecting you.

You turned off the machine. Nobody told the forest.