Code-Signed malware: What's all the buzz about? Looking at the "Ryuk" ransomware as an example.

06/08/2019
G DATA Blog

Certificates are an established method for verifying the legitimacy of an application. If malicious actors succeed in undermining a certificate authority (CA) by either stealing a valid certificate or compromising the CA, the entire model unravels. We have taken a look at a case where this has happened.

What's code signed malware about?

Signing code is a method to guarantee the legitimacy of an application, in a Windows environment. The goal of this method was to create a trust model that shows if the origin of the PE file is correct. In theory, this is very resource friendly, as no behavior of the executable needs to be monitored. The certificate of the file simply needs to be checked on its origin in order to for the file to be trusted.

The entire concept is based on the assumption that the signature is trusted. This makes certificates an interesting asset for individuals who are willing to abuse the model. Should a malicious actor manage to acquire a certificate from a highly trusted CA (or steal one from a trusted vendor), they can then use this to sign their own malware, enabling it to sail right past a lot of security barriers.
One thing should be made clear, though: the presence of a valid certificate does not automatically infer that the signed application is benign. In fact, some malware as well as many programs that are classified as "potentially unwanted" are properly signed. At the end of the day it is up to the user to decide whether or not he trusts the vendor of an application. 

Researchers from Chronicle collected data from VirusTotal reaching over a time span of 365 days to find out which CAs had be abused the most. 
In all, 3,815 samples met their filtering criteria. In the picture below you can see the top 25 abused CAs. You can read more about their insights here - Abusing Code Signing for Profit.

Signed malware example: Ryuk

Insights about the Ryuk malware like the ransom note and the certificate are shown here.

 

Ryuk's initial routine

Ryuk checks if one of the following network interfaces are present. If so, it terminates. This has been implemented to protect devices with those network interfaces from being infected. At this point, it's not clear which devices are meant to be protected with this feature.

 

10.30.4
10.30.6
10.30.6
10.30.5
10.31.32

 

Next, the following commands are executed:

 

net stop "audioendpointbuilder" /y
net stop "samss" /y

 

The first command stops the Windows Audio Endpoint Builder, which causes audio devices and effects to not function properly. This might be implemented, because the victim notices on another way (other than just encrypted files), that the computer is infected. This may include missing sound on YouTube videos.

The second command stops the Security Accounts Manager, which prevents other services - such as SIEM solutions - from receiving any alerts about suspicious activities on the affected system. 

Lastly, Ryuk will attempt to terminate a number of processes. This might be implemented to make sure, that any open documents aren't locked by the corresponding software and certain malware protections aren't hindering Ryuk on its actions.

 

veeam, backup, backup, xchange, dbeng, sofos, calc, ekrn, zoolz, encsvc, excel, firefoxconfig, infopath, msaccess, mspub, mydesktop, ocautoupds, ocomm, ocssd, onenote, oracle, outlook, powerpnt, sqbcoreservice, steam, synctime, tbirdconfig, thebat, thunderbird, visio, word, xfssvccon, tmlisten, pccntmon, cntaosmgr, ntrtscan, mbamtray, veeam, back, xchange, ackup, acronis, enterprise, sophos, veeam, acrsch, antivirus, antivirus, bedbg, dcagent, epsecurity, epupdate, eraser, esgshkernel, fa_scheduler, iisadmin, imap4, mbam, endpoint, afee, mcshield, task, mfemms, mfevtp, msdts, exchange, ntrt, pdvf, pop3, report, resvc, sacsvr, savadmin, sams, sdrsvc, sepmaster, monitor, smcinst, smcservice, smtp, snac, swi_, ccsf, truekey, tmlisten, ui0detect, wrsvc, netmsmq, ekrn, ehttpsrv, eshasrv, klnagent, wbengine, kavf, mfefire, hrmlog

 

As you can see, this list includes a wide range of applications, such as malware protection and backup solutions.

 

Ryuk's main routine

This has been covered by other articles already and won't be reported about here in detail. If you want to read more about it, checkout this article from McAfee - Ryuk Ransomware Report.

 

Ryuk's certificate

The certificate used is a valid Thawte certificate. The subject is "WMV CONSULTING LTD". According to a companieshouse.gov.uk entry, this is an officially registered company.

Searching for the shareholders "Mrs Ilana Michelle Varney & William Varney" returns no results. The company contact details are (except the necessary registered address) unreported. Strange for a consulting company, which would want to have exposure. Don't you think? 

 

Ryuk's ransom note

