Why Malware Gets Signed With Valid Certificates

Does a valid signature mean the file is safe?

No. A code signature carries two claims: a named identity signed this file, and nothing has changed since it was signed. Neither claim describes behaviour. Windows shows a publisher name because a certificate authority verified that name belongs to a real organisation, not because anyone read the code. Signed malware is the ordinary consequence of that gap.

This is worth being precise about, because the phrase "signed malware" suggests something is broken. Nothing is. The chain builds, the hash matches, the timestamp verifies. An analyst checking the file with signtool verify /pa /v gets a clean result and a publisher name. The signature did its job; the job was never to assess intent.

What follows from that is why Windows stopped treating a verified publisher as a pass. SmartScreen scores reputation per certificate from real download telemetry, Defender judges the file, and enterprise policy engines apply their own rules. When Microsoft removed the instant-reputation benefit that EV certificates used to carry, the stated reason was precisely that attackers had learned to buy their way into it — the story we tell in EV vs OV code signing.

The four routes to a validly signed threat

There are four, and they differ in which control failed. An attacker can take a working key from a publisher, enrol as an organisation that is not theirs, pay a service to sign on their behalf, or compromise staff at the certificate authority and issue from a genuine customer account. Only the first involves a legitimate publisher's key at all.

The grouping matters more than the list. Publishers spend their budget on the first row — tokens, HSMs, key ceremonies — and that spending is not wasted, but it addresses the route that has already been narrowed by rule. The remaining three sit inside the issuance system, where a publisher has no levers at all. Reading the 2026 incidents in that order makes them much less surprising.

Route 1: taking the key from a developer

Key theft was the classic route and is now the hardest. Before June 2023 a signing key was frequently a password-protected file sitting on a build server, so copying that file handed an attacker the publisher's identity. The rules changed: publicly trusted code signing keys must be generated inside hardware certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+, and they cannot be exported.

The best-known casualties predate the rule. Certificates that leaked from NVIDIA in 2022 turned up signing malware for a long time afterwards, and that pattern — breach a well-known vendor, inherit its publisher name — was routine enough that the CA/Browser Forum treated exportable keys as the problem to solve. It worked. Bulk theft of usable publicly trusted code signing keys has become rare because there is no longer a file to take.

Here is the part that gets missed. Hardware protects the key, not the signing operation. A build agent that holds the token PIN, or valid credentials to a cloud signing service, can ask for a signature on anything it likes. The attacker never extracts the key and never needs to; they use it in place. So the modern version of route 1 is not key theft, it is unauthorised access to a signing pipeline, a build-security problem wearing a PKI costume, and the reason code signing in CI/CD deserves its own threat model.

Route 2: enrolling as somebody else

The cheapest route today never touches a publisher. An attacker applies for a certificate as an organisation — sometimes a shell company registered for the purpose, sometimes a real company whose corporate identity documents were stolen — and passes organisation validation. MITRE ATT&CK tracks this separately as technique T1588.003, and dark-web sellers have been reselling the output since at least 2015.

Research on that market has repeatedly landed on the same uncomfortable finding: standing up a credible shell company and assembling the documents to support it is neither difficult nor expensive, and the companies whose identities get borrowed usually have no idea it happened. A certificate obtained this way is not forged. It is genuinely issued, to a genuinely verified name, that happens to be a fiction.

From a reseller's desk this reframes something customers complain about constantly. The validation step that stalls an order for three days — the registry that has to agree, the callback to a number the CA looked up independently, the document that gets rejected because it came from the applicant rather than the source — is the only control standing between this route and an issued certificate. It is slow because being fast at it is how the route works. When you buy an OV or EV code signing certificate, the friction is the product.

EV raises this bar without removing the risk. More organisational evidence makes a throwaway front company harder to sustain, and it is one honest reason to choose EV now that the SmartScreen shortcut is gone. It is not a guarantee, as the next two routes make plain.

Route 3: renting a signing service

Signing can be rented. In May 2026 Microsoft's Digital Crimes Unit, working with Resecurity, disrupted Fox Tempest — a malware-signing-as-a-service operation that abused Microsoft Artifact Signing to mint code signing certificates for paying customers. Microsoft revoked more than a thousand certificates attributed to the group and reported that it had stood up hundreds of Azure tenants to keep supply running.

The commercial shape of it is worth stating plainly. Customers reached the service through a storefront at signspace[.]cloud and paid figures reported in the range of roughly $5,000 to $9,000, which is an ordinary business expense for a ransomware crew and far more than a legitimate certificate costs. Microsoft assessed that the operators used identities stolen from people in the United States and Canada to clear the identity verification the service required. Files signed through it included the Oyster loader, the Lumma and Vidar information stealers, and Rhysida ransomware.

