Stop Trusting Signed Malware: 3 Steps

There has been no shortage of news about malware bearing valid signatures. Most recently, Cryptowall ransomware was discovered with signing credentials that appear to have been validated by a popular certificate authority. Similarly, news broke a few weeks back that HP’s signing credentials were stolen and used to sign malware.

In theory, code signing allows an end user or enterprise to have confidence that software is produced by an author they trust. Manipulating these systems to get malware into an environment is more common than most people think. Malware authors can steal, purchase, or privately generate signing credentials and associated certificates. Our recent research shows they are frequently doing all three. We’re reminded that whitelisting and application management systems that rely on certificates to establish trust are, at best, insufficient to protect the endpoint.

Researchers at Confer recently examined the signing artifacts of roughly 25,000 malware samples caught in the wild over the last year. In this relatively small sample set, we observed many examples of attackers misusing legitimate or quasi-legitimate credentials.

In one case, a certificate that was issued to a legitimate software company in the United States was used to sign payloads in drive-by exploit kits. We saw this cert in nine different malware samples over the course of several weeks. All of them had valid code signatures.

This may sound surprising but the reuse of certificates in malware is common. We saw the same credentials showing up in hundreds of samples over months. In fact, based on this data set, once compromised, a certificate will be used on over 50 samples and for a period of more than 190 days.

We also saw many samples with “invalid” signatures or certificates issued by private certificate authorities (CAs), often with confusing names. The attacker’s goal is to trick end users into accepting software installs. It seems likely that attackers are generating their own credentials and certificates for this purpose.

Finally, we saw several samples with valid signatures and valid certificate chains that do not appear associated with any legitimate producer of software, indicating that attackers are procuring these certificates through legitimate channels. They are buying legitimate certs from established certificate authorities. This appears to also have been the case with the recent Cryptowall example.

Now what?
There are several things this data tells us and about can we improve security in the enterprise.

Step one: Every CIO, CISO, and engineering manager who’s signing code needs to protect his code signing keys, passphrases, and CA infrastructure by designating someone in the company to be responsible for recommending, implementing, and monitoring effective controls around the keys and signing infrastructure.

These are valuable assets and an extension of a company’s brand. But all too often, they are carelessly maintained, widely distributed, and procured in a decentralized manner. No company wants its name attached to the next devastating piece of ransomware. If you are developing code, stop reading now, figure out who has access to these signing assets, how they are controlled, and how they are used.

Step 2: Information security professionals should look at the signing artifacts associated with code running in their environments and use them as a detective control versus a preventive control. While it may be easy to steal, buy, or generate new credentials, attackers do tend to rely on these certificates longer than particular binaries or C2 infrastructure. Signing credentials are simply more difficult for the adversary to replace. We can use this to help find them.

Step 3: More broadly, this situation is another opportunity for us to examine how we deal with trust. Do enterprises really know where the software they run comes from, and is this even a tractable problem? At the end of the day, users still will click the “yes” button when presented with illegitimate signatures.

Code signing isn’t a simple solution to the complex problem of trust. Controls create incentives for attackers to change their behaviors and make assets we might not always think of as critical to the business key targets. Signed malware will likely only become more common and the authors will keep trying to get their hands on what they need to produce signatures that bypass traditional controls. Just because a binary says it is from a source you think you trust, you should still keep a close eye on it.