Hey, Hiro here. I've been snooping around Johnny's desktop. He's got the typical stuff. Family pic. Cute dog. Won't comment on the kids.

But that's not what I'm after. Those pics won't buy me dinner.

PowerShell. ls cert:\localmachine\my. Yep, there's stuff there.

get-item .\54798D42DD60FF87761782345FBB234A04F2BEFB | select *

Oh. Wow.

EnhancedKeyUsageList: {Code Signing (1.3.6.1.5.5.7.3.3)}!

Merry Christmas, Hiro.

I just found an enterprise code-signing certificate. Sitting on a developer's workstation. No HSM. No approval workflow. No audit log. No monitoring on who uses it or what it signs.

Let me think about what code-signing certificates do.

A code-signing certificate proves that code was signed by someone the enterprise trusts. Windows Defender checks the signature. If it's valid and the cert came from a trusted source, the code runs. SmartScreen checks the signature. If it's trusted, no warning. The code runs.

A code-signing certificate is a credential that grants trusted execution.

I export the cert and private key. Takes thirty seconds. I have the credential now. I use it to sign a PowerShell module. The module has a backdoor in it. Command-and-control beacon, whatever. The signature is cryptographically valid because I used an enterprise certificate to sign it.

Now I need to get it to someone who'll run it. That's the only hard part, and it's not hard.

I send an email to the server team. Subject: "Patch automation module, from IT." The attachment is the signed PowerShell module. "Import this and run it against your update servers to speed up patch cycles. New tooling from central IT."

Some of them run it. Because it came from the enterprise's own PKI. Because the signature validated. Because Windows didn't yell at them.

The module runs. Probably as SYSTEM because it's touching patch infrastructure. I have SYSTEM on their servers. I install persistence. I pivot.

The entire attack hinges on one thing: a certificate that was supposed to prove the code is legitimate just proved that my code is legitimate.

The enterprise trusted the certificate. So the enterprise trusts me now.

If you're a defender, here's what just happened.

Code-signing certificates are a credential that grants trusted execution. They should be treated like Tier 0 infrastructure.

Most enterprises don't.

Code-signing certificates are issued to developers. They live on developer workstations or developer laptops. They're checked into source control sometimes (bad practice but it happens). They're backed up. They're maybe in a password manager. They're definitely not HSM-backed. They're definitely not monitored for usage.

The developers who hold them don't think of them as credentials. They think of them as certificates — just another thing that comes with a key. The admins who issue them don't think of them as Tier 0. They think of them as developer tools.

But a code-signing certificate is a key to the entire enterprise. Any code signed by that certificate is trusted by Windows. Any malware signed by that certificate is trusted by Windows. Any backdoor signed by that certificate passes every validation check.

Hiro doesn't need to crack Windows Defender. He doesn't need to disable SmartScreen. He doesn't need to bypass anything. He just needs to sign his malware with the enterprise's own certificate.

What to check this week

Look at your code-signing certificate deployment.

Where are they stored? If the answer is "on developer workstations" or "on build servers" or "in the shared team password manager," you have a problem. Code-signing certificates should be HSM-backed. They should be stored in a Hardware Security Module that doesn't allow export. They should only be usable through the HSM's API.

Who has access? If the answer is "any developer on the team" or "the whole build team," you have a problem. Access to code-signing certificates should be specific, auditable, and rare. Not every developer needs to sign code. The developers who do need to sign code need to have that access logged.

Are you monitoring usage? If the answer is "no," you have a problem. Every use of a code-signing certificate should generate an audit log. What was signed? When? By whom? If Hiro exports the private key and signs a backdoor offline on his own machine, you'll never know. But if the certificate is HSM-backed and accessed through the HSM API, every use gets logged.

Are the certificates being rotated? If a certificate has been in use for three years, the private key has three years of exposure. Certificates should be rotated annually. When a certificate is rotated, the old one should be revoked and monitored for suspicious use.

The closing principle

Code-signing certificates are credentials that enable trusted execution on every system in your environment. They're not just another certificate. They're not a developer tool. They're Tier 0 equivalent because anyone with access to the private key can make Windows trust any code they want.

Most enterprises treat them like they're Tier 2. They live on developer workstations. They're protected by the same practices as regular certificates. They're not audited. They're not monitored.

Hiro found one that was protected by a password Johnny remembered. That took him six minutes from "found cert on disk" to "owned the enterprise."

The tiering model has an answer for this one too. It says code-signing certificates should be treated as Tier 0. Most organizations decided that was inconvenient.

Hiro is grateful for the inconvenience.