In the image below, you can see the current ransom note. It's stored as HTML file named "RyukReadMe.html" inside every directory in which Ryuk has encrypted files.

In the previous Ryuk versions, the ransom payment instructions were explicitly given. This time, the name "Ryuk" is presented in center, which should let the victim inevitably know, that it got infected by the Ryuk ransomware. The payment "instructions" are simply two emails, which are located at the top left of the HTML file. Why the operators have chosen to use this kind of ransom note is open for speculation.

Code signed malware and the underlying economy

Here, cases of signed malware are shown and the question "Can everybody create their own signed malware?" is answered.

 

Famous stuxnet worm

As you may know, the worm stuxnet infected a control system at a nuclear power station in iran. Stuxnet took advantage of code signing. More about this case in a post from 2010 by securelist

 

Current case: Ryuk

In a recent report from Arstechnica, Ryuk is responsible for infected devices in the network of Georgia's Judicial Council and Administrative Office of the Courts. In an older report, Ryuk infected the local government of Florida. 

It seems like the threat actors specifically target local institutions, rather than going on a bigger scale. They might also target individuals, but those cases usually don't appear in the press.

While those reports didn't specifically mention that the sample is signed, it's surely possible.

 

Everybody can buy valid certificates

In a study from the Georgia State University, a very interesting view on the shadow economy of certificates used to encrypt website traffic is shown. Here are some interesting facts the researchers found out.

  1. Five of the watched darknet markets offer SSL/TLS-Certificates and related services such as 0-day exploits and ransomware.
  2. The cost of a certificate varies between 260 and 1.600 USD.

In another study from 2018 by the Maryland Cybersecurity Center, vendors of certificates used to sign code were analyzed. A key finding is that a vendor specialized on code signing certificates sold more than 10 certificates a month, earning about $ 16.150 from that.

 

vendor D offers certificates from various CAs (citing Comodo, Thawte, DigiCert, Symantec), all for $400.

As previously mentioned, Ryuk is signed by thawte. So it's possible that the threat actors of Ryuk bought their certificates or even the whole operation(ransomware+certificate) there.

 

Misc. recent reports

https://www.bleepingcomputer.com/news/security/microsoft-warns-of-campaign-dropping-flawedammyy-rat-in-memory/

https://threatpost.com/new-dridex-variant-slips-by-anti-virus-detection/146134/

Outlook

Francisco partners acquired Comodo CA, which is now known as Sectigo. As you may have noticed from the statistic image at the beginning of this article, it's clearly visible that Comodo is the most abused CA.

Here's an excerpt of a blog post from sectigo.

Sectigo’s Certificate Practices Statement and license agreement allow the company to revoke any certificate that to our knowledge is being used for illegal or deceptive purposes.

And further:

To know when one of our Code Signing certificates is used for malware, we rely on credible third parties, including VirusTotal. 

So Sectigo has the possibility to revoke certificates. But are they actively doing it?

Yes, according to the report "Abusing Code Signing for Profit", which was mentioned at the beginning of this article. 21% of samples had their certificates revoked at their time of writing.

Furthermore, Sectigo reported that they revoked 127 code signing certificates which were discovered by the chronicle researchers. This number seems so low, because a lot of duplicate certificates were found.

 

While proactive CA's look good at first, here are some bad examples of this behavior.

 

Case with Globalsign: A medium user wrote in a post from the 26.08.2018, that Globalsign simply revokes certificates without asking questions. Apparently Globalsign revoked a whole certificate based on antivirus heuristics from a year ago (which even were false positives). 

Case with Sectigo: In a slashdot story, A mid-size software company had their code-signing certificate revoked by Sectigo due to false positives as well. 

To sum up, it's the old problem of security vs. convenience. On the one hand, CA's are doing their duty in order to protect the people from code signed malware. On the other hand, legimite business owners are getting their certificates revoked because of overly-protectionism.

What you can do to protect yourself

Currently, code signed malware is mainly used in targeted attacks with a high financial gain as the price-barrier is often too high for the run-of-the-mill malware distributor. But since those type of attacks are quite efficient, it is becoming more widespread under the more sophisticated criminals.

 

If you want to stay updated about malware, be sure to follow these accounts:

RansomBleed - My personal Twitter account about the latest malware reports.

GDATA – G DATAs Twitter account.

Referenced samples

DescriptionDetection NameSHA256
[1] RyukWin32.Trojan-Ransom.Ryuk.A0b1008d91459937c9d103a900d8e134461db27c602a6db5e082ab9139670ccb6