Build better cyber trainings by writing malware and vulnerable apps

Cybersecurity is a field where people take a lot of company organized trainings. This may be awareness training meant to inspire better security decisions in everyday work, or it can be targeted trainings to help incident responders stop and remediate attacks faster, or help software engineers build more secure applications. We all know a good training from a bad one.

I would argue that if you create training within cybersecurity, you will have more success if you incorporate your own malware into the training development.

Let’s first examine some of the characteristics of good trainings:

• The content is realistic and practical
• The material is presented in an understandable and engaging way
• The presenter shows great passion for the subject at hand

Unfortunately, many cybersecurity courses fail to satisfy these characteristics. In fact, many trainings seem to optimize for the opposite characteristics:

• The content is theoretical and not based on relevant threats and technologies
• The material is presented as a listing of facts, sometimes examples that are either too basic, or so theoretical they feel completely unrealistic
• The presenter is monotonic and seems to have little actual interest, or even knowledge, about the subject

Writing your own malware is an antidote to terrible training. Only people who have a passion for security would spend the time writing their own payloads, creating their own attack chains, emulating actual threats. Since creating that malware is itself a creative endeavor, it can also help build the passion that is required for creating better trainings. ISO 27001 brings a lot of good things to the table, but fun and engaging are not its main selling points.

Another reason why writing vulnerable software and malware prototypes is good for training, is that the software creation process itself is useful to generate ideas. Both ideas that occur during development and experimentation, and ideas the stem from other people playing with the malware or just seeing a demo of it.

The MultiRAT case

I have created a lot of cybersecurity trainings. I am sure some were better than others, and I am convinced that the ones based on self-authored malware have been the ones people have enjoyed the most taking. This one is now many years ago, but I still think it is one of the better technical trainings I have had the privilege to work on. At a company where I was part of internal security, we did some internal incident response training. For this, a few members of the security team built an attack chain that was unleashed on other members, and they would then investigate and remediate this threat. This was a Python based web shell designed to work on Windows. MacOS and Linux. We made different droppers for them for different operating systems. For Windows (the primary target), we created a PowerShell based dropper script, disguised as a vulnerability scanner looking for a particular CVE that was popular at the time of the training. The kill-chain looked as follows:

• Create phishing e-mail with a link to the “vulnerability scanner” on a Github repo masquerading as a tool from a well-known security vendor.
• The victim downloads and runs this tool on Windows clients. The script then generates a fake vulnerability report showing that you are not vulnerable to the CVE in question. It also downloads ngrok, creates a tunnel to the victim computer, drops a Python binary into the user profile, creates a virtual environment, uses pyinstaller to create an EXE file. It then removes the Python setup, uses scheduled tasks to create persistence restarting the EXE file with the web shell on reboot, and deletes both the Python setup and the dropper script.

This setup was used in a purple teaming exercise, where we worked together after the infection to learn more about detection coverage, where incident response procedures were strong or weak and so on. Was it delivered with passion? Definitely. Did it improve security? It definitely did that too. Did it require a lot of effort and time? Yes to that as well. But how was the return on investment?

• It led to direct improvements in detection coverage and incident response
• It provided war stories for use in later trainings
• And it was novel; the ngrok method for C2 connectivity was reported in the wild a few years after we did this. It is good to feel ahead of the bad guys!

A funny side note: the Github repo we used for this received a takedown notice from the threat intel company whose name we imitated. Learning point: if you are going to use lookalike names in training payloads or red teaming infrastructure, it is a good idea to talk to the company you are imitating up front.

The RottenDonkey case

The MultiRAT case was relatively advanced, but it doesn’t always have to be. For a developer training we wanted to demonstrate how software supply chain attacks work in a simple way. For this we made an NPM package that did nothing but add a backdoor to a nodejs project. The package is still available, and it is quite funny to see that the code scanning tool Snyk marks it as “no vulnerabilities found”. This is of course because Snyk is looking for vulnerable dependencies, but here the package itself is a big stinking vulnerability – but “No known security issues” is a stretch. The readme of the project says “Demo of evil project” and includes the text “WARNING: using this package would allow anyone to take full control over your server/container/etc”.

As for the training? It did get the point across. You find the package here if you are interested: rottendonkey - npm (npmjs.com).

Attacking the developer – Evil VSCode Plugin

While working at DNV we made a demo in the security team that we used as demo for some customers we helped with application security. At the time (2022) there was a lot of talk about APT’s targeting developers. The payload we created was a VSCode plugin masquerading as a tool to automatically clean up messy code and reduce technical debt. The plugin had to be sideloaded because we (of course) did not want to publish it to the VSCode marketplace. The kill chain here was:

• Create plugin that would generate a reverse shell on the developer’s machine and send to the attacker’s listener
• Create package file for the plugin and host it on a download site
• Create a blog post explaining how great the plugin is
• Create spear-phishing message to targeted developers
• …. and then there were shells

This wasn’t really used in interactive trainings but used as demo’s in various motivational talks for developers and tech people. It got quite popular – and was certainly more memorable than a PowerPoint explaining that software supply-chain attacks are dangerous.

Does vulnerable software and malware have a place in less technical trainings?

When creating tabletop exercises, do we gain anything from writing code? I think we do. Early this summer I and a few colleagues had the pleasure of helping a customer in the healthcare sector with a cyber incident exercise focusing on clinical impact of cyber-attacks. This was a discussion exercise around a targeted attack on medical devices. As part of the background story, we researched remote access mechanisms used by some X-Ray machine vendors and set up a simulation in the cloud of such a mechanism with jump servers, a Linux based “x-ray” machine, a work order based access mechanism and some monitoring. This allowed us to test in practice some of the ideas we had for how the threat actor had moved laterally through the system, and the observable facts this would generate in logs. This technical level was never shown to the customer, but it did certainly increase the quality of the scenario description and made sure we did not stray too far from reality.

I think I can safely say: to build great cybersecurity trainings – even for management – write your own malware.

Finally, I'm grateful to several former colleagues I have worked with on these trainings and malware ideas - creating is always more fun together.