Thursday, July 5, 2018

APT28: Digging through Sandbox-Evasions with Bare Metal Analysis


In October 2017, we blogged about the advantages of analyzing malware on bare metal machines. Bare metal analysis offers the possibility to perform dynamic analysis on real devices such as laptops or PCs. The bare metal analysis is not affected by virtual machine detection, which is a major check done by most malware nowadays:


To demonstrate this, we analyzed a recent sample related to APT28/Grizzlybear which includes nine different evasion tricks.

Spotting evasive Samples on Cloud Basic

We have various triggers and alerts defined for our free online platform called Joe Sandbox Cloud Basic. Cloud Basic uses only Virtual Machines to analyze suspicious files, the bare metal analysis feature being available only in Joe Sandbox Cloud Pro

Recently, we got an interesting alert which led us to the following sample uploaded on the 2nd of July.




If we look at the behavior graph we see only one process:


The spider classification chart outlines that this sample is very likely evasive:


Further, no obvious installation or infection behavior is recorded. Therefore, we can assume that the evasions were successful.


Digging through the Evasion Checks

We reran the sample found on Cloud Basic in Cloud Pro on a bare metal W10 machine:



The resulting analysis can be found here:


If we go to the behavior signatures, section Anti-Debugging and Malware Analysis System Evasion, we find many hits:


What type of evasions has the sample used? Let us analyze the checks one by one.

1. XEON CPU

Function at address 406CFC calls CPUID and checks whenever the CPU model is XEON. This type of processor is an indicator for a server and is usually not used in a Laptop or a PC, the real infection target for the malware:



If the model of the CPU is XEON the sample will stop its execution.

2. Sandboxie Check

Thanks to our Hypervisor based Inspection technology which works on virtual machines and bare metal, user-mode API calls are traced. Interesting is the GetModuleHandle API since it can be easily used to check for loaded DLLs:



If a module with the name sbiedll.dll is found, the sample will terminate. Sbiedll.dll is a DLL of the famous Sandboxie tool which is often used to analyze malware. 

3. Sleep/GetTickCount Time Evasion

At function 406DC8 the sample performs a time evasion which detects if a malware analysis system modifies Sleeps but misses to modify the GetTickCount values. Sandboxes often shorten sleep in order to trigger future behavior. Malware can detect this by comparing the Sleep duration with other time sources such as GetTickCount:



4. Command Line Checks

The sample fails to execute if a Sandbox passes one of the following arguments:

  • -autorun
  • -update

5. Virtual Machine Detection via VideoBiosVersion

At function 407118 the malware queries the registry value of  HARDWARE\Description\System\VideoBiosVersion:


If the key value contains the string VirtualBox the sample will fail.

6. Virtual Machine Detection via SetupAPI

In addition to the previous virtual machine check, a second check is executed via the SetupAPI:



Basically, the SetupAPI is used to enumerate device registry properties. The malware checks for the string "vmware". On VMWare common device properties are:

  • vmware svga 3d
  • vmware, vmware virtual s scsi disk device

7. IsDebuggerPresent

To check for debuggers, the API IsDebuggerPresent is called:



8. Name / Path check

At function 406E04, the sample checks for the following names in the path and the sample name:

  • \SAMPLE
  • \VIRUS
  • SANDBOX
If one of the names is found the sample terminates.

9. RDTSC + CPUID Time Evasion

A second-time evasion is performed at address 406B60:


What evasion is performed? Basically, the sample measures how long the CPUID instruction takes. The measurement is done via the RDTSC instruction:


On virtual machines, the CPUID instruction executes slower compared to bare metal. The reason is that virtual machines intercept the instruction and this usually takes longer. 


Payload Analysis


Since the analysis was performed on a real machine none of the nine checks was successful. As a result, the sample injects into explorer.exe:



The sample execution then ends in a Sleep call:


This is also nicely visible in the Execution Graph. All the red nodes have been executed. All the black nodes not:



The large non-execute code includes various interesting areas, such as searching for files:


C&C communication:


Download and execute:




Executing the sample a bit longer, fully reveals the behavior of the payload and all IOCs:




Looking at the Yara rules, we finally see some hits related to APT28 / Fancy Bear implant:


Joe Sandbox, no restriction for Bare Metal analysis

Joe Sandbox does not restrict you to analyze malware on a particular virtualization solution or device. You are free to choose on which kind of machine to analyze:

  • Modern Bare Metal Laptop
  • Modern Bare Metal PC
  • Mac Mini
  • MacBook Pro
  • Bare Metal Android Phone (e.g. Motorola G3)
  • iPhone
If you use Bare Metal machines you leave malware no chance for detection. Detection techniques which are successful for KVM, VirtualBox, VMware, Xen and Qemu will fail since the malware is executed on a real device. If you already have a sandbox or are looking to get one, then ask yourself: is Bare Metal analysis supported? Or is the sandbox solely based on KVM, VirtualBox, Qemu or Xen?

Interested in Joe Sandbox? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!