Well. It seems I can't hijack your CA through backups anymore. You all went and shut that door on me after my last musings. I'm a little hurt, honestly. But black hat and all, hurting you is my job. Right?

So I'll find another way.

I've hijacked Suzie Q's desktop. She fell for my exotic prince routine, and now I'm in. She's not super privileged, which is unfortunate. But I'm patient. The help desk is bound to show up eventually and leave me a present in the shape of global desktop admin credentials.

While I'm waiting, though, I always check what Suzie Q has access to.

This is the part where I'd normally walk you through the exact reconnaissance commands. I'm not going to. Not because the commands are secret. They're not. AD is read-only to anyone authenticated, by design, with a small number of exceptions. Your CA configuration, your templates, your published enrollment rights, every group membership Suzie Q sits in, all of it is readable to me from the moment I land on her box. Telling you the commands would just turn this post into a tutorial. The point isn't how I find what she has. The point is that I can.

And what does Suzie Q have? Let me see. Enrollment rights on a User template. Standard. Domain Users has Enroll on it. Suzie's a Domain User. So am I, now.

What does that template give me?

Client Authentication, for one. That means I can request a certificate as Suzie, or as whoever I'm impersonating once the help desk drops by, and use it as proof of identity to authenticate to anything in your environment that trusts your AD. Web apps with smart-card-style login. VPNs. Internal SaaS that does cert-based SSO. Any of it. The cert says "this is Suzie Q" and your infrastructure believes the cert because it's signed by your CA.

But here's the one I like better. Encrypting File System.

The User template publishes an EFS certificate too. I can enroll one, no questions asked. And EFS works like this: the user has a cert, the cert encrypts a key, the key encrypts the files. If you have the cert's private key, you decrypt. If you don't, you don't.

So here's what I do. I enroll a fresh EFS cert in Suzie's name. I encrypt every file on her drive with my new cert. Documents. Spreadsheets. Project plans. The SharePoint cache. The lot. Then I take my fresh cert's private key and I burn it. Throw it into the void. Forget it ever existed. Clean cut, no leftovers.

Suzie's files are still encrypted. Beautifully encrypted. Mathematically sound. Just nobody has the key. Not her. Not me. Not your help desk.

Before I leave, I drop a text file on her desktop. Just this:

Have a nice day,
Hiro

She'll see it Monday morning. She'll open it before she opens anything else, because it's the only thing on her desktop that isn't behind a lock icon. That's when she'll know.

You think you'll restore from backup? Maybe. Depends what you back up. The EFS-protected files on your file shares? Same problem if the user's cert was used on the server side. Some environments find out the hard way that EFS-encrypted data is exactly as dead as the cert that encrypted it.

You think your key recovery agent will save you? Let me check. There's a KRA cert configured on the CA, but it's expired. The replacement was never issued. The private key from the original is on a USB stick in someone's desk drawer at the office they moved out of three years ago.

This isn't ransomware. There's no ransom note. I'm not asking for money. I'm just here to ruin your week. Mission accomplished.

Hiro out.

End scene.

If you're a defender, here's what you need to understand. The attack just described uses no privileged access. No exploit. No malware in any traditional sense. It uses your CA the way you set it up. The reason it works is that most enterprises publish the User template — or a copy of it — with Enroll permission granted to Domain Users, and have done so since the CA was first installed. Nobody reviews it because nobody thinks of a User cert as dangerous. It is.

Three things to check this week

One: who can enroll for what. Open the Certificate Templates Console. For every published template, look at the Security tab. Domain Users, Authenticated Users, or any broad group with Enroll permission on a template that publishes Client Authentication or EFS is your problem. The fix is to scope enrollment to a specific group that contains only the users who actually need that cert type. Most users don't need EFS. Many don't need Client Authentication either, depending on what your environment uses certs for.

Two: whether you actually have a working key recovery agent. A KRA cert that's expired is not a KRA. A KRA cert whose private key was lost in a previous CA migration is not a KRA. A KRA configured on the CA but with no encryption-enabled templates referencing it is not a KRA. Verify all three. If you're using EFS in your environment, you need a working KRA, and you need to test recovery on a regular cadence. Annually at minimum. If recovery doesn't work in a tabletop exercise, it won't work when you need it.

Three: whether EFS is appropriate for your environment at all. EFS made sense in 2003 when laptops were rare and BitLocker didn't exist. In 2026, full-disk encryption handles the laptop-loss scenario better, with central recovery via Active Directory or Entra ID, no per-file complexity, no per-user cert lifecycle, no KRA dependency. Many organizations are still running EFS by default because nobody ever turned it off. If you're one of those organizations, the question to answer is whether you'd lose more by removing EFS or by leaving it in place as an unsupervised ransomware vector.

Hiro doesn't need to be sophisticated. He needs patience and a phishing payload that works against one user. The rest of the attack chain is your CA doing exactly what you configured it to do, signing certs for users who have enrollment rights.

The first step is knowing what those rights actually are.