Quick abuse reports with certReport

Summary: The purpose of this blogpost is to formally introduce the certReport tool. The blog post will explain the tool’s function and give examples as to how to use it.

If you are completely new to code-signing certificates, consider reading my previous blog posts on impersonation to obtain certs and certificate reuse.

A story

When I started as an analyst, I found a malware that had low detection scores. The low score made me disappointed.

I wanted to find a way that I could negatively the malware’s chance of success. As I studied the options available to me, what stood out to me was the code-signing certificate. I had been surprised to see the malware was signed. (I was new, this form of trust abuse was unknown to me.) Yet, as I looked into understanding code-signing certificates, I found that if the certificate became revoked—multiple systems like browsers and operation systems— would respond to the malware differently possibly preventing its download or execution.

I reported the malware to the certificate provider—giving them the file hash and little more. I was pleased with myself that I had reported the certificate. However, they responded telling me that the file was benign and the certificate was going to stay. It was at this time I realized I had failed to be helpful. Just as antivirus systems struggled to find malicious indicators, the systems and processes that the certificate provider relied on failed to find them as well. I didn’t know good ways to report certificates.

I responded to the provider providing them much more detail about the behavior and pleaded with them to look again at the behaviors I had identified. With the information I provided them, they confirmed the certificate’s abuse, and revoked the certificate.

As I continued to track the malware. I continued to report certificates. I continued to improve how I reported the certificates. After writing more than 100 certificate revocation requests, I was ready for automation.

certReport

certReport is a tool to generate the reports that I used to write. Its ultimate goal is to make creating the reports as low-effort as possible for the analysts and ensure that certificate providers have the information that they need to action the reports.

As it turns out, I’m not the only lazy person. It is normal for analysts to submit bad reports just like I did at first, but certReport is here to help stop that.

Let’s look at the reporting of a certificate together as a way to learn to use certReport.

At the time of this writing, the file hash 22aee22dda57ee1891a90019d4e84a173c73dcdc12f74d0064c6439fb4f4c81d has a score of 36/74 detections. Looking at the details page, we see that VirusTotal indicates that the file is “Signed” with a “valid signature” as depicted below.

Looking at the community notes, we see that multiple “Collections” and “Comments” indicate that the file has been identified as Socks5Systemz malware.

Note: If you can’t see “Contained in Collections” in your version of VirusTotal, you should log into an account. With free VirusTotal accounts, you get a bunch of additional information—if this is news to you, I recommend for you to check out my free VirusTotal course at KC7Cyber. The course is a great introduction to VirusTotal and introduces elements that are visible when logged in. It can level up your VirusTotal skills substantially.

In the community comments, some of the commenters have shared sandbox reports—many of which identify the malware as Socks5Systemz. For me, the analysis appears to consistently indicate that this certificate is being abused: we can report this certificate.

To report the certificate with certReport we have two options. First, we can use VirusTotal’s API, or, second, we can use MalwareBazaar’s API. Each option has their own benefits.

Note: It is necessary for the file to be available on VirusTotal or MalwareBazaar. There is no “offline option”. The reason is that the file must be available to the certificate provider: the file’s availability on one of these platforms ensures that the provider has access to the file.

VirusTotal API

With a free VirusTotal account, you, unfortunately, only get 1 API call per-day. You can use this 1 API call to generate a report. But the VirusTotal option works best for users with access to a paid access to VirusTotal through an employer or another means. Free users may need to rely on the MalwareBazaar option explained in the next major section.

To generate a report, a user needs to install certReport. This should be done with PIP, the Python package installer:

pip install certReport

Once installed, I recommend running a normal command to generate a report like this:

certReport -s VT -# 22aee22dda57ee1891a90019d4e84a173c73dcdc12f74d0064c6439fb4f4c81d

The -s VT command indicates that you want to use the VirusTotal service. The -# indicates that you are passing in a SHA256 filehash. It will provide you the following information on setting up your API key:

