In this case, the assumption that the threat actor was directly issued certificates through abuse of the certificate issuance process is more strongly suspected than the stealing of the private key, but the protection of private keys on the user side is still a challenge.
In the use of code signing certificates, private key protection on the user side has been enhanced over time, but it still has a long way to go before it can be classified as foolproof.
As mentioned above, we can see in QAKbot a function to retrieve victim’s private keys using the PFXExportCertStore() API, which can only export private keys if they are stored in the Windows Certificate Store with an exportable flag. In other words, if key generation was performed using a hardware token that meets certain criteria (IC card, HSM, TPM, etc.), the private key is not stored in the Windows Certificate Store, so no method is provided to export and reuse the private key since it is stored within the token.
There is a document, “Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates(v.3.1)” that defines things related to code signing certificates. This document is followed by CAs that issue code signing certificates and require CAs to encourage users to use tokens that meet the criteria to protect their private keys. According to this, prior to November 15, 2022, CAs must recommend to users that they protect their private keys with hardware tokens that meet the criteria and must obtain a representation from the user that they will protect their private key by using certified hard tokens or at least in a way to keep the key physically separate from computers until a signing session can begin.
So far, we have confirmed that many companies that sell certificates for code signing issue them in a way that the key is stored on a smart card or other hardware device basically in which case the private key cannot be exported remotely.
Even though everyone knows that hardware key generation provides stronger protection, software key generation that allows easy backup in the type of PKCS#12 files without the use of hardware tokens has remained popular on the user side. Some certificate issuers continue to provide this method as an option by to this day. As the last mile of protection, if the user actually imports it into the token and keeps it offline, it is left to the user themselves.
The scenario in which active abuses by threat actors are continuously observed is required to rethink the key generation and certificate issuance methods. The baseline requirement will have stronger requirements for private key protection starting November 15, 2022. According to the Baseline Requirements, the CAs “shall” ensure the user’s private key generation with a suitable hardware after the date. While this is a step forward compared to the scenario in which the last mile is left to the user, the day when private key storage in software is no longer common may still be a little further away.
In the previous sections, we mentioned the possibility of abuse of the certificate issuance process, which includes identity theft. The problem that a threat actor may impersonate a real organization then being issued a certificate directly can also happen in WebPKI, which gives TLS certificates used for HTTPS communications.
WebPKI has introduced Certificate Transparency(CT) since around 2015, which means that the issuance of all public trusted server certificates used for HTTPS is logged in the CT logs in public. This allows the CT logs to be verified by anyone from the internet and helps detect the issuance of certificates that the domain name owner is unaware of.
Thus, while WebPKI can use the CT logs to check for unexpected issues of certificates for organizations, however, code signing certificates cannot be checked in the same way because the CT mechanism has not been introduced for code signing certificates.
To counter the abuse of certificates that have already been issued, the one of the options is to revoke the certificates.
According to research made by Doowon Kim and Bum Jun Kwon in 2018 titled “The Broken Shield: Measuring Revocation Effectiveness in the Windows Code-Signing PKI,” even if a code signing certificate is revoked, the signature may remain valid due to the specifics of the revocation and verification method, which is a mechanistic challenge.
All certificates observed to have been abused in this case have been revoked at this time.
For users:
First, protect your private keys. The people who perform code signing store their private keys for code signing certificates using modern best practices. The private key is stored with the appropriate hard token and stays offline until just before the signing process begins. Modern practice also provides a service to store private keys and sign in the cloud.
Second, protect your identity. While the origin of the abused certificate is currently unknown, victims may have been impersonated in the name of the company completely unknown to them, and the certificates issued to them may have been abused. Thus, it would be imperative if we could carefully monitor for strange things happening around us related to identity theft. It will take some time for things to unravel but protecting yourself while the certificate issuers figure out why this is happening will be key to avoiding abused certificate issuance.
It is possible that the threat actor has acquired a domain name similar to the company name of a real company and is using the fact that they own the domain name to get a certificate issued. Unfortunately, there is currently no effective way to check this case since unlike WebPKI, CT has not been implemented for code signing certificates.
Detection and monitoring of abuse of trust
Security teams need to be aware that an abuse of trust has been observed. Since a valid code signing is not enough to determine that a module is benign, it might be needed to check things closer, to be assured that the one with a valid code signing is not a malware impersonating a legitimate module.
The certificates confirmed to have been abused in this case had the following attributes:
- Had company names unrelated to technology
- Issued to micro-companies around the world
- Used a free email service for its email address
- Used an email address that contains a domain name that looks like a company name, but the domain name does not host any content
- The top-level domain of the domain name used is not common for enterprise, like “co”
- Assigned a new IP address just before the certificate was issued
Fortunately, these certificates can be figured to be unusual if they are carefully checked.
Conclusion and Trend Micro solutions
QAKbot is trying to evolve into a much more intrusive malware. Its use of valid code signatures can make it hard to determine which files are real, and its persistence can cause further danger to machines and the network that it is connected to while the certificate issuers find a way to counteract what the trojan is doing.
Since QAKbot can originate from an Excel file, make sure that macros are disabled in Microsoft applications. In addition, check the sender and the format of the email address to prevent email spoofing. For further protection, install Trend Micro Deep Discovery, which contains an email inspection tool. For endpoints, Trend Micro Vision One can detect possible persistence since QAKbot drops in via .DLL files.
With additional insights by Byron Gelera.
