Malcore Tech Blog #1

They're worth millions, they have to be good right?

What will be covered?

In this blog post we will cover well known security tools and attempt to generate false positives using as little code as possible. Today we will be focusing a lot on VirusTotal (VT). Everyone knows what VT is. However if you’ve been living under a rock for the past ten years, VT is a website that allows you to upload files and scan them against multiple anti-virus (AV) vendors as well as analyze them inside of multiple different sandbox solutions. This is great and provides inexperienced users with an easy, user friendly platform in order to better protect themselves. However what if there are ways so that benign files can be flagged as malicious for not doing anything? Well today we will be attempting to do just that.

For this experiment we will be using the x86 assembly language, nasm compiler, ld linker, VirusTotal, and Malcore. Lets get started…

---

The Code:

We will be attempting to make an x86 assembly program using as little assembly as possible and making sure that the assembly doesn’t really do anything interesting. To start we’ll use the following code:

section .text

global _start
_start:
_start:
mov dword [var], 0
loop:
inc dword [var]
jmp loop
section .bss
var resb 4

For those of you who are unfamiliar with assembly, this code basically attempts to add to the [var] variable by one in a loop. Meaning there is no malicious intent and that it doesn’t really do anything, eventually this program will most likely crash and it might not even work on some systems.

Now all we have to do is compile this assembly code into a usable binary file. We can do this using nasm and ld:

What we did was compile the assembly file (test.asm) into an object file (test.obj) using nasm, and then take that object file and link that object file into a Windows 32bit binary file (test.exe) using ld. This allows us to recompile the file as needed as well as link the file back to exe files as needed.

---

Lets Trick a Multi Million Dollar Company

Now that we have our binary file we can analyze it and attempt to trick VT into thinking it’s malicious:

As you can see 8 AV vendors flagged it as malicious, including Google, and McAfee. As well as this if we look at the sandbox activity we can determine what this file actually does, according to the sandboxes used by VT this file does the following:

• Communicates with 3 IP addresses

• Performs process injection and spawns processes

• Executes dummy loops to evade sandbox detection (well it does loop..)

• Monitors Windows changes

• Reads the system software policies

• Triggers multiple high and medium Sigma rules

• Performs multiple shell commands

We can also upload this file to Malcore and run it through the dynamic emulator to determine if it really does anything dynamically, according to Malcore’s dynamic emulation engine, this file appears to do really, well nothing, and gets a fairly low score of 23.02:

---

As Small as Possible

The goal of this project is to make the program as small as possible in order to trick VT into thinking that it’s a bad program when it really isn’t. So for this next part we’re going to shrink the assembly code and use as little instructions as we possibly can.

Looking at our above assembly code we can go through each line and determine if we really need it or not:

section .text

global _start ;;
_start: ;; I don’t think we need these 3 lines for the code to function
_start: ;;
mov dword [var], 0
loop:
inc dword [var] ;; we don’t really need to keep adding to the variable
jmp loop
section .bss
var resb 4 ;; we don’t really need to start at 4

After we have removed the unnecessary lines, the resulting code will look like this:

section .text

mov dword [var], 0

loop:

jmp loop

section .bss

var resb 0

Now this program will do absolutely nothing but run blankly forever, as you can see in the loop: part all it does is jump back to the loop declaration. We take the same steps in order to compile it into a win32 binary file (using nasm and ld) as we did with the longer code and upload the resulting binary to VT:

This time we only get 2 AV’s detecting us, but if we look at behavior we get the following:

• Sandbox evasion with dummy loops

• Reading of software policies

• IP traffic

• Dropped files

• Multiple registry keys set

• Command execution

Once again throwing this into Malcore we get pretty much the same results, score of 23.02, and nothing happening in the dynamic emulation:

---

IOC Information

SHA256 of samples:

• First sample

  • a38d7017cc064ea4a41a9b2136e5a975544c54761166d1f79f502dbdd826d769

• Second sample

  • cda16eeeae01ec56ccc89d9b781f9974f390fec47d97a723a75f4cd5a7680076

Analysis Links:

• First sample

  • Malcore

  • VirusTotal

• Second sample

  • Malcore

  • VirusTotal

---

Conclusion

We have successfully tricked a well known malware analysis tool into thinking two benign samples are malicious. But how did this happen? Well the most likely scenario is that the rules and triggers are faulty which causes the code to trigger things that aren’t actually there, as for the sandboxes either they have malware stuck in the analysis engine, or they are catching things that Windows environments do and are necessary for the environment to run.

What I find most interesting about this is that regardless of what the code does, there were two AV solutions that detected both without cause. They are Rising & VBA32. Rising detected the samples as: Trojan.Generic@AI.84 (RDML:4GoQroJi0Y2w3/72Y/DnOA) & Trojan.Generic@AI.92 (RDML:bWyRkYjad6wpBQdsFCNceA) which appear to be two different classifications while VBA32 detected both samples as the same classification of Malware-Cryptor.General.3. As well as this, the first sample triggered multiple high and medium level Sigma rules. My assumption is that the Sigma rules were falsely triggered from whatever was being caught by the sandboxes.

So in conclusion, we can safely determine that someone either needs to check their AV solution signatures, or VT needs to look into their Sigma rules as well as their sandboxing technology. It seems that they are both fairly easy to trick using benign samples. I wonder if we could trick them into thinking a malicious sample is benign as well? That’s going to have to wait until next time, thank you for reading, enjoy my shameless plug below!

---