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/7/2014
11:15 AM
Paul Drapeau
Paul Drapeau
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
How to Identify Cobalt Strike on Your Network
Zohar Buber, Security Analyst,  11/18/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: A GONG is as good as a cyber attack.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25660
PUBLISHED: 2020-11-23
A flaw was found in the Cephx authentication protocol in versions before 15.2.6 and before 14.2.14, where it does not verify Ceph clients correctly and is then vulnerable to replay attacks in Nautilus. This flaw allows an attacker with access to the Ceph cluster network to authenticate with the Ceph...
CVE-2020-25688
PUBLISHED: 2020-11-23
A flaw was found in rhacm versions before 2.0.5 and before 2.1.0. Two internal service APIs were incorrectly provisioned using a test certificate from the source repository. This would result in all installations using the same certificates. If an attacker could observe network traffic internal to a...
CVE-2020-25696
PUBLISHED: 2020-11-23
A flaw was found in the psql interactive terminal of PostgreSQL in versions before 13.1, before 12.5, before 11.10, before 10.15, before 9.6.20 and before 9.5.24. If an interactive psql session uses \gset when querying a compromised server, the attacker can execute arbitrary code as the operating sy...
CVE-2020-26229
PUBLISHED: 2020-11-23
TYPO3 is an open source PHP based web content management system. In TYPO3 from version 10.4.0, and before version 10.4.10, RSS widgets are susceptible to XML external entity processing. This vulnerability is reasonable, but is theoretical - it was not possible to actually reproduce the vulnerability...
CVE-2020-28984
PUBLISHED: 2020-11-23
prive/formulaires/configurer_preferences.php in SPIP before 3.2.8 does not properly validate the couleur, display, display_navigation, display_outils, imessage, and spip_ecran parameters.