New Ransomlock Variant Bypasses Automated Threat Analysis Systems’ Sandboxes

A lot of malware modify themselves to either hide from security software when they copy themselves to the compromised computer or to hinder engineers attempting to analyze the malware by executing the decrypted memory area and reading the decrypted memory value. This blog examines the behavior of Trojans that modify themselves by sharing memory.

The malware process follows the red line in Figure 1.
 

Figure 1. Code showing the threat process
 

Address ebx-4 indicates the top of the .data section. Initially, ebx-4 is a zero so if it is compared to 31h and 32h, it fails.

The code writes 31h to address ebx-4 and the Trojan executes itself by executing the WinExec function with its own file name. It then uses the ExitProcess function to end itself. It appears that the program just executes and quits repeatedly since the value at ebx-4 is always 0 at execution, but it does perform malicious activities. Here’s the trick.
 

File structure

This file sample has the following .data section structure.
 

Figure 2. File structure of the file sample
 

The characteristic rw- d0000040 is an unusual configuration and has the following settings.
 

The memory value is shared because of the IMAGE_SCN_MEM_SHARED setting.
 

Actual behavior

When the malware runs for the first time, the address ebx-4 is zero so the code writes 31h to the address and executes itself again. When it runs again, because ExitProcess has not yet executed, it shares memory that has 31h at the address.
 

Figure 3. Process follows different route when run again
 

The newly executed program writes 32h at the address and executes itself again. The new program shares memory that has 32h at the address.
 

Figure 4. Process reaches decryption routine
 

Because the address is 32h, it executes the _decrypt function, decrypts encrypted code, and jumps to the esi address. The behavior is shown below in sequential order:

1. Windows loads the file
2. The address has 0 as its initial value from the file
3. Modifies the value to 31h
4. Executes itself
5. Windows loads the file image except shared memory; the original file still has 0 on the disk image
6. The program runs with the value 31h
7. Exits the first process
8. Modifies the value to 32h
9. Executes itself
10. Windows loads the file image except shared memory the original file still has 0 on disk image. The program reaches to decryption routine and the computer is now compromised
11. Exits the second executed process

Figure 5. Behavior shown in sequential order
 

Process behavior in a sandbox

I believe the attacker tried to hide the malicious behavior from automated threat analysis systems. I submitted a sample file to eight websites that host automated threat analysis systems and the following are the results:

1. ThreatExpert logged the created file, registry modifications, and unexpected network access. Therefore, I recognized the sample behavior and decided that the file is malicious.
2. Three websites logged that the process executed but nothing else.
3. The other four websites did not log anything.

It seems that automated threat analysis systems only monitor the red section shown in Figure 5. We often see this type of specialized code to bypass these automated systems.

Symantec will continue to monitor the type of malicious code and the techniques outlined in this blog. We also recommend that users do not run suspicious programs and keep their operating system and antivirus software up to date.