Certified Bad

This material was presented at SLEUTHCON on May 12, 2023.

Abstract:

Authenticode Certificates are intended to ensure that software is created by vetted parties and that the software can be trusted; however, malware is often signed with valid Authenticode certificates and the process for signing malware and the implications are often misunderstood within InfoSec.

My presentation presents lessons learned from studying and documenting the Authenticode Certificates used by the SolarMarker malware actor. The research looks over 2 years and 50 Authenticode certificates that I personally documented and reported for revocation. 

This presentation explains the role of Authenticode certificates for malware and then uses certificates used by SolarMarker as an in-depth case study. The study covers how the SolarMarker actor has used certificates and discusses how those same certificates were used by other malware actors: this is referred to as a collision. Examples of collisions are instances where SolarMarker has used the same Authenticode Certificate that was used to sign other malware, such as ZLoader and IcedID.

Disclaimer: This data is not intended to shame or endorse any certificate provider. This is just a presentation of the data. 
Disclaimer: I am making no claim that this data is a representative sample across certificate providers.

What are Authenticode Certificates?

Authenticode Certificates are digitally signed certificates of trust for programs (executables). They confer trust of the certificate provider to the Software Provider. Certificates are used to tell computers that the software is from someone who is trusted.

There are two types of Authenticode Certificates: Standard Code Signing and Extended Validation (EV).

Standard Code Signing requires basic identity checks.

Extended Validation requires legal-style identity information and have a three stages for verification.

  • The provider will ensure the company exists within government databases
  • The provider will perform domain control validation to ensure that the requestor is a legitimate part of the requesting organization.
  • The provider will have a robot call the requestor to ensure they have control over the provided telephone number.

Once these checks are performed for an Extended Validation certificate, the requestor will be provided a Two-Factor token to use for code-signing.

Certificates are desired by malware actors because with a certificate, the malware can be mistakenly trusted by Microsoft SmartScreen and mistakenly trusted by analysts. In fact, some providers such as Certum.EU/Certum.PL (a certificate provider) market their Extended Validation Certificates as providing these same benefits: namely, that browsers will trust the program and so will SmartScreen.

In order to obtain a certificate, an actor impersonates an organization in order to obtain a certificate. Once the certificate is obtained, the actor (or as I will call them hereafter, “impostor”) will usually create a “Proof of Value” by signing any program. This signed program shows potential buyers that the impostor can in fact sign programs with a valid certificate. The impostor will then sell their services to sign malware on behalf of threat actors.

SolarMarker Dataset

The dataset I researched was based off of SolarMarker.

SolarMarker is a modular malware first seen in 2020. The modules consist of a backdoor, a keylogger, a form-grabber/wallet stealer, infostealer, and a VNC Client.

The SolarMarker actor always signs his first stage payload and over 2 years of tracking the actor, I identified and requested revocation 50 certificates that were used by the threat actor. Based on these 50 certificates, I reviewed 698 files on VirusTotal that were signed with the same certificate signers.

Twenty-eight (28) of the fifty (50) certificates were from Digicert. (Interactive Graph) Twenty (26) of the fifty (50) certificates were Extended Validation certificates.

And why is this interesting?

This data becomes interesting because the 698 files reviewed from VirusTotal were not all SolarMarker malware. Many times the certificates used by SolarMarker were also used to sign other malware: I refer to this concept as “Collisions”.

Collisions are when one certificate is used to sign multiple malware.

Collisions

In reviewing the data, 14 distinct malware families were identified. (Interactive Graph.)

Of the 698 binaries, 412 of Chromeloader malware. However, this wasn’t due to a large amount of Chromeloader in the wild: this is actually due to the impostor testing and uploading files repeatedly to VirusTotal. For this reason, we will exclude Chromeloader from the following graphs.

How Collisions happen

Reviewing the data, we can sometimes observe these transactions vividly. In a concrete example, we observed one impostor impersonate an organization receiving a Extended Validation certificate from Certum.PL.

After they receive the certificate, they sign a “Hello World” program and upload it to VirusTotal as their Proof of Value. Thirty-one (31) days later they sign a Lock-Screen malware, and then twenty-two (22) days later, sign a SolarMarker binary.

