Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

11:15 AM
Paul Drapeau
Paul Drapeau
Connect Directly
E-Mail vvv

Stop Trusting Signed Malware: 3 Steps

Cybercriminals who manipulate valid signatures and certificates to get malware into an organization is a more common tactic than you think.

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.

Paul Drapeau is a Principal Security Researcher for Confer, which offers endpoint and server security via an open, threat-based, collaborative platform. Prior to joining Confer he led IT security for a public, global pharmaceutical research-and-development organization. He is ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment:   It's a PEN test of our cloud security.
Current Issue
IT 2020: A Look Ahead
Are you ready for the critical changes that will occur in 2020? We've compiled editor insights from the best of our network (Dark Reading, Data Center Knowledge, InformationWeek, ITPro Today and Network Computing) to deliver to you a look at the trends, technologies, and threats that are emerging in the coming year. Download it today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-01-24
An issue was discovered in Big Switch Big Monitoring Fabric 6.2 through 6.2.4, 6.3 through 6.3.9, 7.0 through 7.0.3, and 7.1 through 7.1.3; Big Cloud Fabric 4.5 through 4.5.5, 4.7 through 4.7.7, 5.0 through 5.0.1, and 5.1 through 5.1.4; and Multi-Cloud Director through 1.1.0. A read-only user can ac...
PUBLISHED: 2020-01-24
Angular Expressions before version 1.0.1 has a remote code execution vulnerability if you call expressions.compile(userControlledInput) where userControlledInput is text that comes from user input. If running angular-expressions in the browser, an attacker could run any browser script when the appli...
PUBLISHED: 2020-01-24
: Incorrect Default Permissions vulnerability in libzypp of SUSE CaaS Platform 3.0, SUSE Linux Enterprise Server 12, SUSE Linux Enterprise Server 15 allowed local attackers to read a cookie store used by libzypp, exposing private cookies. This issue affects: SUSE CaaS Platform 3.0 libzypp versions p...
PUBLISHED: 2020-01-24
CiphertextHeader.java in Cryptacular 1.2.3, as used in Apereo CAS and other products, allows attackers to trigger excessive memory allocation during a decode operation, because the nonce array length associated with "new byte" may depend on untrusted input within the header of encoded data...
PUBLISHED: 2020-01-24
Soapbox through 0.3.1: Sandbox bypass - runs a second instance of Soapbox within a sandboxed Soapbox.