Malware Development – Welcome to the Dark Side: Part 1

If you are in cybersecurity, especially Red Teaming, writing a full-undetectable (FUD) malware is a great skill to have. Folks tend to use Metasploit combined with Veil-Evasion or PE injectors like LordPE or Shelter, to generate a binary which can bypass the antivirus. Sometimes this works and sometimes it does not. The worst thing that can happen when running a Red Team activity is the binary gets caught by the AV and raises an alert to the SOC/Incident Response team.

Another reason to write your FUD malware from scratch is to eliminate the need for Metasploit, since it can handle only one connection at one point of time. Whereas, during red teaming I needed a CnC Server that can control all the pawned machines together, in simple words, a Botnet.

Thus, this blog will be an introductory blog to set things in motion to get started with malware development. The next set of blogs will be highly technical for the same reasons. Here’s a glimpse of the final toolkit:

To begin with, malware is just a piece of code like every other program. For example, if you want to write an undetectable keylogger, one should first check how a normal game would work in Windows. For example, every time you press a key in the game -> up, down, left, right, ctrl etc, a Windows handle is being called which captures the keystroke and performs some action according to it. So, if I could just write a program with the same code which runs in background and just slightly modify it to store the keystrokes in memory rather than performing some game-based action, it becomes a keylogger. I can then simply convert it into a module and push it to a reverse shell for dumping keystrokes from a remote machine.

However, there are few pre-requisites before delving into the world of malware. We need to do some homework before we get started. Below is a set of the most important questions before you start writing a malware:

1. What kind of malware do you want to write?

   1. Something that spreads automatically like a worm

   2. A trojan horse?

   3. Something that automates some task when executed rather than giving a reverse shell

   4. Reverse shell for Red Team/Phishing/Targeted Attack Simulation

   5. A bind shell

2. Which protocol will it use – TCP/HTTP/UDP or HTTPS?

3. Which language do I want to write in?

Here are some of the pros and cons of different programming languages when it comes to developing your first FUD:

We will be using TCP connection throughout the blog, however the malware we will be writing can be easily ported to HTTP. For the purpose of this blog, we will be writing droppers and stageless malware, since writing a staged malware would require us to go in deep into assembly, create shellcode and send it to buffer to execute it.

But since we want to write something which is quick and fairly straightforward, I will be writing these programs in C and C++ and use Python 3 for the server code. C/C++ based binaries are really small in size and when writing the handler/server for the malware, we need something that is fast and quick to write, thus Python3. I highly recommend not to write malwares in python or ruby, because the compiled size of the binary shoots to 1 megabyte and the malware that we would be writing, should ideally be less than 50 kilobytes.

Prerequisites

Below are a few of the skillsets that I think would be necessary to fully understand the code written throughout the blog series:

1. C/C++ [Malware/Bot]

   1. Pointers [for storing data in memory on the victim side]

   2. TCP Sockets [reverse shell]

   3. Manipulating buffers on the heap [reading large files]

2. Python 3 [Server/Handler Code]

   1. Multiprocessing / Multithreading [ Handler for multiple bots ]

   2. Handling data types with data structure

   3. TCP Sockets

   4. Event Signal Handling

3. WINAPI [Windows Sockets]

4. Mingw-g++ compiler flags/options [to reduce the size of the binary]

5. Elasticsearch and Kibana [for visualizing the compromised systems/users, privileges obtained during a Red Team Assessment]

Tools required to setup the environment for testing the malware:

1. Linux [Debian preferred – which will run the Malware Handler Server]

   1. Download Link – https://www.debian.org/devel/debian-installer/

2. Windows [Virtual Machine – for testing the binary]

3. Visual Code [for writing both Python and C++ code]

   1. Download Link – https://code.visualstudio.com/download

If your base machine is going to be Linux (as mine is) which will run the Windows code, I would recommend installing the cross-compiler i686-w64-mingw32-gcc to compile windows code in Linux.

Installing Mingw cross compiler in Debian:

However, if you are going to use a Windows system to do the development, you can use Mingw compiler for the same from here – https://sourceforge.net/projects/mingw/files/

Agenda of the Blog series

The next parts of this series will cover:

1. Writing a fully undetectable TCP based reverse shell in C/C++

2. Writing a fully undetectable TCP based bind shell in C/C++

3. The  malware should be compatible with all versions of windows [Windows Xp/7/8/10/2012/2016]

4. Programming a handler which supports multiple connections in Python3 [Botnet Style]

5. Using Elasticsearch and Kibana when handling multiple connections of bot to display their status and privileges

This is how the final malware toolkit/server would look like:

Once you’ve setup all the pre-requisites, it’s time to start listing all the features that you would want your malware to run:

1. Which user the malware got executed from (whoami)

2. Print current working directory (pwd)

3. List files in current directory (ls)

4. Move/Copy a file/folder (mv/cp)

5. Create a file/folder (touch/mkdir)

6. Delete a file/folder (rm/rmdir)

7. Execute a Windows command or another binary/file.

8. Download a file

9. Upload a file

10. Reconnect at random intervals to the CnC Server

11. Hide the binary on execution

12. Switch between multiple connected reverse shells

13. Send command to multiple Bots

Remember, that feature no. 7 is something that should only be run occasionally, reason being that every time you execute a Windows based command, it creates a process and becomes easy for Windows ATP or agent based solutions like Crowdstrike/Sysmon to track what the malware has done. All the features mentioned above would be written either using windows C/C++ API calls or something written purely from scratch.

In the next part, we will start writing a simple cmd-based reverse shell based on netcat, and then modify it to connect to a Python C&C server.