Researchers have published several ransomware projects in the name of education and freedom of knowledge. The question of their usefulness sparks debates among security enthusiasts and researchers since the release of open source ransomware Hidden Tear in August 2015.
Educational ransomware comes either as binary or source code which are published with the proclaimed intent to showcase potential risks, prevent infections or reduce potential damage, and to improve security products and behavior guidelines. We can roughly distinguish four flavors:
1. Ransomware Simulators
These are non-malicious binaries or builders for non-malicious files that simulate the behavior of ransomware by showing ransom notes or ransom screens without causing any permanent damage. They are a great way to demonstrate the effect of an attack and may be part of a training to prevent infections or to improve malware analysis or forensic skills. In the latter case the simulator may also encrypt files on the system.
An example of a ransomware simulator is ShinoLocker by Shota Shinogi which was presented at Blackhat 2016. ShinoLocker is meant to train forensic skills. Students may run the simulator and try to retrieve the decryption key from memory.
ShinoLocker comes as a builder that allows to customize the resulting binary, including the server to retrieve the encryption key, the extensions for the files to encrypt and a “Command & Parameter” field. The resulting ransomware binary will execute the entered command and so opens the potential for misuse. That means the tool can be misused to create actual, fully functional ransomware, an argument also brought forward by Bleepingcomputer owner Lawrence Abrams
Security precautions should be made to diminish the risk for misuse. Simulator builders can limit the file encryption to a specific folder and shouldn’t allow certain configurations, especially those that will execute any command. At least make it hard.
2. Partially Functional Open Source Ransomware
These are ransomware source codes which cannot be used to readily create a fully functional malware binary because integral parts are missing. These source codes may be published by security researches as proof-of-concept for new or formerly unknown techniques. They may help to educate security professionals about these techniques and can lead to improvement of security products that did not consider these techniques before.
Linux ransomware CryptoTrooper by Maksym Zaitsev belonged into this category until it was taken down. Zaitsev told Softpedia that the encryption construction algorithm was broken on purpose. Now the Github project only contains a readme with a challenge which people have to solve in order to get the source code.
As a rule of thumb the missing parts of the published code should require at least as much programming skill as the rest of the proof-of-concept code. This will prevent misuse by people who would otherwise not be able to create any ransomware on their own. It does not prevent misuse by more skilled malware developers who may include these techniques into their products. But such is security research: while one may argue that publishing new techniques this way can only be done responsibly, if malware in the wild already uses them and security products have yet to catch up, it is also fair to note that it is not very probable that a certain technique will only be ever developed by one person at a time. Just because nobody published it before it doesn’t mean that it was unknown. However, it cannot be denied that publishing a proof of concept of an efficient technique will increase its active use. This may indeed raise the pressure on the defending side or an individual vendor to come up with a proper mitigation, a rarely doubted ground truth in the security community. However, we may beg to differ with regard to ransomware: the issue is undeniable and well known; delivering a loaded gun (e.g., in the form of a flawless implementation of an encryption algorithm) to those otherwise too inept to load that gun is probably not helping.
3. Fully Functional Open Source Ransomware
Source code that can be readily compiled to a fully functional ransomware is without a doubt the main reason for debates about educational ransomware. The projects Hidden Tear and EDA2 by security researcher Utku Sen belong into this category. Part of the latest debate are also shc Ransomware and CryptoWire.
The most obvious argument against those projects is that these source codes are the basis for actual malware in the wild. Criminals who would otherwise not be able to create their own ransomware use them to get their foot into the ransomware business. Let’s take a look at the arguments of the project authors and proponents.
"It's just a sample which shows that how we can use basic encryption techniques to create a malware." (Sic!, Utku Sen)
“[T]here wasn’t any proper source code for a ransomware sample. My first motivation was provide a source code for newbies, students who are trying to understand the process.” (Sic!, Utku Sen)
If a student wants to glean deeper insight into the inner workings of ransomware, they may read a few analyses. The methods are diverse and the techniques implemented to maximize the malware’s impact are certainly interesting to observe over time. If a student aims to understand basic cryptographic primitives, there are well-structured text books. Just ask, we can recommend a few. Or read the source code of the NaCl library if reading code is how you learn. In any case the mentioned encryption techniques can be shown without publishing a full-fledged ransomware as discussed in the previous section. There is no reason to hand ready-to-compile ransomware source code to the technically halfway inept bad guys on a silver platter.
"publishing a vulnerability is not evil. hidden tear wasn't detected by antivirus programs the day i coded it. now it's detected. vulnerability fixed. my work is done." (Utku Sen)
“Script kiddies will have a field day, but... using detectable versions.” (@himayyay on Twitter)
Both statements argue that their projects improve the security software and as such prevent future infections. However, as reality has shown, undetected Hidden Tear and EDA2 based malware samples are still being spread. Although a plain Hidden Tear binary is detected by antivirus vendors, the malware creators use crypters, crypting services or obfuscators. These are common and readily available techniques that often serve to decrease detection rates. Projects like Hidden Tear are not difficult to detect, it is the packed files that are.
If you aim at improving security products, rather walk the established way of responsible disclosure: submit the sample along with a meaningful description of the point you intent to make and set a reasonable deadline for vendor response. Publish after fix. While there may be cases in the security field, where full-disclosure policy can be ethically argued, there is no indication that ransomware could be among them.
“The purpose is to reduce the risk which is caused by script kiddies. I can defeat most of the samples if the antivirus companies ask for my help” (Utku Sen to Eduard Kovacs)
"I think you don't understand the point of ransomware programs. It doesn't harm the system or cause an infection. It just encrypt files." (Sic!, Utku Sen)
Utku Sen has created a blog post that explains the intentional flaws of Hidden Tear and how they can be used to break the encryption. His idea was that the ransomware in the wild is weakened as criminals use the flawed Hidden Tear code instead of the ransomware-as-a-service websites. The flaws made it possible to create free decryption tools for victims like the Hidden Tear Decrypter by Michael Gillespie.
However, this argument does not account for all the victims who do not search for a decryption tool or don’t feel computer-savvy enough to find or apply solutions. Even if a victim attempts to find a solution they might not identify the ransomware correctly and assume they cannot do anything about it. The argument also does not account for companies that have a loss of profit and higher expenses as they try to recover from a ransomware attack. Depending on the severity of infection they may need days or even months to fully recover, even with the professional assistance of a good incident response team.
The main point here is that a ransomware attack damages systems even if the files can be recovered. Downtime means loss of profit, also if the victim has a well-tested backup strategy. Having a few more decryptable ransomware samples in the wild is a cold comfort after long hours on recovery and every victim that could-have-been-but-is-not, as no one handed weaponized code to skiddies is a good thing. Also, easing things for criminals is never a good choice: if a miscreant only needs to fiddle with the encryption algorithm to gain a profit-making malware instead of having to roll their own, we’d argue that you are abetting the enemy. This is not a fictional issue either: there has been EDA2 based ransomware in the wild that cannot be decrypted.
4. Closed Source Proof-of-Concept Binaries
Some researchers create ransomware without disclosing the source code. This is useful to show that certain things are indeed possible, e.g., to demonstrate attacks on so far ignored platforms.
One example is the Mac OS ransomware Mabouia. Its author Rafael Salema Marques created a video of an attack to demonstrate that Mac OS is also vulnerable to ransomware infections. He disclosed Mabouia only to AV vendors.
New ideas or concepts can also be shared, e.g., a ransomware that is purely written as MS Office macro as shown in the figure below.
Closed source projects seem to be a safe way to publish ideas, albeit they may not be applicable for every case. And yes, we care for these kinds of submissions. On the one hand, we are technical people that enjoy the occasional nifty trick. On the other hand we care for our customers. It may not always be easy to counter a new phenomenon or attack vector, but we do indeed go at great lengths to do so.
Irresponsible Disclosure Considered Harmful
While full disclosure has a long history in InfoSec, we argue that ransomware is just not the field to exercise it. Security researchers should weigh up the pros and cons carefully before they publish ransomware for educational purposes. Especially with fully functional open source ransomware, like Hidden Tear, the disadvantages are clearly perceptible and outweigh any potential (or imaginary) gains. Most of the advantages can be achieved by publishing only parts of the source code or providing it only to the people that need to know it to improve their security products.
The arguments for open source ransomware are not much different to the sarcastic statements of CryptoWall’s ransom note version 4: “CryptoWall Project is not malicious and is not intended to harm a person and his/her information data. The project is conducted for the sole purpose of instruction in the field of information security, as well as certification of antivirus products for their suitability of data protection”. Similar allusions at teaching users a lesson can be found in many other “real” ransom notes.
Taking down the source code unfortunately does not remediate the situation. There are still forks of Hidden Tear on Github and the stream of new Hidden Tear or EDA2 based malware releases continues. The internet does not forget, nor do the bad guys. And while it is said that at the bottom of Pandora’s box there is hope, the smart thing would still have been to keep the box shut.