Please set your VirusTotal API key by running the doing the following:
    On Linux:
        echo "export VT_API_KEY=your_api_key_here" >> ~/.bashrc
        source ~/.bashrc

    On Windows:
        setx VT_API_KEY "your_api_key"

    On MacOS:
        echo "export VT_API_KEY=your_api_key_here" >> ~/.zprofile
        source ~/.zprofile

This will allow you to store your API key in the way appropriate to your operating system. This will make it available for future use. You can then run the command again and it will generate the following report.

Before we go any further, lets think about what we did:

We just produced a 5 paragraph report by providing a file hash.

I have found it difficult to make it any easier than that.

At the end of the report, it tells you where to send the report, so all you need to do at a minimum, is send the report to the destination provided to submit the revocation request.

With this tool, it makes it really easy to report certificates for known bad. (Determining for sure that something is bad is outside of the scope of this blog post. However, I recommend my VirusTotal course as a crash-course in sifting through VirusTotal reports.)

Lets look at the elements of the VirusTotal version of the report.

Intro

The report is polite but gets straight to the point: it identifies the problem and provides a direct link to the sample for the provider to investigate and validate your findings.

Signature details

While these details can be less interesting to analysts, this section contains the most important details a provider needs: the serial number and thumbprint. With these details, the provider is able to connect the certificate with the exact customer.

These details can help provide you, the reporter, with a sanity check: sometimes certificates may be revoked, or may be expired. These details can help you and the provider know the exact status of the certificate.

VirusTotal Report Overview

This section provides some quick information about the file, such as its file type and general behavior. It will also provide basic information such as how many systems are detecting the file as malicious and what names (like “trojan” or malware family names) are explicitly assigned by detection engines.

Community Detections

The following section serves two purposes.

First, it collects any information that the community has contributed to VirusTotal. By default, any high severity YARA rules, Sigma Rules, and IDS rules that the community has contributed, will be listed in this section. These details can be observed by users logged into a free VirusTotal account or a paid account. With paid accounts, the user may also see when VirusTotal can extract a malware configuration, as in the example above.

Second, if you have any observations about the malware, this is a great place to write those details before submitting the report. In many cases, I report malware which is signed and has few or no detection engines, as a result, the report will be bare. However, this section gives me the opportunity to explain what behavior I observed such as how the victim got the malware, anti-analysis that I observed of the malware, and any other reasons as to why I believe it is malicious. If you have information about the file’s malicious behavior, there is no reason for you to hold back on it: share what you can to help the provider make a decision to act on your report.

Signature

The report finishes by politely offering further help if needed.

Finally, under the separator, certReport will tell you where the report should go. If it does not provide a email or web form for submission, be sure to verify that it is not a self-signed cert. If it is not a self-signed cert, consider submitting a pull-request to add support for that additional certificate provider.

MalwareBazaar API

Unlike the VirusTotal API usage, no API key is required. The downside of using MalwareBazaar is that the file with the signature that you wish to report, may not be on MalwareBazaar unless you upload it. However, I encourage you to consider uploading malware to MalwareBazaar. Any malware you upload will be automatically fed to multiple sandboxes, uploaded to multiple other repositories, and downloaded by hundreds of automated systems. By uploading, you are benefiting the whole community in addition to making it possible for you to generate a report using the API.

To use the MalwareBazaar option, install certReport using PIP, the Python package manager, if you haven’t:

pip install certReport

And then pass the file’s hash in the commandline:

certReport -# ed87fab7cf5d8a467f442560c85904ec7c41926536477ae10779b27a2e4b3e9a 

certReport defaults to using MalwareBazaar as the default service for generating the report. The -# option indicates that you are passing in a SHA256 file hash. One you do so, the following report will be generated:

Once again, we generated a multi-paragraph report by providing just a file hash and the report.

It is difficult to make this process easier. I strongly encourage the use of this tool to report certificates that are known to be bad.

Lets look into the elements of the MalwareBazaar version of the report.

Introduction

The report starts off polite and gets straight to the point: it states clearly what was found and gives the provider a direct link in order to validate your findings.

