Malware Development: Part 1

This is going to be a long series as I document my learnings from various sources on the interwebz.

What will we learn?

• Malware Dev and Research….duh

But why learn this?

Working in offensive security - doing pen tests and red team ops day in and day out, I’ve realized we usually have three options when it comes to tooling: use what’s out there in the community, pay for premium tools, or build our own. While community tools are great and paid tools can be slick, nothing beats writing your own malware (sounds pretty dope too). It gives you more control, helps you really understand how things work under the hood, and lets you experiment with bypassing EDRs in new ways. Why rely on someone else’s code when you can create your own and level up in the process?

What is Malware?

Malware, according to Merriam-Webster (we so fancy), is software designed to mess with a computer’s normal behavior. In our case, we’re not trying to be villains twirling mustaches - we build malware to ethically break into systems, steal fake secrets, and tbh scare our clients just enough to make them improve their security. Think of it as hacking with a heart: we show what bad guys could do so the good guys can sleep better at night. All the fun of cybercrime — none of the jail time (phew).

Pre-requisites?

• Basic coding skills (Read and write)
  • Preferably in C and Python to cover both high-level and low level languages.
• General understanding of AV/EDR on systems
• A Virtual Machine (VirtualBox/VmWare/UTM etc.) with the following tools:
  • Visual Stduio
  • msfvenom
  • ProcessHacker
  • PE-Bear
  • x64dbg

MDLC - Malicious SDLC : evil

We all know about the famous SDLC (Software Development Lifecycle) that is used for building out software, given that malware is also software we follow a tweaked version of the traditional SDLC and call it Malware Development Lifecycle.

Here are the typical steps/stages:

1. Dev - Development of the malware. (We write the code)
2. Test - Run tests to look for bugs in the code. (Think QA)
3. Offline tests - Run malware against offline AV/EDRs (sandbox environment) to avoid sample submission that might expose your newly created malware to the vendors and can get blocked.
4. Online tests - Run it against online AV/EDRs (sandbox environment) and if successful, know that automaic sample submission is on.
5. Analysis - Put on your threat hunting hat and analyze the malware to produce IoC’s (Indicators of Compromise) to detect the malware.
6. Rinse and repeat.

---

See you in Part deux