Code Signing Key Theft: Examples, Risks, and Security Best Practices

Key Takeaways

• A code signing key is basically a key that allows all the people in possession of it to speak in the name of a piece of software.
• Theft and pipeline abuse all create “validly signed” malware.
• Turn it off first and enable it back on new hardware. The key should not be reused.
• Store keys on an HSM, token, or cloud HSM. Never leave it on disk or even in GIT.
• The relevance of logs, timestamps, least privilege, or scan-before-sign is as important as the certificate.
• As a consequence of an incident, customers require a new serial and a way of verifying the incident.
• Prevention is cheaper than it is to re-sign every one of them and a year of update untrust.

A valid digital signature is a green light for Windows, browsers, and “Microsoft SmartScreen” protection: this file comes from the publisher mentioned in the digital signature, and it has not changed since it was built. By signing code, you are trusting to ensure that the code is safe for your machine.

Digging up the asset is not just their public .cer file, which is everywhere in a certificate store; it is the key that is vital for the creation of the signature.

An attacker can sign ransomware, fake software updates, or drivers to appear official with this key. You will learn how to see how theft actually occurs, how people get paid for stealing, steps you take when you discover the theft, and what controls prevent you from having the key on your laptop, a git repository, or the shared build server.

What is a Code Signing Key?

A code signing key is the private side of a certificate authority certificate given after verifying the identity of the publisher. The first half is designed for public viewing, and the certificate contains the public half. A valid signature can only be provided with the private key.

When signing, the tool produces a hash of the binary, signs it with the private key, and adds the signature and certificate chain. Platforms then verify two things: the publisher and whether the file had been modified. They don’t determine what software is safe.

A trusted timestamp demonstrates that the signature was there at a time when the certificate was active. Timestamped files will continue to serve after expiration of the cert. When it comes to revocation, things get trickier, and requiring an active response still is a stolen key.

Both the third and fourth declarants include the names of a publisher in the certificates. But EV Code Signing still needs to have its respective hardware-backed key, and does typically receive a better reputation on SmartScreen.

Since June 2023, trusted CAs only allow for the generation and storage of new private keys in the private key format defined by FIPS 140-2 Level 2 or CC EAL4+ hardware, and not an exportable PFX format.

What will happen if a Code Signing Key is Stolen?

An attacker will steal the private key and pretend you’re the publisher. Signing ransomware, fake installers, drivers, or updates that appear as your own.

There are numerous tools that either whitelist “Signed by Vendor X” or obscure information about signed files. There was already a click-through that made users click through.

Your digital identity goes out of your control. Fake builds can be delivered on pirate sites, GitHub releases, or poisoned packages, which are hard for customers to distinguish as a signed fake.

It needs to be revoked and in disarray. It must be revoked and in disarray, starting to alert to invalid applications. You renew existing releases, send out replacements, and deal with a spike in support. Even the software that requires a timestamp can be checked in line with the platform policy, so rewinding isn’t possible.

The worst case is to have a key for your build or channel for updates. Then, malware gets transported down the official pipeline, or rather, one that is not a random download page. This leads to an inevitable and inevitable consequence of soft damage: the delay in customers updating and the questioning of partners in the SDLC environment in which a signing key walked away.

A code signing key isn’t just a technical credential. It is an image and character in its own right that is an attribute of the organisation it belongs to.

Real-World Examples of Stolen or Abused Keys

Trafficking/stolen signing keys continue to make malware “trusted” software! What is visible in these four incidents are the normal scenarios: copied key, forgotten cert, poisoned build, and hijacked update channel.

Example	What happened	Lesson
Stuxnet (2010)	Signing of Realtek and JMicron keys for drivers.	Installing with a valid kernel signature eliminates the ‘unknown publisher’ snafu. The removal of the cert is not a sign of removing binaries from the wild.
Bit9 (2012–13)	Attackers signed backdoors targeting Bit9 customers with an old cert on an unprotected VM.	An unused cert that is still valid is STILL a live key! Update obsolete signing records and remove old records.
CCleaner (2017)	There is a backdoored installer signed in the true installation/update process and deployed as a regular install.	If the pipeline is damaged, then the attacker won’t be required to steal the key elsewhere.
ASUS ShadowHammer (2018–19)	Payload signed for the official update mechanism.	Mass reach happens at a marker point two to three weeks before update servers.

Subsequent incidents see a “caller backs” behaviour: NVIDIA (2022) lost the certs that they used for malware leaks; AnyDesk (2023-24) lost production signing material after being compromised during production.

Recommended: Risks and Challenges with Compromised Code Signing Certificate – How to Overcome?

How Attackers Can Abuse a Stolen Code Signing Key

A lost key isn’t able to just hide malware. It allows an attacker to use your name on every platform that is still influenced by a valid signature as a sign of trust in the file.

Signed Commodity Malware

