Sandbox

About the sandbox technology

A sandbox is a system for malware detection that runs a suspicious object in a virtual machine (VM) with a fully-featured OS and detects the object’s malicious activity by analyzing its behavior. If the object performs malicious actions in a VM, the sandbox detects it as malware. VMs are isolated from the real business infrastructure.

Sandboxes analyze the behavior of an object as it executes, which makes them effective against malware that escapes static analysis. At the same time, compared to other behavior analysis designs, a sandbox is safer as it doesn’t risk running a suspicious object in the real business infrastructure.

Kaspersky sandbox

At Kaspersky, we developed our own sandbox some years ago. In our infrastructure, it is one of the tools for malware analysis, research and creation of antiviral databases. A sandbox is also a part of the Kaspersky Anti-Targeted Attack Platform and the Kaspersky Threat Intelligence platform. It helps to rate files and URLs as malicious or benign and provides information on their activity that is useful for creating detection rules and algorithms.

Sandbox features

• The sandbox is based on hardware virtualization, which makes it fast and stable.
• VMs are available for:
  • Windows OS (all personal computer versions starting from Windows XP, all server versions starting from Windows Server 2003),
  • Android OS (x86, ARM processor architecture).
• The sandbox monitors interaction of the explored process with the OS (about 30 thousands of different APIs are watched). In suspicious cases, the sandbox goes deeper.
• The sandbox provides exploit detection starting from the early phases of exploitation. It detects typical exploit behavior such as ROP chain usage, heap spraying, stack pivoting, security token changes, suspicious memory protection changes and others. The sandbox is capable of detecting even advanced exploits used in targeted attacks.

Object types that can be executed

• Windows: any files, for example: *.exe, *.dll, .NET objects, MS Office files, PDFs.
• Android: APK (DEX).
• URLs: the sandbox goes to a URL and detects the following events: downloads, JavaScript, Adobe Flash execution and others.

Malware detection workflow

1. The sandbox receives a request to scan an object (a file or a URL) from another security solution component, with instructions: the OS and the configuration for running the object, the object’s execution parameters, other third-party applications installed in the VM, the test time limit, etc.
2. The tested object is run.
3. The sandbox collects artifacts throughout the specified timespan. If the object interacts with other processes or URLs with known reputations, the sandbox captures this.
4. The sandbox analyzes artifacts and delivers its verdict to the requesting system: malware or benign. The sandbox adds the object’s data to the verdict (ID, features, logs, behavior details), which may help in further analysis without the need for a new request to the sandbox. If a certain suspicious activity is found during the sample’s execution, sandbox also returns detailed description of the activity. At the moment, descriptions of about 200 different suspicious activities are included in our sandbox.

Artifacts collected by the sandbox

• Application execution logs (API function calls with their parameters, execution events)
• Memory dumps
• Loaded modules dumps
• Changes in file system, registry
• Network traffic (PCAP files)
• Screenshots (for easier audit and manual analysis, if needed)
• Artifacts of exploit activity

Evasion prevention

It is typical for today’s malware to try to detect and evade a sandbox. Once it knows it’s running in a sandbox, it may skip performing any malicious activity, erase itself from disks, terminate itself or use some other evasion technique.

A simpler design of hardware sandbox monitoring (e.g. hooking API functions) would leave traces that indicate that a suspicious process is being watched. So, we implemented other monitoring techniques that are non-intrusive and leave no trace visible to the scanned object. The sandbox controls CPU and RAM, but does not modify process operation, memory, system libraries on disk and in memory, leaving no traces of monitoring.

We also keep track of emerging new evasion techniques and tune our sandbox to counteract them, for example:

 

Evasion A: The sandbox environment is typical of some known brand sandbox. The malware recognizes it and evades detection.

Counter evasion A: Our sandbox randomizes VM environment prior to VM start.

Evasion B: The malware can detect the sandbox environment through a lack of user activity. For some malware to run, the user needs to enter a password from an email, click through a wizard or do other ‘human’ things. Many sandboxes do not emulate this and therefore do not see the malware detonate.

Counter evasion B: Our sandbox emulates user actions: mouse movements, scrolling documents that it opens. Our sandbox also does many things that users do to activate malware.

 

Attacks revealed with the Kaspersky sandbox

Examples of new waves of targeted attacks uncovered with sandboxes in Kaspersky products of infrastructure in 2016-2017: Sofacy (Oct 2017), Zero.T (Oct, Nov 2016, Apr 2017), Enfal (Sep, Oct, Nov 2016), Freakyshelly (Oct 2016), NetTraveller (Aug 2016), CobaltGoblin (Aug 2016), Microcin (Jun 2016) and others.