One detail in Microsoft's account deserves more attention than it got: the certificates were deliberately short-lived, valid for about 72 hours. That was an evasion choice. A certificate that expires in three days has usually finished its work before a revocation reaches anybody, and it leaves a much thinner trail for researchers to pivot on. The whole industry is moving toward shorter certificate lifetimes for good reasons, and this is a reminder that the same property cuts both ways — brevity limits the damage of a compromise and also limits the usefulness of revoking it.

Nothing about this is specific to one vendor's service. Any model where an operator holds the key and signs on a customer's instruction concentrates the risk in customer onboarding, which is why the identity checks on subscription signing platforms are the interesting part of the comparison in Azure Trusted Signing vs a CA certificate.

Route 4: attacking the people at the CA

The fourth route goes through the people who operate issuance. In early April 2026 an attacker contacted DigiCert's customer support channel, delivered a ZIP archive that looked like a customer screenshot and contained a Windows screensaver executable, and used the internal access that followed to generate EV code signing certificates across several real customer accounts. Sixty certificates were revoked.

Twenty-seven of those sixty were tied directly to the intruder's activity, and the certificates were used to sign samples from the Zhong Stealer family. The split in how they surfaced is the useful part: sixteen came out of the company's own investigation, and eleven were flagged by outside researchers and community members who saw the signatures in live malware and filed certificate problem reports. Anybody can file one, and in this case roughly four in ten confirmed abuses arrived that way.

DigiCert's reported remediation was narrow and sensible: masking initialisation codes when a support analyst operates on a customer's behalf, so a proxied session cannot be turned into issuance. Treating this as a story about one authority would be the wrong lesson. Every CA runs a support function, every support function can be socially engineered, and the ecosystem's answer has never been to assume otherwise. It is public logging, an open reporting channel, and revocation that works.

What actually limits the damage

Three mechanisms do the work after issuance, and none of them is the signature. Revocation withdraws trust from a certificate. Timestamping decides which signatures survive that withdrawal. Reputation and endpoint detection judge the file itself rather than the publisher name on it. Together they are the reason a validly signed threat has a shelf life.

Revocation is more precise than most people expect. The CA records a revocation date, and Authenticode compares each signature's RFC 3161 timestamp against it: releases timestamped before that date normally keep validating, anything stamped after it fails. In a key-compromise case the CA can set the date back to the exposure, so an attacker's signatures lose trust while the publisher's earlier builds survive untouched. We walk through the mechanics, including which reason code to give, in what breaks when a code signing certificate is revoked.

That precision is also the catch. It only works if the signature was timestamped, and a revocation only bites once the verifying machine learns about it. Cached revocation responses, offline verification and long-lived installers all delay that, which is exactly the window a 72-hour certificate is built to exploit. Microsoft supplements the CA's own revocation with its disallowed-certificate list for cases that need to propagate faster than the usual channels manage.

Reputation is the layer that behaves least like PKI and matters most in practice. It attaches to a specific certificate thumbprint and accumulates from real download telemetry, so a certificate minted this morning carries none of it regardless of validation tier. A freshly signed, freshly issued installer looks unfamiliar to SmartScreen, which is unhelpful for the small publisher shipping a first release and useful against somebody burning a new certificate every three days.

What this means if you sign software

Your exposure is narrower than the headlines imply and sits in two places: whether somebody can make your signing credential sign something you did not build, and whether you can prove when your own releases were signed. Hardware key storage covers the key and is already mandatory. It does nothing about a build agent that legitimately holds the PIN.

So the useful work is operational rather than cryptographic. Keep signing off developer workstations and behind a job that only release branches can trigger. Log every signing operation with the artefact hash, and read the log. A token or cloud signing service that signed eleven things on a day you shipped once is the earliest signal you will get. Timestamp every release without exception, because that is what decides whether a revocation costs you one build or your entire shipped history.

Then plan the unglamorous parts in advance. Know who at your CA takes a compromise report and what date you would give them. Assume a replacement certificate starts at zero reputation and that warnings will reappear for a while, which is survivable if you expect it and alarming if you do not. If you hold your own HSM, the attestation evidence a CA needs at renewal is a document you want ready rather than one you assemble under pressure. And keep timestamping configured in the build, not in somebody's memory of the release steps.

None of this makes your signature a safety claim, and it is healthier to stop wanting it to be. What a code signing certificate buys is accountability: a name that a CA checked, a record of when each build was signed, and a mechanism to withdraw trust cleanly when something goes wrong. Used that way it is a strong control. Read as a seal of approval, it was always going to disappoint.