How can security teams detect Code Signing Key Theft?

How attackers turn a stolen signing key into trusted malware

code signing key theft matters because the attacker is not trying to break trust at the network layer, they are trying to borrow it. Once a signing key is stolen, malicious code can look legitimate to users, endpoint controls, and update workflows unless defenders notice the signing pattern itself, not just the payload.

That makes the detection problem less about static malware signatures and more about tracing whether the organisation’s normal signing process is still being followed. A useful baseline includes which hosts sign, which keys or certificates are used, when signing happens, and whether the artifact came from an approved build or release path.

For a practitioner guide to the broader control plane around this problem, NHIMG’s Code Signing Security Guide covers key protection, signing pipelines, timestamping, revocation, and theft response.

What anomalies usually show up first

The earliest warning signs are usually operational anomalies, not obvious malware alerts. Look for signing activity from a new machine, a new user context, an unusual time of day, a different signing tool, or a certificate that appears in builds it has never previously touched.

New certificate use is especially important when it is paired with binaries that do not match the normal release process. If a code-signing certificate appears in artifacts that were not produced by the approved CI/CD system, that is a strong clue that signing authority may have been copied, misused, or routed through an unauthorized host.

Key and certificate lifecycle evidence also matters. A signing credential that suddenly begins producing many signatures, signs unfamiliar products, or is used outside its normal environment deserves immediate review. NHIMG’s Cryptographic Key Management Guide is useful for understanding how key inventory, rotation, and compromise response fit together.

How to separate normal release signing from theft

The best discriminator is provenance. A legitimate signing event should line up with source control, build logs, release approvals, and the expected signing host or service. If any one of those links is missing, the signing event may still be valid technically, but it is not trustworthy operationally.

Security teams should also compare signer identity against environment boundaries. Signing that happens on an engineer workstation, jump host, or interactive admin session is higher risk than signing from a dedicated, hardened system with tightly controlled access. When signing keys are protected well, the provenance trail is usually boring and repeatable.

NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is relevant here because certificate and key lifecycle problems often hide in the same places, especially when release automation and trust material are intertwined.

Practitioner Guidance

What to prioritise: Triage signing events that cannot be tied to an approved pipeline first, then check whether the same certificate or key has been used from unexpected hosts or at unexpected times. That combination is usually more actionable than waiting for confirmed malicious binaries.

What to verify: Confirm that signing hosts, service accounts, certificate issuance records, and build provenance all align. If the signing event is real but the pipeline record is missing, treat it as a control failure even before you prove theft.

Escalation / exception: If an unauthorized signing event is suspected, move quickly to revoke the certificate, isolate the signing environment, and assess whether other artifacts signed by the same key are already in circulation. Delay increases the chance that trusted malware will spread through ordinary update channels.

Practitioner takeaway: Detecting signing key theft is mostly a provenance problem, so the strongest signal is not “was malware found?”, but “did a trusted key sign something outside the trusted process?”

Related resources from NHI Mgmt Group

• Why does combining authentication and code signing on one key change the security model for development teams?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?