I've decided to compromise your infrastructure.

Yes, I've gone to the dark side and figured that as long as I don't get caught there's more money and reputation in going black than the blue I normally wear.

Where do I start. Nope, not domain admin. Too obvious.

A quick net groups /domain dumped to text and start looking at that list for anything interesting. Oh. Found one. BackupAdmins. That smells good. It's not the default Backup Operators which is frequently monitored. Who's in it? Hmm let's see. net group BackupAdmins /domain. Five members. Four look like privileged accounts. t0_johnsmith smells of domain admin to me. That last account though. janedoh. No prefix, nothing. Let's check her out. net user janedoh /domain. Just as I thought. Standard user object. Look at all those distro lists.

She's my way in.

A week of patient phishing later, I'm sitting on janedoh's session. Her token gets me into the backup console. Better than Domain Admin honestly, because nobody's watching this seat. I browse the backup catalog. There they are. The DCs. Sure, I'll grab those. But what I really want is two seats over. The CA. PIXA-ROOT-CA. Full system backup. 47GB.

I download it slow. Pieces over days, blended into normal backup-job traffic. Nothing screams. Nothing alerts. I reassemble at home, mount the VHDX, and there it is on the system disk. The CA's private key, exportable, mine to use however I want. I now sign certificates your entire forest will trust. I issue myself an administrator certificate in the name of any domain admin I want to be. I walk into your environment as them. I own you and you don't know it yet.

End scene.

If you're reading my story, know that yes, everything I just did works in many environments and it's part of the early steps taken by attackers to find a way into your organization. Granted, some tools (Microsoft Defender for Identity, for one) will report on users doing reconnaissance like this when they have no business doing it, but for the sake of this article, we'll pretend I had to get sneakier than that.

I targeted BackupAdmins because the odds are very high that group has access to every backup in your organization. I could also have looked for storage admin type groups. Bottom line, I'm looking for backup files, VMDK, VHDX, or any other virtual system files. Any of those are typically a gold mine.

I'll come back to the DC backup in a moment. The real prize was the CA.

Let me ask you. When you do a snapshot, or your backup utility grabs a full system backup, where does the private key of your CA end up? I hope you answer "it's on my HSM, I'm not worried." If you can't say that, then the reality is the private key of your CA exists in every snapshot, in every backup you're still hanging on to. Every one of those is an opportunity for someone like me.

Backup agents on Tier 0

Backup agents and third-party software on Tier 0 systems deserve their own conversation, and I won't belabor it here. Just know that every piece of software installed on a Tier 0 system increases the risk footprint of that system, often in ways the vendor never documented and the customer never reviewed. When you put a backup agent on a CA, you accept that the agent is now Tier 0 by association, that its update channel is a Tier 0 channel, that its credential cache is a Tier 0 secret, and that its vendor's breach is your breach. Few organizations make that accounting consciously.

So how do you actually back up the systems that matter?

Domain Controllers

Microsoft has long suggested system state backups of your domain controllers using the built-in Windows Server Backup tool. Point the backup target at a different server or an external file share. Have a dedicated Tier 0 backup utility pick the files up from there. The DC writes the backup. Something else moves it. No agent on the DC.

Certification Authorities

I highly encourage you to never do a full system backup of an issuing CA unless you have an HSM in place. And even with an HSM, don't do a system backup if you're also doing private key archival. Private key archival saves user private keys inside the CA database, and you don't want those in the wrong hands either.

From a criticality perspective, I tell customers all the time that I can keep them up and running with only the CA's private key for recovery. The private key alone allows me to sign fresh CRLs, which is what keeps every certificate already issued from being treated as untrusted while the next CRL is overdue. Things stay working. Existing certs validate. The lights stay on. New issuance, that requires a full restore — you'll need the database, the registry config, the templates list — but the immediate fire (a forest full of cert-auth devices about to fall off the network because the CRL expired) doesn't happen if you have the private key and can sign a new CRL.

So most customers I've worked with do an application-level backup of the CA. Not a manual process. Scripted, automated, scheduled task. The script grabs:

  • The certsvc registry hive and all its content
  • The CAPolicy.inf file, if one exists
  • Copies of the CA's certificates (public, both current and historical)
  • Copies of the CRLs the CA has issued
  • A list of the templates published on the CA
  • The CA database

The private key is never backed up by this task. The output files land in a file share that the Tier 0 backup utility can pick up from. I've seen versions of this script written as a batch file, a VBS script, and a PowerShell script. You can have fun creating one for yourself.

Or you can download the PowerShell version I've used at customer sites for years, free, at brkrops.ca/download.html. The article you just read exists because somebody downloaded that script this week, and I figured the context behind it was overdue.