Adrian Hada
ATI Security Researcher
Blog

Escaping the Matrix—How Malware Evades Researchers (Part 2 of 3)

July 27, 2016 by Adrian Hada

In the first part of this blog series, I looked at how debugger presence is detected. Malware uses this to avoid analysts trying to reverse-engineer its functionality. When it comes to automated analysis platforms such as sandboxes, the situation is entirely different. This post looks into how malware can try to detect common sandboxing environments.

Common Sandbox Detection

Sandboxed environments are applications that use specially created virtual machines (VMs) to execute malware. To analyze malware and deliver meaningful results, the sandbox environment relies on modules and applications running inside the VM. The machines themselves can also carry specific configuration items that give them away. Some common examples include repeated use of the same Windows product number, specific user names, and file names. Sandboxing is also done on a high scale so the machines are very limited in configuration –reduced number of CPUs, little RAM, smaller hard drives, few devices, and others. Here are some examples:

Tracing Mouse Activity

As seen in blog series Part 1 in the Paranoid Fish run, not moving your mouse is considered a sign of a sandbox. Moving it too abruptly might also trigger a detection. Paranoid Fish goes for the prior:

1

Note that GetCursorPos is also a Windows API function. This is all the code that's necessary to implement such a check.

Is Your Name Really Virus Something?

Some sandboxes relied on predefined usernames such as "malware", "virus", and "sandbox". Using a random name is less of a giveaway. Of course, this can be applied to the file name (e.g., "<sha256>.exe", "sample.exe") and file path ("\\SAMPLE"). Here's the Paranoid Fish username check:

2

And here's a demonstration that the examples above aren’t all theoretical (Source: SentinelOne): 

3

  Finding Files

Sandboxes need tools running inside the VM in order to collect necessary data. Malware aware of this can easily check for certain files and modules. 

Paranoid Fish implements a check for a DLL loaded by Sandboxie:

4

Furtim malware checks for a long list of tools giving away research environments:

  • C:\agent\agent.pyw
  • C:\sandbox\starter.exe
  • c:\ipf\BDCore_U.dll
  • C:\cwsandbox_manager
  • C:\cwsandbox
  • C:\Stuff\odbg110
  • C:\gfisandbox
  • C:\Virus Analysis
  • C:\iDEFENSE\SysAnalyzer
  • c:\gnu\bin
  • C:\SandCastle\tools
  • C:\cuckoo\dll
  • C:\MDS\WinDump.exe
  • C:\tsl\Raptorclient.exe
  • C:\guest_tools\start.bat
  • C:\tools\aswsnx\snxcmd.exe
  • C:\Winap\ckmon.pyw
  • c:\tools\decodezeus
  • c:\tools\aswsnx
  • C:\sandbox\starter.exe
  • C:\Kit\procexp.exe
  • c:\tracer\mdare32_0.sys
  • C:\tool\malmon
  • C:\Samples\102114\Completed
  • c:\vmremote\VmRemoteGuest.exe
  • d:\sandbox_svc.exe

The list ranges from stuff common to different sandboxes—GFI, Cuckoo—to tools that might be used in the analysis process. Note that, in this case, the malware authors have good knowledge of multiple sandboxing environments.

Checks such as these can give away a lot of sandboxing environments. However, as shown, a carefully built environment could actually fool all of these checks. The solution to circumvent that (from a malware author's point of view) could be to simply detect a virtualized environment and avoid execution. This means that the author is giving up on targets using virtualization (servers or virtualized desktops) in order to avoid detection. In the next post we'll see how this can be accomplished.

Leverage Subscription Service to Stay Ahead of Attacks

The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.