why develop malware

Malware implants are a fundamental part of red teaming. After all, once you are able to get that initial RCE (remote code execution) how else are you supposed to leverage that to make real gains. While there are a huge number of tools readily available (metasploit, empire, covenant), all of these tools will get flagged by even the most basic AV (anti virus) and EDR (endpoint detection and response).

To get around these challenges, it is necessary to modify existing malware or develop your own. To do this properly, a thorough understanding of creating implants is needed. To gain this understanding I have begun to develop a modular implant incorporating function call obfuscation, payload encryption. This mainly follows a series of videos from sektor7 Malware Essentials class. Github code can be found at this github repo

All of this code was written by me with reference to the sektor7 trainings. Once I got the jist of things I attempted to expand the functionality and configureablity of the executables as you can see in the source code.

Importing payload

An important part of implant development is for the codes ability to take in raw executable binary and then execute that. Theoretically this should be possible by creating a chunk of memory that has write and execute permissions. However, this is very bad security practice in regular programs due to basic binary exploitation. This means that most executables have w^x. It is possible to create wx memory, however due to the rarity of it, it is often flagged as malicious code by AV.

To get around this, we simply divided the writing and executing to separate parts of the code. First we create a rw block of memory that we copy our payload into. Then we change the permissions of the block into rx. This avoids having any block of memory ever having rwx permissions and the AV alerts associated with it.

Hiding payloads

Often the most detectable part of the malware is the actual payload. Whatever part of the code allows you to establish a remote shell, run modules, etc. This can be very hard to change without altering the desired functionality.

Rather then alter the payload, we encrypt or encode it to make it impossible to read before run time. This prevents static analysis techniques used by AV from reading the payload and detecting any of the bad stuff.

In the code, you can see there are 3 methods of hiding the payload: base 64 encoding, xor encryption, and AES encryption. Each method is pretty self explanatory. The coder will included the encrypted/encoded payload in the exe, and there will be a wrapper that will decrypt/decode the payload then start a new thread executing at start of the code.

Obfuscating function calls

The other big way that anti virus can statically detect malware is based around the function calls that a exe imports. It isn’t often that a program needs to create chunks of memory and change the permissions on it. Similar things can happen with downloading and executing remote payloads.

To defeat this we want to create a way to create a handle to the dll containing the function and then to get a function handle. We are then able to call this function handler as if it were the function. If we obfuscate out the strings required to get these handles, we are able to remove all strings related to the suspicious function calls and avoid AV.

Conclusion

With the ability to hide payloads and the function calls that the program is making it becomes possible to get past a large number of static analysis AV solutions. From here, more work needs to be done on the payload to make sure that persistence is established and allow post exploitation to start.