This repository was created to archive and document all of my attempts to learn and develop malware. I'm brand new to all of this. We'll start from the absolute beginning and see how far we can get. This repository houses the code (often updated to reflect my current "skills" — or lack thereof) from my videos on YouTube or my blog.

The techniques I'd love to learn are:

• 🟢 Shellcode Injection
• 🟢 DLL Injection
• 🟢 Using NTDLL
• 🟢 Full NTDLL Implementation
• 🟢 Using Direct System Calls
• 🟢 Indirect Syscalls
• ...

We're going to be dealing with a lot of low-level stuff. As such, it's important to familiarize yourself with languages like C, C++, Assembly, etc. I might create another repository solely for documenting my progression with the aforementioned topics, but that's far back in the pipeline for now.

If a technique specifically does not contain a Makefile, then it's meant to be compiled using Visual Studio. Otherwise, you can just compile the program(s) with make. I'm sure all of these can be compiled with a Makefile, but I haven't had the time to give it much attention yet.

Since there has been a lot of attention on the videos and thus, a ton of people trying out the techniques for themselves, a lot of problems have been encountered. However, they're all (mostly) very easy to diagnose and remedy.

• If a process is crashing, make sure that the architecture that you compiled your program in matches the architecture of the target process you're trying to inject into. This is the single most common pitfall I see when diagnosing/viewing someone's issues with their program and it can be very annoying and tedious.
• A crashing process could also be indicative of some incomplete/missing/borked shellcode, so make sure your shellcode didn't get cut out halfway during copying and pasting it.
• This could also be a consequence of how you're generating your payload. Make sure to explicitly define EXITFUNC=thread during your msfvenom generation which will allow the process to exit gracefully instead of shredding the process and killing it. The included shellcode already has this set, so if you're facing the crashing issue, that would need further investigation.
• On a slight tangent, if you're injecting a process and nothing is happening — it's not even crashing, then, this again, could be a consequence of an architectural mismatch or borked shellcode.

• A look into Windows Defender might be warranted since it can also interfere with our program's execution, so make sure to set exclusions accordingly.
• You get a reverse shell or something after injecting a remote target process and for the first few seconds, it's fine. Then, the second you issue a command, Windows Defender (or some other security solution) kills your process/connection. This can be due to how signatured (msfvenom | metasploit) payloads, listeners, handlers, etc. are. Encrypt your traffic or use something less signatured. A reverse shell by itself is almost always suspicious so more techniques are going to be needed in conjunction with what we've learned above.
• The (in)direct syscalls technique isn't working! This could be due to API Hooking. EDRs/security solutions will sometimes inject their own DLL into your process to hook commonly abused functions. The function(s) responsible for scraping the syscall numbers and instructions currently don't incorporate a way to fight/circumnavigate API Hooking and will fall apart due to the offsets being borked. So, you're going to have to be stuck in limbo for a while and research how to do that yourself. Eventually (TM), I'll add a way to account for hooks, in which case, I'll just remove this line from the common pitfalls section.

I'm only going to be accepting bug fixes or typo fixes. Since this repository was created to document my personal growth with malware development, I don't want to cheat myself by having you contribute a technique which I myself am not currently capable of implementing. If I'm doing something super inefficently (which most of the time I am), then depending on what it is, it might get accepted as a pull request. Either way, contributions are accepted based on those two (2) conditions. Thank you very much to everyone who helps out!

I'd be nothing without the support and research of my incredible (and insanely smart) friends who've pretty much taught me everything I know — in some way or another, as well as directly influenced me on this ongoing and amazing journey. In no particular order, thanks to:

• Lavender, Zetty, Xor, Spider, Rektsu, Bakki, Nigerald, Snow, Aqua, Geistmeister, Urien, and many many more.