It is a common misconception that malware authors are mastermind elite hackers who know 18 flavors of assembly language and can write intricate pieces of software that do unimaginable things with their eyes closed.
This document is specifically talking about Linux malware, but most of these concepts are platform-agnostic.
This may be true sometimes, but it is exceedingly rare. Typically, the quality of malware is quite low (see Malvuln Project).
There are many reasons for the quality to be low:
-
Malware tends to have a short shelf life. It doesn’t make sense to spend a ton of time testing and applying quality control to malware that is meant to leverage a bug that is going to be patched within a couple of hours of it being used.
-
Often, malware has a short window of opportunity to be applied to hosts. Putting this into perspective, when some new high-profile vulnerability is released, it is often a race for malicious hackers and bug bounty hunters to be able to hack the impacted systems. In these cases, it is better to be first than it is to be correct.
-
Many malware authors are literal children. They lack the technical experience of a career software engineer.
-
Malware often leverages poorly-documented or undocumented features, APIs, etc. If there aren’t a lot of great examples or documentation available for using these features correctly, chances are the resulting code that uses it is not going to be that great either.
-
Although malware can be very lucrative under the right circumstances, it often isn’t. Malware may sell for a couple hundred dollars or maybe a few thousand depending on what it is on criminal forums. There are less criminals in the world willing to buy these tools than regular people looking to buy silly applications like productivity apps or games. The legality issues vary depending on the author’s location in the world, but generally people tend to make more money over time with less risk if they got a traditional software development job than selling hacking tools.
There are a ton of similar issues like the ones mentioned above, but I hope this helps demonstrate that you do not have to be an S-tier developer to get it done. In fact, many pieces of malicious software are people’s very first programming projects.
Depending on what the malware’s intent is, the author may not even need to know that much. In order to write general purpose malware, one can be very effective knowing some basics of computer science:
-
How to compile and run a simple program.
-
How to run a simple script.
-
Using software libraries.
-
How to read and navigate software documentation.
-
File-based and keyboard/screen-based input/output (stdin, stdout, stderr, …).
-
Navigating the filesystem: what a path, directory, and file are. What the general layout of the filesystem tends to be, …
-
Basic networking: IP addresses, ports, sockets, basics of protocols, …
-
Processes: what a PID is, what a thread is, using exec* functions, pipelining commands, fork(), …
-
More operating system basics: users, groups, permissions, general layout and function of a system.
Obviously, the more advanced one becomes, the easier it will be for them to write malware or just software in general. It really doesn’t take much to get started and one can definitely learn as they go.
For Linux and UNIX-like systems, the following books gave me most of my foundational knowledge for both offense and defense:
-
Operating Systems - Design and Implementation
-
The Linux Programming Interface
-
Advanced Programming in the UNIX Environment
-
UNIX Network Programming
I would suggest someone reads a modern book about C to learn the basics (Robert Seacord), then dive into the books above. They are all pretty thick, but ultimately were worth it for me to read and work through them. There may be more modern texts or ones that resonate better for you. As such, you should take ownership of your own learning and explore alternative options if these aren’t working for you.