Foreword
I'm creating a series for malware development on my YouTube channel. You can find the first video in the series below. The series will contain most, if not all the subjects covered in the malware development section of my blog and more. In the first video, we look at some of the fundamental concepts of the Windows operating system—including processes, threads, and handles before using some basic WinAPI functions. This provides us with the rudimentary basis required for our malware development journey.
Homework
In the video, if you stayed until the end, you’ll have heard that I assigned you homework. I wasn't kidding. Here’s your homework:
I want you to, using some of the WinAPI functions covered in the video, develop a program that will do the following: Start a process of your choosing, and print out some values like the
PID,TID, and the subsequent thread/process handles. Then, have it wait for the process or thread to finish using an API likeWaitForSingleObjectbefore closing the handles to your thread and process, using an API likeCloseHandle.
Starting Malware Development
Recently, I’ve been attempting to get into Malware Development. As someone who’s spent a considerable amount of time (~2 years) “hacking”, I’m sort of ashamed of myself for not trying to understand how to develop the one thing all of us hackers use—perhaps even on a daily basis; malware. I mean obviously, I’ve gotten shells with shellcode generated by msfvenom. I’ve even dabbled with a little obfuscation a couple of times—sprinkling in an AMSI bypass here and there, but that’s about the current extent of my “maldev” “knowledge.” I plan on remedying that here in this series. There’s something… different and refreshing about the art of creating malware and not just generating it.
Obviously, as we’re developing malware, you should take extra precautions with the programs we build and the techniques we learn. Although I’ll try to use simple “calc.exe” proof-of-concept shellcode, it’s still extremely important to exercise caution and to NEVER run any of these programs, techniques, tools, etc., against someone or something to which you do not have explicit written permission to do so.
Please also note that we’re mainly going to be talking about malware and its development therein in the context of the Windows operating system. Linux-specific malware is its own beast that we might tackle someday.
Now, by “malware development,” what do I mean? Honestly, I don’t really know. I’m a complete beginner at this. However, I do know that the most common techniques in malware development, more specifically in the context of “process injections,” “thread hijacking,” and “evasion/obfuscation,” are something like the ones below:
Process Injection
- Shellcode Injection
- DLL Injection
- Using NTAPI, Full NTAPI Implementation
- Using Direct System Calls
- Using Indirect System Calls
- Using Vectored Exception Handler (VEH) System Calls
- …
Thread Hijacking
- Local Thread Hijacking
- Remote Thread Hijacking
- APC Injection, Early Bird APC Injection
- …
Evasion & Obfuscation
- API Hashing
- String Obfuscation
- No CRT
- …
There are so many more, and probably even more than what I think is out there when it comes to the different techniques as it pertains to process injection. Attached below is an excellent resource describing the various common process injection techniques:
This is such a huge field, and without the plethora of incredible free resources out there—the Twitter maldev community and these people who I’m insanely lucky to call my friends: x0reaxeax, lavender, 5pider, bakki, aqua, rektsu, and many more that I’d love to mention—to draw inspiration from, I’d surely be way more lost than I already am. So, if any of them are reading this, thank you so much! ❤️
I need to make this abundantly clear. I’m not an expert on malware development, C, C++, or whatever. Not even close. I’d never ever claim to be either. I’m simply making this blog, and the videos therein, to consolidate my learning. I hope that by putting what I learn into a blog post or video, it will further lock in that knowledge. Also, the blog posts are to give others who’re starting their journey someone they can struggle with. The best way to learn something, in my opinion, is to teach it to someone else-à la Feynman’s method. So, long story unsigned short, don’t come into this expecting the world’s most sleek code, a universal exploit that’ll work for everyone on their respective machines or anything along those lines.
So, what do we need to start malware development? Patience and clinical insanity, probably. People get too caught up in what languages to use for x, y, or z. Your programming language is just a tool. As long as you know what you’re trying to accomplish, the tool you use is up to your discretion and shouldn’t be too much of a factor.
With that being said, the typical languages you may see in malware development are (but are not limited to): C, C++, C#, Assembly, Golang, Rust, Nim, etc. What you need is something you have to consider on a per-project basis. Some languages are better than others for their specific/niche use cases. Which is something you’ll come to understand with exposure and practice naturally.
I’m mainly going to be implementing all of these techniques in C. However, there will probably come a time when we might have to explore some ASM, C++, or a plethora of others, who knows? Remember, I have no idea what I’m doing. I'm learning, just like all of you are (or were at one point). Another thing I’m embarrassed to admit is that, at the time of writing this (March 27th, 2023), I don’t really know how to program C or C++1. You give me some source code, I can generally maybe sometimes understand it; most of the time only enough to know the gist of the program’s purpose.
Because of my background in binary exploitation, I know the common vulnerabilities that lead to buffer/heap overflows; format string bugs, use-after-frees, etc. However, suppose you plop me (gently) in front of a computer with an IDE opened, PC fans humming, the light from the monitors flickering, and tell me to program something in those two languages. In that case, I’d be shitting bricks bigger than some of the allocated buffer sizes I’ve seen on some stack-based buffer overflow challenges. So, instead of shitting bricks, I’m going to link some resources down below which I’m currently using to learn C/C++ and once I’m comfortable, the WinAPI.
Resources
These are what I’ll be using to build the necessary foundations I need with which I can attempt to learn the arcane/dark arts of malware development2. Although more realistically, I’ll probably be programming in C/C++ until I mess up enough to understand the language more and more (the best approach, in my opinion). Once I’ve gotten a bit comfortable with the languages and the WinAPI, we can do our first injection! Thank you so much for reading and I hope you’re excited for this journey we’re about to take!
Repository
My GitHub used to be a pseudo-blog/source code haven for all of these techniques that I was learning. Depending on when you’re reading this, it might now solely be a container for my code.
References
Footnotes
-
Update from the “future” on June 26th, 2025: I still have no idea how to program. ↩
-
Hi, Crow again. Yeah, this is totally unnecessary. When I was learning
C/C++in the beginning, I always thought that I’d end up using all of these textbooks and resources that I had bookmarked/saved. Yeah, I don’t think I ever did that. Instead, I learned by just shutting up and just opening a terminal. I geniunely think the best way to learn to program is by… programming. So, pick a project (it doesn’t have to be anything crazy; you can even start with a simple text-based game that takes in user input and tells a story, or a calculator app, even) and start coding. ↩
