Certificates are valuable resources to threat actors, as their mere presence can reduce the chance of early malware detection. This is particularly true for financially motivated actors. When spreading malware is a business model, ensuring the malware flies under the radar is a top priority. That means acquiring the best digital certificates one can get their hands on, and using them for as long as possible.
Digital certificates allow their owners to digitally sign information in a process that stamps the content with their identity and protects it from tampering. While both of those signature properties are important, the identity behind the origin of information is the one that is used as the key measurement of trustworthiness. That is why threat actors are so focused on impersonating trusted parties.
Certificate authorities, as digital certificate issuers, are the gatekeepers of this system of trust. They represent a mechanism that guarantees the identities behind the signatures are verified. For this reason, it is crucial that the processes they implement to check the identities are resilient to potential abuse - something much easier said than done.
Just like the certificates themselves, not all identity checks are made equal. The difference in the checks performed to issue certificates dictates the overall trust that can be placed in the certificates. When it comes to code signing, certificate authorities issue two types of certificates: code signing and extended validation certificates.
Code signing certificates require basic identity checks for individuals and businesses. The entity requesting such certificates usually provides basic identity information and, through a quick validation process, gets a binary file that contains the certificate itself. The price of those certificates varies from one certificate authority to another, but it is usually a measure of trustworthiness of the authority and their business conduct track record.
Extended validation code signing certificates require a rigorous vetting process for individuals and businesses. The entity requesting such certificates provides detailed, usually legal-document-style identity information that goes through multiple stages of verification. Once the vetting is completed, the certificate authority issues a hardware token as a two-factor guarantee that the signing process is secure. The price of those certificates also varies, but as a rule, there is a significant markup to the baseline code signing price, as deeper checks and tokens are involved in the issuance process.
From the standpoint of customer security and trust behind these two types of certificates, extended validation is by far the better choice.
There’s little threat actors wouldn’t do to appear as legitimate entities. While stolen certificates get a lot of public attention, there’s also a quieter side of the malware business - stolen identities. Sometimes these two can become intertwined.
The following is a complete timeline reconstruction of a successful executive impersonation attack that was used as a vessel to obtain a valid digital certificate. We also illustrate stolen certificate misuse in signing and distributing malicious content.
Phase 1: Reconnaissance
The reconnaissance phase is all about selecting the right target to impersonate. At this stage, the threat actor is trawling through publicly available information in search of viable candidates. A person well-established in their industry, with easily verifiable history is a preferred target. Since the goal is to acquire a code signing certificate, the perfect victim is someone working in the software industry.
This phase can take a very long time, as any candidates found in this initial search will have to be vetted through additional selection criteria. Assuming someone’s identity can happen only if the supporting infrastructure can be made believable enough to fool a certificate authority during the identity verification process.
Phase 2: Selection criteria
Based on collected information, the following person is selected as a viable impersonation target. The following information was scraped from their public LinkedIn profile page.
| Gender | Male |
| Name | [ Redacted.Person ] |
| Estimated age | Estimated to be early to mid 40 |
| Location | London, United Kingdom |
| Education | University in 1998 and an EMBA in 2011 |
| Industry | Information Technology and Services |
| Work Experience | Employment history starting from 2001 With current employer since 2017 |
| Employment | [ Redacted.Company ] |
| Occupation | Co-Founder / Operations |
United Kingdom is the perfect location for this threat actor. Like in other countries with modernized bureaucracy, the company registrar and their ownership structure is a matter of public record. Anyone with a browser can look up the basic information about company incorporation, ownership structure, and solvency. For identity impersonation to succeed, the selected target must be easily linkable to their place of employment. This is something the certificate authority will definitely check during their identity validation process.
| Company type | Private company |
| Company status | Active |
| Incorporation | 2017-30-06 |
| Founder | [ Redacted.Person ] |
| Date of birth | 1976-??-01 |
| Location | London, United Kingdom |
| Address | [ Redacted.Adress ] |
| Business nature | Business and domestic software development Web portals |
Company website registration details are also readily available, as there are plenty of online services that perform WHOIS lookups.
| Domain | [ Redacted.Company ].com |
| Created on | 2016-07-02 |
| Updated on | 2019-07-03 |
| Expires on | 2020-07-02 |
| Country | United Kingdom |
| Registrar | GoDaddy.com, LLC |
The threat actor performs a domain availability check for [ Redacted.Company ].co.uk - the domain name is available. The selected target is a perfect candidate for this identity impersonation scheme.
Phase 3: Infrastructure
Infrastructure building can be a significant effort on the attacker’s side. For this particular attack, building starts with domain registration.
| Domain | [ Redacted.Company ].co.uk |
| Created on | 2019-04-07 |
| Updated on | 2019-04-07 |
| Expires on | 2020-04-07 |
| Country | United Kingdom |
| Registrar | Nominet |
The attacker aims to use the top-level domain confusion in order to mislead the certificate authority during their identity verification process. The gamble is that the person verifying the certificate issuance request will assume that the same company owns both the global .COM and the regional .CO.UK domains for their business.
Here’s where the choice of registrar becomes truly important. Since GDPR legislation came into effect, most EU domain registrars have agreed that WHOIS records are considered private and personally identifiable information. This makes knowing the true identity behind the registered domain name subject to a data release process - a bureaucratic procedure meant to be fulfilled in cases of a legitimate enquiry such as a trademark dispute or a law enforcement request. Those are things slightly more important than certificate authority identity verification, yet sadly, that leaves them with an exploitable blindspot.
To make things even more believable, the threat actor opts to redirect all HTTP requests made to the .CO.UK domain to the company owned .COM one. The only difference between these domains is that the email sent from the .CO.UK domain does not get redirected to its top-level domain counterpart. Replying to such emails would mean corresponding with the attacker, not with the person who is impersonated.
Phase 4: Buying a certificate
With the infrastructure in place, the order for a new code signing certificate can be made. There is less verification for non-extended validation certificates, and the attacker already has everything required to purchase one for the impersonated identity. The only thing that remains is passing the certificate authority identity verification. For the certificate authority the attacker has chosen, this is a simple three-stage process.
| Step 1 | Organization validation No paperwork. The company’s legal existence is checked in a public government database using the company name or unique identification number (registration number), OR via verified public third-party databases like GLEIF, Duns & Bradstreet, Hoovers, Companies House GOV.UK (check), Lursoft.lv and others. |
| Step 2 | Domain control validation DCV via email is the most traditional method of passing ownership verification. The certification center will send an email (check) to the administrative contact of your domain. The mail contains a unique validation code and a link to a certification website to enter the code. |
| Step 3 | Callback process For Business Validation, vendors use an automated callback process. A robot calls you on the verified number (no public company phone numbers, CA probably used the one provided by the attacker during account creation) and tells you the verification code. |
After the order has been placed and the payment has been made, it only takes a few days for the purchase to be fulfilled. Conveniently, the certificate authority of choice offers many payment options, such as Skrill, PayPal, and WebMoney.
The attacker now possesses a code signing certificate issued to a legitimate company based on the request made by impersonating its executive.
Phase 5: Testing the certificate
Testing the certificate is a matter of signing executable content and verifying that the certificate chain can be validated to a trusted root. Typically, it is an offline operation performed with code signing and software development tools. However, this threat actor does signature validation a little bit differently.
2019-04-24 06:40:29
The threat actor signs a common Windows executable, Notepad.exe, and uploads the signed file to a public antivirus scanning service. The uploaded file is renamed to Notepad_[Redacted].exe. This executable is cross-signed for timestamp verification via COMODO SHA-1 Time Stamping Signer service. There is no malicious code within the signed file.
2019-04-24 06:40:30
The threat actor signs a common installation executable, NSIS, and uploads the signed file to a public antivirus scanning service. The uploaded file is renamed to Example1_[Redacted].exe. This executable is cross-signed for timestamp verification via COMODO SHA-1 Time Stamping Signer service. There is no malicious code within the signed file.
Details of the digital certificate used to sign both of these files are shown in the following image.
Note the last line in the certificate extensions list. From the metadata above, it is clear that the certificate purchase request has been made from an attacker-controlled .CO.UK domain.
Phase 6: Selling the certificate
There is a reason why digitally signed files have been named the way they were, and were uploaded to the public antivirus scanning service. The file scan record is a proof of value for the potential buyer. It is a proof of certificate ownership and its validity, and a clean bill of health.
2019-04-30 07:07:59
The first signed malicious file appears in the wild. The certificate is used to sign OpenSUpdater, an adware application that can install unwanted software on the client's machine. This executable is cross-signed for timestamp verification via Symantec Time Stamping Services Signer service.
2019-05-16 11:46:00
The last signed malicious file has been spotted in the wild. In total, the certificate has been used to sign 22 executable files. Not all of them have been malicious, but those that have all belonged to the same malware family - OpenSUpdater. Some of them have been installation packages made with NSIS. All signed files after the first two have been using the same timestamping service.
The change in the timestamping service is a significant indicator. While there’s no requirement that timestamp validation must be done via servers of the certificate authority that issued the certificate, it is customary to do so. Developers who implement code signing in their organization usually follow the recommendation of the certificate authority from which they’ve purchased the certificate in the first place. Usually, the documentation that illustrates proper certificate usage already has timestamp servers listed within the examples. Very little needs to be done to convert that example to production code. This is why most developers end up using the expected timestamping infrastructure. Furthermore, once code signing is implemented, it is usually left as-is until the certificate expires.
Because of this, there's a strong indication that the certificate has been sold on the black market, and that the group spreading the adware has an infrastructure in place that rotates purchased digital certificates. It’s also apparent that they care very little about the small details such as which timestamping server is appropriate for which certificate.
While it would be comforting to think that this incident is an outlier and that this company was a sole victim of circumstances, that is simply not the case. The data collected and analyzed by ReversingLabs shows that this identity theft is a pattern of behavior for this threat actor, and that the number of impersonated companies in exactly the same way equals more than a dozen. It is clear that this attacker (or a group) is financially motivated, and acts as a supplier of impersonated and possibly stolen certificates to the black market.
The only thing better than using a scheme once is using it many times, on as many people as possible. Building a believable infrastructure is hard. When it is up, using it just once would be a waste. Why sell only one certificate on the black market when you can sell many?
Certificate authority hopping is another tactic employed by this threat actor. Using the same impersonated identity, the actor tries to buy as many certificates from as many certificate authorities as possible. These typically get issued in quick succession, as the attackers want to get the best return on their infrastructure investment. While certificate issuance procedures could do more to verify identity, the success behind this attack can only be credited to the ability of this threat actor to make the request seem so believable.
Identity verification checks that are performed for regular code signing certificates are less rigorous than the ones for extended validation certificates. For the latter, the certificate authority performs more detailed checks, and ultimately sends a hardware token via post. That token must be used during signing.
ReversingLabs research into certificate authority hopping has also found cases where extended validation certificates have been issued to the same threat actor. This means that infrastructure investments this threat actor makes extend from digital to physical world. Since extended validation certificates are more expensive and harder to come by, one can only assume what that means for the attacker's profit margins.
Extended validation certificates are extremely valuable to adware spreading groups. Files signed with this type of certificate bypass Microsoft SmartScreen protection and allow signed programs to execute with no warnings about the possible unsafe file origins. That means that the following Windows dialog, that can deter installation of unwanted applications, will not be shown at all.
Instant trust with Microsoft SmartScreen is a key selling point that multiple certificate authorities use to justify purchasing extended validation certificates instead of the regular code signing certificates. While it is harder for the attacker to acquire one, this group has shown that it is in fact possible to do so.
Certificates are a hugely important piece in building trusted environments. Studying their use and misuse is the only way to preserve their relevance.
Signed executables (listing partial SHA256 hashes to protect the company identity):
27a78fe26dcd417287ca33e8418d735c...
56d7a98bea20d77be8e47d58d5781b60...
abc513e2de71d7289066bd38b4138ce1...
96850d836677b55658320a7042e2f847...
388a5bcc6c0cd0b083ff0923b83debde...
0d1eb17bceac7d78ee3e3f2163f93dd5...
4eccc15440532019e56ed7d772a2dc34...
1b039c8cef3dd741b9bc8d9702bf90bd...
81cf8cd3773f3d23f51897dbfc57d0b9...
1f54a2e8577ffff6b7228b524412fbda...
105a6356f3d8d86611d56862f5b87dee...
1daf0f102954cc0a10778e3cc24256ba...
a7e573fec0b0b4c0e7d73859303ebc20...
aab56d071ff05117c7f36f5cc9f0a0d0...
eeb603a0b3ce0d29ba3ee79e494070f2...
814b15d282f44f08aabdf15ad28481f6...
a1ae46a87a1f9cd3e1feb5bc4c2880e7...
69dfc4062adee03ebde881de42695f24...
aa2e10c73de1afb70b875c0d2d578d52...
b52beeb98f5ee65103cd36f57bb059a4...
1648e9a7afbc8b057c1f5c4c9f5c143c...
bb4f529be95b6e7b1c8a19adfb0a1b69...
This article is the 6th part of our Digital Certificates series of blogs. Read other blogs in this certificate series:
