People learn by doing, hence the saying practice makes perfect. Not everything that people make, is published. Sometimes researchers deliberately refrain from publishing specific material. In this blog, I want to talk about the balance between malware creation and malware research. Needless to say, the type of creation that is covered in this blog, is done from an educational perspective.
The reason to write this blog is based on the fact that I got quite some questions about this recently, and because I’ve seen more and more people publish material that I think should not have been published. In the end, our goal is to enhance the security of the greater good, not weaken it. Within this blog, I’ll not refer to any other projects, as I do not want this blog to serve as an advertisement.
Research and creation go hand in hand
To research a certain topic, one requires knowledge in that area. When analysing malware, it helps to have a deep understanding of programming languages, especially the one that was used to create the sample that is being analysed at that moment. When starting out to learn a language, it is helpful to write small programs, which you can then analyse. This provides you with the benefit of using both the compiled output and the original source code during the analysis.
Alas, the source code of most malware samples is not available, leaving the researcher to look at the compiled, and often obfuscated, output. This makes the learning curve steeper. Developing your own samples to look at, is one way of solving this problem whilst gaining experience.
Where do you draw the line?
To answer that question, I should first specify what the goal is when creating something. There is a difference between making a proof-of-concept to prove a specific technique or exploit works, and providing the complete compilable source code for a piece of malware. The proof-of-concept is used to prove novel findings, showing that the theory is usable in a practical case. The compilable malware projects do not serve such a purpose, since the novel concept can be explained differently.
It is important to ask yourself what the reason is to publish something. Naturally, people like others to see the results of their hard work. Additionally, sharing knowledge is a noble goal. The question is, however, if one should publish the complete source code, or explain the concepts that are used. Publishing educational ransomware, or yet another remote access trojan, does not contribute to the community. Instead, it plays into the cards of criminal actors, who can freely use and adopt the projects as they see fit, usually with limited technical effort. Although this discussion is somewhat adjacent to the offensive versus defensive tooling debate, it differs enough to warrant its own blog post. As such, I’ll not discuss it in further detail in this blog.
The two malware types above are not picked at random, as they represent two educational projects that were published, and subsequently abused by malicious actors. The educational ransomware was used in quite some actual malware campaigns, causing the victims to lose their data and stopping businesses dead in their tracks. The original author of the educational ransomware is not responsible for this, but did help to enable the criminal actor, without adding anything positive to the defensive side of things.
It’s not in anyone’s benefit that the wrong software is released and subsequently abused, hence this plea. When in doubt, you can always ask around in community channels, or in public fora.