Trend Micro Incorporated: Scanning SSL / TLS Certificates Used by Malware

0

In recent years, malware has increasingly resorted to encryption to help mask their network traffic. This makes sense, especially when you realize that ordinary network traffic is also increasingly encrypted. Google’s own Transparency report notes that HTTPS traffic now constitutes the vast majority of network traffic passed through the Google Chrome browser.

Over the past six years, we’ve seen basic malware and targeted attacks make heavy use of encryption. This is done to evade detection as well as to blend in with normal encrypted traffic. Besides malware, intrusion frameworks like Cobalt Strike, Metasploit, and Core Impact also use it. In many cases, this use of certificates extends to the use of X.509 certificates, which are normally used by SSL / TLS.

Our technical sheet, entitled The status of the use of SSL / TLS certificates in Malware C&C communications, reviews certificates used by various malware families. We will highlight some interesting features and observations about said certificates, as well as detection techniques for rapid recognition of these certificates. Detecting malware command and control (C&C) traffic at the certificate level is crucial in order to stop malware as early as possible, especially if proxy decryption is not available.

This blog will review some of the unusual characteristics of certificates used by malware and how they can be used to detect malicious activity. We were able to review 1,767 certificates that had been used by various malware families, details of which can be found in the tech note.

Signature of certificates

Signs of potential malicious activity begin with the way the certificates in question are signed. Of the certificates we reviewed, 60% were self-signed. This in itself should be an important red flag. The name of the organization in the certificate itself also frequently provides warning signs: 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 organization name used when OpenSSL creates certificates.

The validity of certificates can also vary considerably. Currently, browsers generally accept certificates valid for a maximum of 13 months, and certification authorities generally issue certificates valid for shorter durations.

Malicious certificates generally obey this rule, although some do not. We have come across certificates with validity periods ranging from one month to several years (including some samples valid up to 99 years). For example, Gozi has consistently used a 10-year validity period in its certificates from 2018 until today.

Pinning the certificate

Certificate pinning is a method by which a client (a browser or, in this case, malware) restricts the number of valid certificates for a specific website, instead of simply accepting any validated certificate. This is a method that some websites and browsers use to secure their traffic, but it shouldn’t be surprising that malware has adopted it as well.

The use is not yet particularly common, but some families are known to use it extensively. These included Iced ID, AsyncRAT, DcRAT, Vawtrak and PhantomNet. It should be noted that currently all of these malware families use self-signed certificates, so they could be detected through this 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 certification authorities

Although we noted previously that most malicious certificates are self-signed, a significant number of them are issued by well-known certificate authorities, as shown in the table below. The table shows the number of malicious certificates signed by each certificate authority.

Certification authority Certificates issued

Let’s encrypt the authority X3

458

COMODO RSA domain validation secure server CA

41

RapidSSL Certification Authority

19

AC EssentialSSL

18

CPanel Certification Authority, Inc.

13

Others

26

Table 1. Trusted Certificate Authority (CA) certificates used by different malware families

Several malware families are frequent users of these certificates. Gozi used 150 of these certificates, followed by 61 for QNodeService, 29 for BazaLoader, and 28 for ZLoader. Regarding the validity of these certificates, we found that no certificate for a malicious domain was renewed after the three month validity period offered by Let’s Encrypt. For a few domains, however, we found different certificates for the same domain.

Policies regarding malicious domains and issuance of certificates vary from CA to CA. Let’s Encrypt, in particular, do not believe that certification authorities should control the content of domains. With TLS enabled by default on all domains, encryption would be an essential feature of all network traffic. Apart from his opinion on this position, it complicates the procedures of defense of the network.

Conclusion

Normally, encrypted SSL / TLS traffic prevents detection of malware C&C communication traffic. However, by examining the certificates used, we can still detect this traffic and create IDS / IPS signatures / filters that attempt to detect different families of malware at the certificate negotiation level. Additionally, it provides new information that threat investigators can use to detect potentially malicious traffic.

You will find complete information on these techniques in the technical sheet.


Source link

Share.

About Author

Comments are closed.