Web
Analyzing SSL/TLS Certificates Used by Malware
We take a closer look at the SSL/TLS certificates used by malware.
Malware has increasingly been making use of encryption to help hide their network traffic in recent years. This makes sense especially when one realises that ordinary network traffic is increasingly encrypted as well. Google’s own Transparency Report notes that HTTPS traffic now makes up the vast majority of network traffic passed via the Google Chrome browser.
In the past six years we’ve seen both commodity and targeted attack malware make heavy use of encryption. This is done to evade detection as well as to blend in with normal encrypted traffic. Aside from malware, intrusion frameworks like Cobalt Strike, Metasploit, and Core Impact are making use of it as well. In many cases, this use of certificates extends to the use of X.509 certificates, which are normally used by SSL/TLS.
Our technical brief, titled The State of SSL/TLS Certificate Usage in Malware C&C Communications, goes over the certificates used by various malware families. We’ll highlight certain interesting features and observations about the said certificates, along with detection techniques for quick recognition of these certificates. Detecting malware command-and-control (C&C) traffic at the certificate level is crucial in order to stop malware at the earliest possible stage, especially if proxy-based decryption is not available.
This blog will go over some of the unusual characteristics seen in the certificates used by malware, and how they can be used to detect malicious activity. We were able to examine 1,767 certificates that had been used by various malware families, the details of which can be found in the technical brief.
Signing of certificates
The signs of potential malicious activity start with how the certificates in question are signed. Of the certificates we examined, 60% were self-signed. This in itself should be a significant red flag. The name of the organisation in the certificate itself frequently provides warning signs as well: some malware families like AsyncRAT and BitRAT include their own malware names in this field, while other malware families use some permutation of “default” or the oddly named “Internet Widgits Pty Ltd,” which is the default organisation name used when OpenSSL creates certificates.
The validity of the certificates can also vary significantly. Currently, browsers generally accept certificates that are valid for a maximum of 13 months, and certificate authorities generally issue certificates that are valid for shorter durations.
Malicious certificates generally obey this rule, although some do not. We encountered certificates with validity periods ranging from as short as one month, up to multiple years (including some samples valid for up to 99 years). For example, Gozi has consistently used a 10-year validity period in its certificates since 2018 up to the present.
Certificate pinning
Certificate pinning is a method where a client (either a browser or, in this case, malware) restricts the number of valid certificates for a specific website, as opposed to just accepting any certificate that is validated. This is a method that certain websites and browsers use to secure their traffic, but it should not be a surprise that malware had adopted it as well.
The use is not yet particularly common, but some families are known to use it extensively. These include IcedID, AsyncRAT, DcRAT, Vawtrak and PhantomNet. It should be noted that currently, all these malware families use self-signed certificates, so they could be detected via that method. However, it is perfectly plausible that this technique could be adopted to use certificates from trusted CAs, which we will discuss below.
Certificates from trusted CAs
While we noted earlier that most malicious certificates are self-signed, a sizeable number of these are issued by well-known certificate authorities, as seen in the table below. The table shows the number of malicious certificates signed by each certificate authority.
| Certificate Authority | Certificates Issued |
| Let's Encrypt Authority X3 | 458 |
| COMODO RSA Domain Validation Secure Server CA | 41 |
| RapidSSL CA | 19 |
| EssentialSSL CA | 18 |
| cPanel, Inc. Certification Authority | 13 |
| Others | 26 |
Table 1. Trusted certificate authorities (CA) certificates used by different malware families
Several malware families were noted to be frequent users of these certificates. Gozi used 150 of those certificates, followed by 61 for QNodeService, 29 for BazaLoader, and 28 for ZLoader. As far as validity for these certificates is concerned, we noted that no certificate for a malicious domain was renewed after the three-month validity period offered by Let’s Encrypt. For a few domains, we did find different certificates for the same domain, however.
Policies regarding malicious domains and certificate issuance vary from CA to CA. Let’s Encrypt, notably, does not believe that certificate authorities should police the contents of domains. With TLS enabled by default across all domains, encryption would be an essential feature of all network traffic. Setting aside one’s opinion of this position, it does complicate network defence procedures.
Conclusion
Normally, encrypted SSL/TLS traffic hinders detecting malware C&C communication traffic. However, by examining the certificates in use we can still detect such traffic and create IDS/IPS signatures/filters that attempt to detect different malware families at the certificate handshake level. In addition, it provides new information that threat investigators can use to find potentially malicious traffic.
Full information about these techniques can be found in the technical brief.