Signature Details

While this section isn’t as interesting to analysts, it provides the essential details that the certificate provider needs to for their investigation: the certificate serial number and thumbprint.

MalwareBazaar Report Overview

Samples uploaded to MalwareBazaar will be tagged by users or by automation: these tags are provided at the top of this section. Samples are also automatically uploaded to several sandboxes. At this time, certReport only pulls information from a few sandboxes: these are sandboxes with a public link to the sandbox analysis. These links allow the provider to get more information about the analysis as needed.

Before the sandbox reports, there is a bit of open space. This is a great place to write your own findings. In many cases, I report malware which is signed and has few or no detection engines, as a result, the report will be bare. However, this section gives me the opportunity to explain what behavior I observed such as how the victim got the malware, anti-analysis that I observed of the malware, and any other reasons as to why I believe it is malicious. If you have information about the file’s malicious behavior, there is no reason for you to hold back on it: share what you can to help the provider make a decision to act on your report.

Signature

The report closes politely. It is good to always offer more help if it is needed, or if you have more details to provide them in the report. It is unlikely for a provider to reach out for additional information, but you should be open to it if needed.

The report finally provides you information about where to submit the report. If it does not provide a email or web form for submission, be sure to verify that it is not a self-signed cert; if it is not a self-signed cert, consider contributing to the project to add detection for that certificate provider.

But wait there’s more

certReport makes reporting easy, but it also makes documentation easy.

If you followed along with the example above, certReport also documented the certificate on your local hard drive.

When you report a certificate for the first time, certReport makes a directory in your user directory named certReport, within that directory is a SQLite Database certReport.db (I recommend using DB Browser for Sqlite for viewing the file). This database keeps track of the most important elements of your report allowing you to (1) store the data for later reference and (2) track malware family certificate usage.

A user is able to track malware by either manually modifying the “user_supplied_hash” in the database or using an option to tag the entry when generating a report: -t <malware name>

When using the tag, the report generation will also check the database and surface information about the number of times that the malware has been reported. For example, the report may surface something like this:

This feature allows a researcher to keep track of certificate abuse over time.

Frequently Asked Questions

Q: Do certificate providers actually process revocation requests efficiently?

A: Yes! Certificate providers take these reports very seriously. Most of my reports are processed within a day, but it is common for reports to be processed even faster. This tool helps ensure the provider has the initial information they need to make a decision. I’m not the only one seeing this benefit either: Tony Lambert, aka ForensicITGuy, and others have reported that these reports get addressed quickly.

Q: Does reporting certificates really make an impact?

A: Yes! Revoking certificates can disrupt malware distribution processes and build processes. Certificates are also expensive, and may cost between $1,000 – $3,000; revocation can make an attacker second guess this strategy. Further if you don’t revoke certificates, they will be reused to sign other malware.

Q: Should I submit requests using my real name? Will they take me serious if I use a pseudonym?

A: Certificate providers only know my as “Squiblydoo”. When you submit a report, they take the report itself seriously and perform an investigation confirm your findings. Your identity is not particularly important here.

As a word of caution: We have seen at least one instance where a certificate provider provided one of their customers the email address of the reporter. The customer was disputing the revocation of the certificate and the provider likely meant well, however, this type of disclosure puts reporters at risk. Someone using their real name would have their identity exposed to a criminal for reporting against them. My recommendation is to use a pseudonym to avoid this risk.

It is my guess that sharing information about a reporter is more likely to happen if the provider has doubts. As a result, the clearer the malicious activity, the less likely this exposure may happen.

Make an impact

If you use certReport, please tag me in social media when you do: this raises awareness of the tool and also raises awareness around abused code-signing certificates. You can tag me on Twitter or Mastodon.

If you would like to get more involved, consider joining my Discord: click this link to join. We use automation to find new certificate abuse and report it. It is a good way to develop investigative skills and make an impact.

Finally, we need more research and publication on certificate abuse. Consider using certReport to empower your own investigations and documentation.