Starting out with Malware Development

Creating a piece of Malware always sounds fascinating to me. So recently I actually wrote a dropper in C for an unrelated project and then further improved upon that piece of malware on my own time.

The issue I found everywhere regarding learning Malware Development was the absence of source code samples which I now realize is a good thing haha.

However, the ideas of how different types of Malware work along with how they are delivered etc are freely available on the internet which is what motivated me to write my own dropper.

This dropper started off as a C program which basically runs two binaries, one in foreground and one in the background. I was trying to simulate how the Elderwood project worked by abstracting all its technicalities. I was basically just working on running a shady binary in the background while also running a genuine piece of software in the foreground.

Draft 1

The first draft of the Malware was not really a dropper. It was just two binaries packaged in another C binary.

xxd -i calculator > calculator.h && xxd MalwareImplant -i malwareimplant.h

Is along the lines of how I converted my binaries, both malware and legit, to a C header file format. Now all was left was to import the header files in a C source file and compile all the three together.

The malware implant being used was generated from sliver, a GO based C2 framework.

The flow of the C program was as follows:

1. Import the unsigned character arrays from the header files
2. Write the data to files in the /tmp directory
3. Execute the malware implant in background with a system call
4. Remove the malware file
5. Run the calculator binary in the foreground

Draft 2

Second Draft of the Malware involved not creating the files on the filesystem and directly injecting the files into memory(as much as that’s possible in Linux).

This involved learning about quite some linux syscalls like:

1. ftruncate
2. mmap
3. memcpy
4. munmap
5. fexecve

I do not claim to be an expert on these syscalls or ANY syscalls for that matter. My research involved how they worked in tandem to achieve what I desired.

So now the flow of the Malware goes as follows:

1. Header files are imported for both, the calculator and implant
2. both the files are created in memory
3. The malware is executed in background
4. The calculator is executed in foreground

This had a flaw since I could not figure out how to run the malware in background and then continue with the rest of the program so I was looking at way I could parallel-ise the processes.

Draft 3

This involved the program creating a thread which ran the malware implant in the background, which was logistically a failure. This could be attributed to the fact that I had never written a threaded program in C and I found a decent alternative pretty soon.

Draft 4

This Draft is basically what the malware still does in its current form.

I found the fork utility extremely comfortable for my use here since i am only shipping two binaries.

The flow of the Malware hence became:

Parent Process:
1. Fork into a child process.
2. Run calculator in foreground by injecting it into RAM.

Child Process:
1. Run the malware by injecting it into the RAM.

This worked exceptionally well for me since it looked amazing during execution. However there was yet more issues which needed attention, the major one of which was the fact that the Sliver Implant was being shipped with the Malware and was basically going to exist on-disk. Any potential Anti Virus software would go crazy since the sliver implant have signatures which have been identified by the AV vendors and now get flagged.

So I moved my thought-train to fetching the implant in real time and the injecting it into the RAM directly hence leaving no room for on-disk existence(however much of it is possible on linux :))

The good thing about this was that even if the “user” shut the calculator application, the child process doesn’t get killed. This is something that I was really happy with. The Beacon/Session could keep running till someone did not close their terminal.

Draft 5

This Draft of malware fetches the implant via http and then creates a file descriptor for it, writes the data to it and executes it.

All this while running the calculator in the foreground.

The dropper on its own does not get flagged by VirusTotal at all.

However, the sliver implant does.

That’s a bummer really. The big issue with this was that ClamAV detected it, which is a software I am planning to bypass especially.

Latest Development

To get this 15/66 + 2sandboxes to drop down to lesser vendors and sandboxes, I looked up ways to obfuscate binaries or mess with them in ways which evade this automated check.

During this process, I was reminded of UPX, a packer which was used to package some malware in the PMAT course. At that point, I was playing the part of an analyst and hence UPX was something I needed to decompress before executing.

What I remembered from that time was that the whole binary even while decompiled had a very very different look after being packaged. figuring out functions and variables was unreal honestly.

So just like any other logical person, I packaged the implant with UPX, thus reducing the detection rate on Virustotal

Further putting packaging layers did definitely help out with evading detection

This was the result of Silent_Packer and UPX over it.

Silent_Packer -f UNPLEASANT_REINDEER -c aes128_ecb -m silvio_infection -o UNPLEASANT_REINDEER_MEGAPACKED

upx -9 -q UNPLEASANT_REINDEER_MEGAPACKED -oUNPLEASANT_REINDEER_MEGAPACKED_UPX

This still is not foolproof(sandbox flags it as super malicious), but its pretty good.

Pipeline

A pipeline can be created to do all this for multiple malware in an automated fashion. I’ll add more packaging options and layering options as I discover them.

The pipeline can be found here.

Future Work

Future work involves messing with the implant mainly. While just initial evasion is considered, veil(from veil-evasion) can be tested as well.

Havoc is a framework which really closely resembles Cobalt Strike which can also be used for its Malleable C2 qualities. But all that is for a windows environment, which is a different ballgame altogether. That will involve writing a dropper designed for windows with win32API, which is not something I am avoiding, but just adjourning for the time being.

Bonus

So I took Draft 4 and after seeing how well the UPX packaged malware were performing on VirusTotal, I decided its a good idea to look at this draft again.

This proved to be a good experience. The only trouble packaged sliver malware was giving was that in sandbox testing, it was getting flagged way too easily and being tagged as a malware outright.

To handle this, I added some code to the Draft 5 piece of code and made it so that the flow looks like this:

Parent Process:
1. Fork into a child process.
2. Run calculator in foreground by injecting it into RAM.

Child Process:
1. Send GET request to a URL
2. Parse the response
3. If the response contains some particular string/number/header, then detonate malware.

Note: Its important to decide what parameter to check on a response. Checking the existence of a URI is an overused method and no Malware writer should be having such a killswitch after wannacry.

Yet Another Note:
1. This is yet again causing an issue with the malware being on-disk

Combining this with the Draft 5 could make things work ngl.

Final Word

Don’t be like me, don’t upload your Malware on VirusTotal…..

I thought its not that big of a deal. IT IS. Don’t do that. Keep your shenanigans contained otherwise, they will stop working in the real world.

Virus Total still doesn’t identify it as sliver, but the Silent_Packer+UPX version of sliver is being flagged by 5 vendors now.

I feel stupid right now. This is 4 days after the 0/67+1 score on VT.

The behavioral sandbox testing must be the reason :(

Anyhow, Malware Writing is super fun. I’m gonna experiment with more Malware techniques and what not. Leaning into windows malware is a little scary but that’s okay, scary means its gonna be super fun after I learn it.