Digital Certificates – Models for Trust and Targets for Misuse 4

Self-signed certificates have a bad reputation and are generally viewed as unsafe, but what most don’t realize is that legitimate use cases do exist. For example, root certificates in every certificate chain are self-signed and issued by certificate authorities. A certificate authority (CA) is a trusted entity that issues digital certificates with specific use cases, ranging from code signing to encrypting internet traffic (SSL).

Larger organizations sometimes act as their own certificate authority and issue SSL certificates for internal usage. The main reason for this is because it's free, and the organizations don't see any problem with it. Since those certificates are not trusted by common web browsers, a validity warning will be displayed, unless the certificates are manually added to the browser’s trust store. However, in case of a man-in-the-middle (MITM) attack, the same warning will be displayed and the user won’t be able to see the difference. Therefore, it's arguable whether self-signed certificates can provide any kind of integrity checks within such environments.

Besides SSL certificates and MITM attacks, code signing certificates are abused for digitally signing malware in hope of bypassing antivirus engines. Digitally signed files appear safer to most users, making them more likely to run such files, especially when the certificate information appears to be legitimate. That is why, in order to make signed executables more realistic, attackers started impersonating big company certificates (such as Google and Microsoft) by copying their common name, serial number, validity dates, extension fields, etc.

Certificate impersonation occurs when a third party tries to imitate other well-known certificates and use them to digitally sign their own software. Impersonated certificates can be easily crafted with software like OpenSSL, and the whole process can even be automated. The intention is to trick users into thinking that they are running a legitimate application from the company that is being impersonated.

Figure 1) shows two “User Account Control” (UAC) warnings.  In order to protect users from such applications, Windows will show a UAC warning, informing them about the file’s signature before they actually run it. Keep in mind that users can disable those warnings, and most of them do, to avoid being "annoyed" by the warnings all the time. The blue UAC warning dialog indicates the publisher is trusted by Windows. The yellow UAC warning dialog informs the user that the signature is not explicitly trusted by Windows. This should be enough to raise suspicion that the signature could be fake. Additional details can be checked in the “Digital Signatures” tab of the file’s Properties dialog. The general view will show detailed verification messages about the digital signature.

Figure 1) - User Account Control warning dialog on Windows

Figure 2) shows a side-by-side comparison of a legitimate certificate by Google and an impersonated one. Although the impersonated certificate has all the information copied from the original one, the root certificate wasn't able to verify the certificate with its public key, since the generated key pair for the impersonated one is different. This is the only information that cannot be spoofed, and the only way to truly check if the certificate was issued by the CA.

Figure 2) - “Properties > Digital Signatures” tab on Windows

On the other hand, the ReversingLabs Titanium Platform will classify certificates based on their properties. As mentioned in one of our previous “Building Secure Certificates Whitelists” blog post, certificates are validated and assigned one of many possible states, such as “Self-signed”, “Impersonation”, “Forgery”, and more. Some validation states can then be nuanced further based on the certificate's contents.

For example, a self-signed certificate is a certificate that is signed by the same entity whose identity it certifies. If the subject name matches a whitelisted entry, it will be tagged as impersonation. Furthermore, if the entire chain is spoofed, it’s tagged as forgery. At ReversingLabs, we continuously monitor our Certificate Feed for anomalies. The Certificate Feed is a customer-accessible API that contains information on all signed files that step foot in our environment. This wealth of information allowed us to discover a sample with a low detection rate by antivirus scanners that was signed with an impersonated certificate.

Figure 3) - Titanium Platform A1000 detecting certificate impersonation

Before we jump into sample analysis, it’s worth mentioning that such samples could also be found via the Titanium Platform. Its advanced search feature allows us to query the metadata by combining different tag keywords. A search for a single keyword - “tag:cert-impersonate” - will return all samples that satisfy the certificate impersonation criteria. Adding more keywords to the search query returns more refined results, allowing us to find samples that are not classified as malicious, but are pretending to be signed with certificates from big tech companies. Those kinds of samples raise suspicion and should be inspected more closely. In our case, the collected set of suspicious files retrieved from the search was analyzed, and in the end revealed a .NET executable that tries to download and execute a file from a remote location.

Figure 4) - Example  search keywords

Figure 5) - Suspicious .NET sample

In more detail, the sample starts off by "sleeping" for two seconds before opening an FTP connection (1). Interestingly enough, the FTP credentials are hardcoded into the binary without any obfuscation (2). It tries to download a file called “flash.exe” and save it to “C:\Users\Public\flash.exe” (3). After downloading the second-stage payload, the sample will attempt to execute it (4). Regardless of whether the execution was successful or not, as a last step, a message box will open, displaying an “error”: “Error installer .NET 4.5 is not installed.” (5). Unfortunately, by the time our manual analysis took place, the server wasn’t online anymore, which made the second-stage payload unavailable for analysis.

Figure 6) - Malicious .NET sample

The same sample also appeared in our Certificate Feed API, which offers real-time certificate-related data. This allows ReversingLabs to setup continuous monitoring for new samples signed with impersonated certificates, and much more. Thanks to the rich set of data provided by the API, we’ve also been able to capture samples with entire certificate chains spoofed. We will cover those samples in more detail in the upcoming blog posts.

This article is the 4th part of our Digital Certificates series of blogs. Read other blogs in this certificate series:

• Blog 1: Building secure certificate whitelists
• Blog 2: Trust-based models in the age of supply chain attacks
• Blog 3: Tampering with signed objects without breaking the integrity seal
• Blog 5: Subverting trust with digital counterfeits
• Blog 6: A new kind of certificate fraud: Executive impersonation