congrats 1-0-1 

Digitally Signed Malware: What Can You Trust Now?

One of the most startling revelations in the McAfee Labs Threats Report, Third Quarter 2013 is that the observed instance of digitally signed malware increased nearly 50%, to more than 1.5 million new signed binaries. The implications of this trend are profound both for security practitioners and the global trust infrastructure.


("click the image to make it larger")


However, before we look at these implications, let’s first take a look at why the cybercriminal community even bothers to sign their malicious payloads.

Many enterprise defense systems have had a rule in place for many years that basically says, “If a binary attachment is signed, it’s probably good. Let it pass.”For a long time it was a valid rule. Unfortunately, a few years ago the cybercriminal community figured this out and started signing their own binaries.

This trend poses three key questions:

• How would a cybercriminal gang get a supposedly legitimate certificate for their own use?
• Isn’t it the job of the Certificate Authorities (CAs) to issue certificates only to legitimate business concerns and monitor their usage?
• How does an enterprise protect itself from this change in the threat landscape?

The answer to the second question is “Yes,” but it’s a hard problem for a few reasons. First, the 50+ big Root Certificate Authorities distribute their certificates through hundreds of “retail” CAs globally, and it’s nearly impossible to monitor the behavior of all of them. Second, there are rogue CAs operating primarily beyond the reach of global law enforcement that will issue legitimate-looking certificates to anyone with a credit card (or Bitcoin). Third, legitimate certificates do get stolen periodically and subverted for use by cybercriminals.

So, from a cybercriminal’s perspective, getting access to a legitimate-looking digital certificate isn’t very hard, isn’t very expensive, and might increase the “reach” of their malware quite significantly. One of the interesting aspects of this trend is that although there are likely thousands of digital certificates being used to sign malware, cybercriminals definitely have their favorites. McAfee Labs announced at the Focus 2013 conference that we found a handful of certificates that had each been used to sign more than 1,000 distinct pieces of malware. We found another dozen certificates that had been used to sign more than 500 pieces of malware. This would be a logical point to explain how and why the certificate validation schemes fail to identify these rogue certificates, but that’s beyond the scope of this particular piece.

So, to our final question, what should we do to protect ourselves from this latest tactic by “the adversary”? The first thing is to recognize that in the current threat landscape a signed binary is inherently no safer than an unsigned one. This means we all need to have other defenses in place to mitigate this threat. The two most commonly used are application reputation (whitelisting) solutions such as McAfee Application Control and advanced threat detection products that include sandboxing technology such as McAfee Advanced Threat Defense. When skillfully deployed together, these two are capable of identifying most malicious binaries–signed or not. In certain environments it may also be necessary to deploy network intrusion prevention functionality as found in the McAfee Network Security Platform.

If you’re operating in a particularly sensitive environment, you may also want to require that all devices comply with a “common operating environment” policy, in which a single disk image is used by all systems and contains only known good applications and utilities. It’s a brute-force approach and flies into the teeth of the Bring Your Own Device trend, but it is a viable option in certain environments.

Over time, Certificate Reputation services will appear that will very substantially mitigate this new threat. Until then, however, vigilance and a multilayered security approach in the cloud, at the perimeter, and on the endpoint are required.


Original article: By Doug McLean on Nov 20, 2013