Modern Malware Development Languages (2025)

As SkilStak focuses more on the essential skills of offensive security (red team) as well as defensive cyber security (blue team) I have been enjoying the perspective of a enterprise developer responsible for writing code for 10s of thousands of servers and desktops running every operating system imaginable, and ensuring their security through audit compliance automation. Having “blue team” experience actually informs the decisions made about picking a good “red team” toolset, specifically malware development languages.

For the record, I’m not interested so much on current trends as much as solid approaches proven in the field and through experience. So here’s why I think this combination of languages will dominate the malware and systems auditing space over the next five years.

I’m blown away by how many knowledgable technologists do not realize that one can write and compile Go code on a Linux machine that will run on Windows or a Mac. That’s right, the static linking allows Go to compile executables (exes) that won’t even run on the computer that compiled them.

This is the main reason that Go is the dominant language for systems tool development such as that Duke energy is hiring heavily for right now. This is the reason Go was chosen for the source language of both Docker and Kubernetes, two of the most significant creations in the field of systems operations in the last 10 years. I believe for these reasons Go will grow to become the dominant malware and auditing language as well because of it.

In order to understand how big of a thing this is it helps to understand the landscape of options for those developing enterprise security audit software, that had to run on everything before Go.

When I architected IBM’s automated server auditing solution we picked Perl because Perl2Exe was a thing, it was a kludge, but it was better than everything else. Each “compiled” auditor had a Perl interpreter essentially embedded in it. This truly allowed creating a single executable (although not a truly compiled binary) to be created for any operating system in the world that could run Perl without requiring Perl to be installed. Each runnable was large and could technically be tampered with, but it was better than the alternatives for rapid development and maintenance of audit rules.

No Java can’t do this.

Java has to ship the entire JRE for each targeted device. This presented tons of problems, mostly that there was no easy way to ship it with each and every executable allowing it to be easily tampered with by anyone on any system that was being audited. This violated the trust required of the architecture.

C required compilation on like system.

C would have worked, theoretically. But it would mean having a compilation lab containing every single target system to be audited available and maintaining a C compilation setup there and running it for any minimal change. Hell no.

Python and Ruby had same problem as Java.

Python also would have to ship the interpreter or maintain one in the endpoint agent somewhere. Again, something that can be tampered with.

POSIX Shell and VBScript Also Worked, But Limited

Shell always works, on anything with POSIX shell support, which eliminates the entire Windows world. VBScript was used for Windows.

The fact that Go is compiled automatically makes it harder for forensics analysts to pick apart. Of course, it can be decompiled like any other C code, but this requires a higher skill set than just looking at the Perl/Python/Ruby/Shell code to see what it is doing. It also executes much faster both in startup time and runtime.

Go compiles down to statically linked executables that are not as complicated allowed an entire payload to be contained in the single executable, which can be moved around in the system dynamically to avoid trip-wire-like detection. There is less network traffic as well.

Using the shell of the target system is already there and needs no download.

I was blown away to discover that OpenPGP and OpenSSL libraries are part of the native library set for Go. To date, Node still does not have these, for example. Perl didn’t have them for decades and still largely does not depending on shipping something like GPG with the code. Go also has built in net-centricity with server and client libraries standard. This makes network-enabled malware and auditing simple a breeze to create.

Python may still be lauded by many for such scripting and for glue language stuff, but the truth is, it is much worse than Go for the heavy stuff (which often depends on third-party libraries) and not better than POSIX shell, perl, PowerShell, DOS, or VBScript for the glue function because you have to ship the Python interpreter to actually do anything.

This leaves Python in that dead-space of not bringing anything particularly valuable to the table. In fact, the only thing Python has going for it in this space is readable syntax, which is actually BAD for malware.

In fact, I will dare to suggest that the only coders in the security space attracted to Python’s advantage are ultimately script-kiddies and language bigots. Python may have built in SQLite support, but we really do not need that for most things and if we did Go has many legitimate, better alternatives from a community who is decidedly head and shoulders (collectively) above other language communities including Python.