Certificate authorities sell different kinds of code-signing certificates that satisfy different needs and cost anywhere between hundreds and thousands of dollars per year. The stringency of the validation process depends on the type and nature of the certificate, with “Extended Validation” certs requiring more extensive proof of the requestor’s identity than less expensive certs.
Despite the issuers’ validation procedures, we routinely detect malware that’s signed with legitimate code-signing certificates. Fortunately, there are many ways to differentiate suspicious or malicious signed binaries from legitimate ones, and we’re going to share some of our strategies for analyzing digital signatures.
Anatomy of a code-signing cert
Most certificates will include some variation of the following information:
- Name (or subject name): The name of the person or company that developed binary
- Issuer: The name of the certificate authority that issued the certificate
- Valid from/to: The time range in which the certificate remains valid
- Serial number: A unique identification number tied to the certificate
Below we share a VirusTotal screenshot with the contents of a suspicious certificate to show you what the above fields look like in the wild. We’ll examine the contents of this certificate a little more closely throughout the rest of this blog.
Other metadata included with a signed binary may include:
- signature status
- copyright information
- descriptions, internal names, and original names
- versions
- signing date
- signers
Spotting suspicious signatures
The following is a side-by-side comparison of a suspicious and legitimate certificate as seen on VirusTotal (links included below). On the left is the signing metadata for a Microsoft Teams installer, since this is what the D3F@CK loader example appears to be masquerading as. On the right is the signature metadata for the D3F@CK loader sample (this is the same certificate as the “Neural Code Technologies” example above).
File version information from VirusTotal
One important element to differentiate good and bad certs is the signing certificate’s history. We’ll start by looking the history of our legit binary, the Microsoft Teams installer referenced above, information that you can find in the “details” tab for binaries in VirusTotal:
VirusTotal binary history section for Microsoft Teams installer
As you can see, this binary has been around for a number of years. The timeline mostly makes sense with the creation of the binary preceding the time at which it was signed by a reasonable amount. That the binary was first seen in the wild prior to its creation time is confusing but not unusual, and could be the result of developers testing the binary in the wild prior to getting it signed, delays in obtaining certificates, or a variety of other reasons. On the whole, there’s nothing in this history that stands out as a red flag.
Now let’s compare that to a suspicious certificate associated with a binary named MC Teams.exe:
VirusTotal binary history section for D3F@CK loader
The most important distinction for this binary, on the other hand, is that it has not been around very long at all. Obviously, not all new binaries are malicious, but a recent creation time can be a leading indicator of malice, especially when it claims to be an installer for a well-established application like Microsoft Teams. While it’s not the case here, suspicious signing histories sometimes include tightly coupled creation times and signature dates, and they are first seen in the wild within minutes or seconds of these.
Further, while the various internal names associated with the binary seem to be masquerading as Microsoft Teams (e.g., MC Teams.exe, etc.), the signer is “Neural Code Technologies Inc.” and not “Microsoft Corporation,” the expected signer for the real Microsoft Teams installer.
VirusTotal binary signing data section
For comparison, here’s the corresponding signer information for the legit Microsoft Teams installer:
Note: We were not able to determine why this certificate’s status is not time valid, but we validated that the binary was trusted on a Windows endpoint. This behavior of bypassing some certificate times is frequently observed in our experience, and appears consistently across VirusTotal for binaries signed with this certificate.
Assessing bad behaviors
Defenders should also assess the behavior of a binary and compare their expectations of the binary based on the claims in the certificate. Using the above example, the first thing to consider is whether or not the binary is behaving the way that you’d expect a Microsoft Teams installer to behave. Beyond that, examine any additional binaries that it creates and analyze their signature metadata and their behaviors as well.
The example we’ve been referencing came to us from actual detections. The first important behavioral evidence suggesting this activity might be malicious is that it’s downloading a purported Microsoft Teams binary from a domain that does not appear to be associated with Microsoft:
It also leveraged the Java Windows app (javaw.exe) to make a network connection to a Pastebin site, which seems suspicious for a legit Microsoft Teams installer:
Do your own research
Search engines can be an analyst’s best friend, and, at the risk of stating the obvious, a simple internet search can go a long way toward vetting the legitimacy of a binary. Most threats are opportunistic, and there’s a high likelihood that the suspicious binary you’re analyzing has already been analyzed by someone else. Searching for terms from the binary signature metadata (like the signer name, for example) may in fact yield results suggesting that someone else has already analyzed the binary and deemed that it is malicious.
Predictably, both the malicious installer referenced in this blog and the legitimate Microsoft Teams one have been submitted to VirusTotal:
If you see something, say something
If or when you find a signed malicious binary, consider reporting it as malicious, while staying within your incident response program’s operational security guidelines, as this may tip your hand to a more advanced adversary who may be trying to stay within your network. As you can see in the VirusTotal entry for the malicious binary referenced throughout this blog, the signature verification section now notes that while the file is signed with a valid signature, it has since been revoked:
Reporting suspicious certificates will make the bad guy’s job harder and more expensive because they’ll have to purchase new signing certs and re-sign their binaries. Every reputable certificate authority has a relatively simple process for reporting fraudulently signed binaries. In your report to the certificate authorities, you’ll want to include the certificate thumbprint or serial number. You’ll also want to explicitly explain why the binary is suspicious or malicious to help the certificate authority perform a thorough investigation.
Certificate or signature metadata is an important piece of the puzzle to consider when analyzing a potential threat.
Ultimately, certificate or signature metadata is an important piece of the puzzle to consider when analyzing a potential threat. Sometimes the information contained within a certificate is sufficient to verify whether a binary is benign or legitimate. Other times this information plays a supporting role along with alerts or behavioral evidence. In either case, it’s worth familiarizing yourself with the signature metadata and knowing where and how to find it.