Now that we have the development and testing environments set up we can start designing and implementing our trojan.

The first question to answer is how we will store the piece of malware inside of our trojan. There are two options: Shellcoded hardcoded string and PE packers.

The malware that we will use to test our trojan will be a reverse TCP shell obtained from Metasploit.

PE Packer

A PE packer is a software program that will grab a PE file and will compress and encode it. The PE packer attaches the encrypted PE file to another non-encoded or encrypted PE file whose purpose is to decrypt, uncompress and execute the first file. If the PE packer needs to run malware, it needs to load the encrypted malware directly into memory and never drop it unencrypted in the disk. To execute it directly from memory, it needs to fix the address tables, and linking issues, in other words, it has to implement the same process Windows does when it executes a PE file. This approach would require to use of an existing malware PE packer or to create a custom one. Programming a PE packer is not an easy task, it requires a fair amount of knowledge and it is a time-consuming task.

Shellcode String

Shellcode usually refers to a small piece of PIC (Position Independant Code) that exploits a software vulnerability. Shellcode is used in opcode (operation code) format.

Opcode is a machine code instruction that represents an operation that will be executed. Shellcode is usually used in buffer overflow attacks. To use it in this type of attack, the opcodes cannot contain any null bytes \x00. This is because buffer overflow attacks are made by injecting a string. If the opcode string contains nulls, the opcode string will be cut where the null byte is. Since for a string, a null byte indicates the end of the string. Whilst Shellcode is often used for buffer overflow attacks, this project will use the same format but in a different way. The idea is to carry the code of the malware in a string format, hardcoded inside of the loader, and then, using different techniques, the loader will execute this code. The next piece of code is an example of what a hardcoded shellcode string looks like.

char ShellCode[] = {"\xEB"
"\x0F\x58\x80\x30\x95\x40\x81\x38\x68\x61\x63\x6B\x75\xF4\xEB\x05\xE8\xEC\xFF\xFF"
"\xFF\xF1\x34\xA5\x95\x95\x95\xAB\x53\xD5\x97\x95\x56\x68\x61\x63\x6B\xCD"};

This code contains no null bytes (\x00), therefore it could be used for buffer overflows. In this case, this is irrelevant, since this implementation allows null bytes on the string.

The shellcode needs to be PIC to execute malware that relies on libraries. To get PIC code from non-PIC software it will have to be manually rewritten as PIC. This is the same problem encountered with the PE packer approach.

Transforming executable to PIC shellcode

Here we have some options, we can implement our own loader that will resolve the linking issues and will recalculate addresses, but this is a very time-consuming task that I don't have the knowledge to explain and implement properly in a reasonable time frame.

To overcome this, we can rely on some amazing tools that can "transform" a PE file to shellcode. The two tools I like the most are Donut by TheWover and pe_to_shellcode by hasherezade. Both of these tools return a PIC shellcode that could be attached to the loader.

As explained before transforming non-PIC code to PIC code automatically is not possible, but what can be done is create a PIC loader and then use it to load our non-PIC code.

The listed tools attach the PE file to a PIC loader that resolves all the linking issues during runtime. This is usually programmed in assembler and takes a large amount of time to develop.

In the case of this project, we will be getting the PIC code directly from Metasploit. But if you are interested in embedding a malware for which you cannot get PIC code I recommend using any of the two tools I suggested before.