Digital Certificates - Models for Trust and Targets for Misuse 5

In the previous blog, we talked about self-signed certificates and how they can be abused for impersonation attempts. Since this is the easiest spoofing technique and the single node in the certificate chain looks somewhat suspicious, more advanced actors started signing their malware with spoofed certificate chains.

To automate the whole process, different actors have been developing tools (e.g. Apostille) that can spoof entire certificate chains and automatically sign applications. But most of them didn’t pay much attention to the details and because of that signature validation fails with tools like OpenSSL. Certificate forgery is a more sophisticated method, as there is more to it than just ripping off subject and issuer fields and pasting them into new x509 objects. The signature will look valid to the naked eye, but the whole validation process will complete with errors. In order for the certificate chain to be valid, proper extension fields have to be added during the signing process. For example, when issuing intermediate or root certificates which will be used for code signing, the “X509 Key Usage” extension has to contain “Digital Signature, Certificate Sign” flags.

When digitally signing PE files, the leaf and intermediate certificates are usually embedded into the binary. This way, enough information is provided for others to validate the digital signature. The validation process starts in the leaf node and will traverse through the chain, all the way up to the root. Each node goes through a predefined validation process, where one of the steps is checking the link to the parent through the issuer name field. What actually happens is that the parent certificate tries to validate the signature with its public key. If the current certificate really was signed by the issuer’s private key, the validation will succeed. If the whole process is done right, it is possible to craft a forged certificate chain, up to the root certificate.

We will cover the following types of certificate forgery:

• Certificate chains only referencing the root
• • referenced root exists in local trust store
  • referenced root missing from local trust store
• Certificate chains with embedded root

Missing root certificate from trust store

In this case, the signed binary will appear as “Untrusted”. This doesn’t mean it’s necessarily malicious or bad. It is perfectly normal not to have all root certificates on the planet. All major operating systems ship with a predefined set of trusted root certificates. Since the majority of certificates are issued by one of those trusted certificate authorities, an untrusted chain should raise some red flags, as it shouldn’t happen in most cases. These files shouldn’t be trusted unless it is specifically mentioned by their publisher that they ship their own root certificate that should be added to the trust store. Usually, this is the case with banking applications which are shipped with custom certificates issued by local certificate authorities.

Generally speaking, this is a great state to be in for malicious files: legitimate certificate chain with a missing root in the trust store. This will most likely go under the radar of most users and will end up executing on the victim’s machine. One could argue that antivirus solutions should detect this regardless, but digitally signed files still manage to avoid most solutions, which will be showcased at the end of the blog.

Figure 1 - Embedded certificate chain without the root

Root certificate exists in trust store

This is mostly the same as the previous scenario, but it could be approached differently from the technical side. The previous case can’t be detected automatically because it would generate too many false positives. When the intermediate certificate references an unknown root, it is impossible to know if it’s made up or just missing from the trust store.

With a predefined trust store which contains most common root and intermediate certificates, it would be possible to automatically detect forged certificate chains that claim to be issued by trusted vendors.

Let’s take a look at an example where the binary claims to be signed with certificates from Microsoft. The basic validation process would just check if the whole chain can be verified, but what if it would also check if those certificates match entries in the trust store? This is a clear indicator someone is trying to fake a digital signature. ReversingLabs Titanium Platform does additional checks based on an in-house certificate whitelist. By checking if the signer certificate matches entries on the whitelist, it is capable of detecting forgery attempts.

Embedding the root certificate into the binary

Ok, but what if the root certificate is also embedded within the binary by signing it with the entire certificate chain? Will this trick the validation process? Not really, as it will still try to validate all the nodes, even the root node, and fail if the root certificate exists in the trust store. The entire digital signature will be flagged as “Self-signed” as the root certificate cannot be validated. On top of that, if the leaf certificate matches an entry on our whitelist, it will receive the “Impersonation” tag as well. On the other hand, a sample with an embedded root certificate is suspicious on its own, as it is not that common.

Figure 2 - Embedded certificate chain including the root certificate

Different variations of certificate forgery described in this blog post are detected by the Titanium Platform. In order to protect our users from this kind of threat, samples abusing this technique will receive a “cert-impersonate” tag and be classified as "Certificate.Impersonation".

Signed malware and the impact on anti-virus solutions

Earlier in the blog, it was mentioned that signing malicious files can potentially help to bypass antivirus detection. Research on this topic exists for quite some time, and it is surprising that digital signatures still have such an impact on malware detection rates. Before digging further, it should be mentioned that the PoC was done using cloud scanners that act differently from end-point engines (EPP). Cloud scanners lack features that EPP have (e.g. behaviour analysis, execution flow monitoring, network monitoring, etc.), which probably had some impact on the results.

As a Proof-of-Concept, Microsoft’s certificate chain (which signs the “explorer.exe” application) was cloned and used to sign different types of samples and advanced malware, such as: Greyenergy, HakunaMatata, and Anatova. Surprisingly, many scanners suddenly changed their classification status (from malicious to no detection) when processing signed executables. In some cases, the detection rate was lower by 50%, and even some major companies didn’t detect the malicious file. The following graph demonstrates the impact digital signatures have on anti-virus detection engines.

This article is the 5th 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 4: You are you, but so am I - certificate impersonation
• Blog 6: A new kind of certificate fraud: Executive impersonation