• 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 analysing its behaviour. If the object performs malicious actions in a VM, the sandbox detects it as malware. VMs are isolated from the real business infrastructure.

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

    Kaspersky Lab sandbox

    At Kaspersky Lab, 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 Lab 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 virtualisation, 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 In suspicious cases, the sandbox goes deeper.
    • The sandbox provides exploit detection starting from the early phases of exploitation. It detects typical exploit behaviour 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 analyses 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, behaviour details), which may help in further analysis without the need for a new request to the 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 recognis it and evades detection.

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

    Evasion B: Due to lack of user activity, the malware knows it is in an automatically running sandbox. 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 Lab sandbox

    Examples of new waves of targeted attacks uncovered with sandboxes in Kaspersky Lab 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.

Related Products


“A simple example of a complex cyberattack”...

Read more


Vulnerable driver: lesson almost learned. How not to...

Read more


A Modern Hypervisor as a Basis for a Sandbox

Read more

RU 2460133 C1

System and method for security of computer applications

Read more

US 9116621 B1

System and method of transfer of control between memory locations

Read more

US 9147069 B2

System and method for protecting computer resources from unauthorized access using isolated environment

Read more

Independent Benchmark Results

  • ICSA Advanced Threat Defense 2017Q4

  • ICSA Advanced Threat Defense 2017Q3

  • ICSA Advanced Threat Defense 2017Q2

  • ICSA Advanced Threat Defense 2017Q1

  • ICSA Advanced Threat Defense 2016Q4

Related Technologies