Regular readers of the Symantec blog may sometimes read blogs that mention a fraudulent file that is signed with a valid digital certificate or that an attacker signed their malware with a stolen digital certificate.
You may recall that the creators of Stuxnet, arguably the most notorious malware in history, signed it using the private keys of valid digital certificates of well-known companies.
Digital certificates are significant because a file with a digital certificate can be checked to see who authored it and to make sure it was not altered. Moreover, some versions of Windows display a dialog box when a file that has no digital signature is opened. If an attacker signs malware with the stolen private key from a digital certificate, Windows will execute the file in many cases, except if the file is downloaded from the Internet using a Web browser.
How does an attacker steal the private key from a digital certificate?
If a computer is infected by back door Trojan, the attacker may gain full access to the compromised computer and will be able to control it. The attacker will therefore be able to steal any information found on the computer.
An attacker can also steal both the private key and the digital certificate if he or she is interested in them. However, it is very hard for an attacker to check every compromised computer and if the attacker is successful in compromising several hundred computers, the task of checking every single one is made even harder. The more computers that are compromised, the harder the task becomes.
Gathered samples
I tracked malware samples that have functionality to steal both private keys and digital certificates from Windows certificate stores using the operating system’s functionality over a period of a month. During this time almost 800 unique sample files were gathered. The gathered samples consisted of some of the following malware:
- Backdoor.Beasty
- Infostealer.Snifula
- Downloader.Parshell
- Trojan.Spyeye
- W32.Cridex
- W32.Qakbot
- Infostealer.Shiz
- Trojan.Carberp
- Trojan.Zbot
Of those malware samples, many of them were Trojan.Zbot, also known as Zeus.
The following is a world map of all the gathered samples displaying infections by country:
Figure 1. World map displaying infections by country
As you can see, a large number of computers infected by the gathered malware appear to be in America.
How an attacker stores digital certificates
Windows stores digital certificates in a certificate store. Program code often uses the PFXExportCertStoreEx function to export certificate store information and save the information with a .pfx file extension (the actual file format it uses is PKCS#12).The PFXExportCertStoreEx function with the EXPORT_PRIVATE_KEYS option stores both digital certificates and the associated private keys, so the .pfx file is useful to the attacker.
The code shown in Figure 2 opens certificates stored using the CertOpenSystemStoreA function, so it chooses the most common system certificate store.
The PFXExportCertStoreEx function exports the content of the following certificate stores:
- MY: A certificate store that holds certificates with the associated private keys
- CA: Certificate authority certificates
- ROOT: Root certificates
- SPC: Software Publisher Certificates
In the example below, the MY certificate store information is saved with the password “Pass” in .pfx file format. As the PFXExportCertStoreEx function is called with the EXPORT_PRIVATE_KEYS option, it exports both digital certificates and the associated private key.
Figure 2. Example of code exporting certificate store information
The code performs the following actions:
- Opens the MY certificate store
- Allocates 3C245h bytes of memory
- Calculates the actual data size
- Frees the allocated memory
- Allocates memory for the actual data size
- The PFXExportCertStoreEx function writes data to the CRYPT_DATA_BLOB area that pPFX points to
- Writes data
When it writes the content of the certificate store, there is no decryption routine; it just writes exactly what is in the certificate store.
Only one of the malware samples gathered waits for the attacker's command to steal certificate stores. The other malware samples all steal certificate store information when the computer starts running. This would therefore suggest that almost no attackers actually check the compromised computer before stealing the certificate stores.
What password does the attacker use?
In the preceding example (Figure 2), the attacker used “Pass” as the password when writing the certificate store data to a file. Other attackers were seen to use “Password”, “0”, “12345” and so on as the password. What about in the case of Trojan.Zbot?
Figure 3. An example of an encrypted password
The password is encrypted and is unreadable without decryption; the attacker encrypts data to hide it from antivirus vendors.
Figure 4. The _decrypt_password code
The code inside the red box in Figure 4 is the main decryption code. Although the code in the samples varies, all the samples have the same password: “pass.” The attacker obtains the private key from the .pfx file through a batch process and having the same password makes the task easier for the attacker.
The signing process is not difficult
Stuxnet is not a special case. We often see reports that an attacker signs malware using the private key from a stolen certificate.
Microsoft distributes a signing tool bundled with Windows DDK, Platform SDK, and Visual Studio. If an attacker can steal the content of the certificate store, the attacker can then run Sign Tool (signtool.exe) and digitally sign malware. If one knows where to look for the Trojan.Zbot source code, they can get it, configure it, and distribute it. Sign Tool can also be obtained by anyone; technical ability is irrelevant for stealing certificates.
How can private keys be protected?
One way to protect private keys is to create a network for developing software that is completely segregated from the internal company network and to use different passwords for both networks. If malware compromises a computer on the company network, it cannot gain access to private keys.
Developers should also only sign code by using the test certificate until they are ready to ship the software. If digital certificates are stored on a computer that is compromised by malware, the private keys may be stolen.
While storing private keys in a file on a computer is not recommended, there may be situations where it is unavoidable. If so, limit the number of computers that store private keys and restrict access to as few users as possible.
The private key and digital certificates should be kept in a secured location, such as a safe or locked room, and ideally on an encrypted device, like an IC card or a USB token (not a USB memory stick) or hardware security module (HSM). If that is not possible, digital certificates and private keys should be archived and protected by a strong password. Only when absolutely necessary should a private key be stored on portable media and it should eventually be removed from that media and stored offline.
Symantec also offers a service to protect private keys called Extended Validation (EV) Code Signing. More information on EV Code Signing can be found here. If you would like to learn more about security best practices for code signing, please see the white paper located here.
Symantec will continue to monitor the malware and malicious techniques outlined in this blog. We also recommend that users do not run suspicious programs and keep their operating system and antivirus software up to date.