They encrypt with RATs, get stuck on sevens and ransomware loaders onto their computers, and now Authenticode, SmartScreen and AV reputation engines mark the file as a known vendor, rather than as a known piece of junk mail.

Kernel and Installer Footholds

Either sign drivers where code is unsigned, or ship a signed MSI like an IT package. The rest is done by social engineering.

Official-looking Channels

They release those binaries under fake update centres, compromised release accounts, or tainted open source packages. Other crews sell or rent the key itself or rent it in a key trade (Megatraffer) in exchange for a profit.

Two Different Failures

The attacker signs his malware with your identity (a stolen key). Steal a pipeline: Sign their code; a key has never left the HSM! There is a need for prevention to address both. If they also have CI/CD or the CDN, which contains the contents of updates, then a signed payload is pushed to all customers by the next release.

How to Avoid Loss of Code Signing Key?

Prevention is not a check-the-box item on a CA form, but rather actual, ongoing work. Treat the private key as production infrastructure, and assume that both the key and pipeline can fail.

• Generate the key in a token or HSM and set it to “do not export”. No PFX stored or found on disk, no keys found in Git, CI, or backup.
• For the following, prefer centralised signing, using hash locally, and signing in the HSM. Private Keys are never handled by the developer(s).
• Least privilege and use multi-factor authentication (MFA), and separate signing identities from daily development accounts. Apply dual control/release signing or M of N control/release signing.
• Sign only from a locked-down signing service or isolated build. The following stations were not signing: developer laptops.
• Record all log requests: who, what hash, when and which ticket or release ID. Notify if the server has increased volume or received unknown binaries.
• Rotate certificates short-term – and periodically (not just after an incident). New validity for CA has been reduced to less than the previous 3 years.
• Always document with a reliable (and a second if possible) TSA.
• Malware scan, an SBOM, and a dependency review are all steps you should take before signing them.
• Record all certificates – subject, serial, expiry date, storage, and who can sign.
• Educate individuals who have approval authority. The typical first step into phishing those accounts remains just that. Still, it is the same old game of phishing those accounts.

What to Do If Your Code Signing Key Is Stolen

Move in hours. There’s now a precedent in place: GitHub and AnyDesk are doing it: Revoking and declaring outdated builds as not trusted and forcing updates.

• Don’t treat this as an IT inconvenience; it’s a live identity compromise situation. Someone else is using your publisher’s name.
• Get in touch with the issuing CA and revoke as soon as the problem is detected. Create serial numbers and thumbprints to send out to customers and threat intel.
• Record all the binaries after the suspected compromised window, and provide a hash list for defenders.
• Create a new smart card key pair for new hardware. Never use the same key material if the one in use is old.
• Re-sign existing supported versions with a new serial and announce to the users how to confirm the new serial.
• Reset corresponding credentials: build access, portals, token PIN and cloud signing API keys.
• Serving as a general rule, look for anything that is signed by us and that didn’t exist in your release catalogue.
• Hunt signing logs and endpoint telemetry in return.
• Inform consumers/app stores / Microsoft/SmartScreen / regulators (where applicable).
• Perform the root cause analysis: Repo, VM, phished admin, or weak token PIN, then close the path.

Recommended: A Guide to Code Signing Abuse & Protection

Code Signing Key Protection: Best Practices for Developers

This playbook is for use if a key leaks one day. The standard is to live in the next critical key as a copy on disk, blob in Git, or unattended signing API.

Practice	Why it matters
Hardware-backed, non-exportable keys	Prevents copy theft without detection while copying silently
A central signing service with RBAC.	Key use is a controlled API and NOT a file.
Duplication of production signs.	Prevents access to a single corrupted account
Immutable audit log	Required for scoping revocations
Use different keys/traust Domains for different kinds of products	Limits blast radius
Timestamp every signature	Meets the expiration and limited further revocation criteria
The CI/CD only signs and scans artefacts	Stops pipeline poisoning
Avoid having signing keys in source control or in the ticket attachments.	GitHub 2022 lesson
Frequent tabletop (key stolen) drills and access reviews	Will buy and sell process, not just hardware
Windows software for public use has an EV certificate.	It also simplifies things with its enhanced identity and enhanced reputation UX.

Design for algorithm flexibility to accommodate CA’s change of requirement for RSA and/or ECC. The migration to post-quantum crypto is not the thorny problem in the middle of your face.

Recommended: PQC Code Signing in a CNSA 2.0 World: Preparing for the Quantum Leap

Conclusion

In the Digital Signing world, publisher identity is called Code Signing. Keep the private key as you would your brand.

Issuing is now the base, not a luxury anymore; otherwise you wouldn’t be purchasing it :). Obtain a certificate from a publicly trusted CA, create a key using compliant signing hardware or service, and have all the signing elements wired into a logged release process

Search