Many of the malware families were some bigger name malware such as: Zloader, IcedID, CobaltStrike (multiple actors, including Qakbot), NetSupportRAT, RemcosRAT, BazaarLoader (Interactive Graph.)

In regards to the 50 certificates I reviewed, there was no indication that any of the certificates were stolen. All of the certificates were issued to an impostor. We can see this more easily when we examine the time-to-abuse.

When do Collisions Happen?

The majority of certificates were abused within 50 days of being issued to the impostor. Many of the certificates were abused within the first week or within the first day of being issued. (Interactive Graph.)

In the graph, the detected abuse date is based on when files were uploaded to VirusTotal. One thing we observe in the data is that certificates continued to be abused up to 600 days after the certificate was originally issued.

The “abuse over time” of one certificate can be observed more easily in the following graph. (Interactive graph). The lines in the graph indicate the same certificate being used for another malware. The darker colors indicate that the abuse of the certificate was detected closer to the time of the certificate being issued.

What we see in the data is that occasionally, certificates are used to sign multiple malware within a few days of each other. When a certificate isn’t revoked, the abused certificate will likely get reused for another malware after several months of the initial abuse.

One vivid example is displayed later in the graph: We observe multiple actors using the same impostor to sign their malware.

The first indications of abuse appear on VirusTotal from an unknown RAT 455 days after the certificate was issued to the impostor. The same certificate used to sign JuiceLedger which was distributed via PyPI libraries. The impostor signed several binaries whose full purpose is still unknown, IcedID and SolarMarker.

This continued abuse is only possible because of the failure to revoke certificates after they are detected as malicious.

In the above example, on September 1, 2022 SentinelLabs reported the abuse of this certificate by JuiceLedger. In the article, they mention that the certificate is valid and used to sign other malicious files, but they fail to get the certificate revoked. As a result of this failure, this certificate continued to be abused until it was finally revoked on January 25, 2023.

Why revoke?

Due to how the certificates themselves are abused, the revocation of a certificate impacts multiple actors and impacts the market itself

When we look at this type of abuse, we see two basic scenarios.

In the first scenario: the impostor invests the money and time to perform the impersonation. They sell their services at some reasonable markup. From the first sale, they receive a small profit but after selling to other threat actors, their labor returns pure profit.

Note: The cost 1000 is arbitrary for illustration purposes. Extended Validation certificates range in cost from providers and are sold for a wide range on the DarkWeb.

In the second scenario, the impostor invests the money and time to perform the impersonation. They sell their services at a reasonable markup, but after their first sale, their certificate is revoked. The actor only receives profit from the marked up cost.

This revocation reduces the profit for the impostor and increases the costs for all other actors using the certificate services.

Key Ideas

From this analysis we have these following key ideas

  • Malware actors use third-parties to sign malware.

While this isn’t the exclusive means, it is one to be aware of.

  • Third-parties sign multiple malware

This use of third-parties creates a common thread between malware actors. My simple data-set shows that even the larger malware families use common third parties and this is a trend of at least over two years. The longer a certificate is valid: the more likely a collision will occur.

  • This common thread indicates that certificates are avenues for law enforcement and research.

The common thread between actors can be investigated by law enforcement by coordinating with Certificate Providers who are issuing certificates to impostors. Reviewing transactions performed by these impostors will lead to multiple malware actors. Researchers can also use the common thread for identifying known, unknown, or undetected malware by following certificates.

Post Script

Hello dear reader! Thanks for making it all the way down here. This section is to include tidbits that were interesting from the research that didn’t make it into the presentation.

  • From the 698 binaries and 50 certificates reviewed, no legitimate files belonging to the organization listed on the certificate were ever observed. Further providing evidence that the certificates were not stolen.
  • The certificates were sometimes used to sign benign goodware, most likely to be leveraged for malicious use. One such instance was a libcurl.dll.
  • One imposter infected themselves with the Neshta virus and uploaded infected copies of Chromeloader. As a result, the certificate was still observed by VirusTotal, but the file was flagged as “Not Signed”: this is due to how Neshta encapsulates the binary and its own header is read by VirusTotal. Similar behavior has been seen by Ransomware affiliates: that is, during an intrusion they deployed programs infected by Neshta. Was their certificate signing impostor infected with Neshta? Who know?! Maybe!

One thought on “Certified Bad

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: