Modern malware doesn’t break out and wreak havoc the moment it lands in your network. Instead, upon establishing a beachhead, it usually implements a series of evasive techniques in order to remain undetected by cybersecurity tools protecting the network. Evasive techniques have now become a vital part of malware attacks, making it important to understand them to be able to implement effective countermeasures.


This is the first of a series of blog posts covering some of the more common evasion techniques used by malware developers, starting with what is arguably the most widely used technique—sandbox evasion.


What are sandboxes and why do malware employ evasive techniques against them?

A sandbox is an isolated and controlled virtual environment that’s used for testing and analyzing suspicious inbound files – which can potentially be malware – before they are allowed into the network. A sandbox mimics systems running in production in order to trick malware into executing as they normally would. That way, they can be analyzed without the malware affecting real production environments.


Because sandboxes are widely known, malware developers now equip their malware with functions/capabilities that enable them to identify that they are in a sandbox so they can evade these virtual environments and trigger only once they have actually entered the network. Typical sandbox evasion techniques include the following:


Environment evaluation

The first thing a malware with sandbox evasive techniques does is determine if it is currently in a virtual environment. To do that, it makes a number of system queries:

  • Registry – If the registry shows an unusually low number of installed applications, this could be an indication of a sandbox environment;
  • Hostname – Some sandboxes use certain hostnames or include certain characters in their hostnames;
  • Number of running processes – An unusually low number of running processes can be indicative of a sandbox environment;
  • USB drives and printers – The presence of peripherals would usually be indicative of a real production environment;
  • Hard disk size – Regular machines usually have hdd sizes over 100gb. An abnormally small disk size would could be indicative of a sandbox;
  • Screen resolution – It’s highly unlikely that anyone would work today on a very low screen resolution (e.g., 800×600);
  • Number of CPUs – No-one works on single CPU computers nowadays… except virtual machines.
  • RAM size – An unrealistically small RAM size (e.g. 1GB) can be indicative of a sandbox;
  • A sandbox agent – Some sandboxes are agent-based.
  • Malware.exe – For matters of simplicity and convenience, many sandboxes change the inspected filename to something along the lines of “”maleware.exe””. Many malwares check for the existence of a malware.exe files as an indication of it being present in a sandbox.

If the result of these checks indicate the presence of a sandbox, the malware will simply not execute and wait until it has passed the sandbox so it can execute in the network.


User interaction detection

Real production environments are usually characterized by user interaction such as mouse clicks, mouse movements, key strokes, document scrolling, etc. Some sandbox environments emulate user interactions in order to appear to be real production environments. However, some malware are smart enough to distinguish simulated behavior to real user interaction. So, if the malware doesn’t detect any user interaction or if it identifies so-called user interactions as machine-generated actions emulating user interactions, it will not execute.


Time-based evasion

Most sandboxes won’t hold a file indefinitely, as doing so may impact productivity if the file in question is part of a business process. Moreover, sandboxes are resource-intensive. Malware aren’t subject to these types of pressure. They can therefore simply stay dormant until the sandbox times out. They can also wait for certain actions to take place, such as a reboot or a login, as such actions aren’t normally carried out in sandbox environments. Only then will they activate.


How Minerva uses these evasion techniques against Malware and Ransomware

Minerva’s hostile environment simulation (HES) system is a layer between the OS and processes which completely controls how processes perceive their environment. With HES, we turn the malware’s evasive properties against itself, in this case by convincing it that it always in a sandbox, effectively causing it to never deploy.


For example, as discussed above, many malwares check for the existence of a malware.exe file.


In a regular system, querying for this file will result in a “”file not found”” reply from the system, as most normal people don’t have any malware.exe files on their pc 🙂

Figure 1: Normal system cannot find malware.exe file

However, with Minerva enabled, when querying for a malware.exe file, Minerva’s platform intercepts the request and displays an imaginary malware.exe to the requestor. It is important to note that no such file actually exists, but Minerva is simply simulating the existence to the process even though the file isn’t really there!


Figure 2: Minerva simulates the existancec of the malware.exe file

Whenever an evasion technique is intercepted by Minerva, an alert and event are recorded on the platform dashboard, which can later be analyzed. This provides insight into attacks that have occurred, even though they have already been prevented at the earliest stage.


Figure 3: Dashboard alert for sandbox artifact

Figure 4: Sandbox event on Minerva dashboard


These are just a few of the thousands of evasion techniques that Minerva simulates. There are still many evasion techniques (even sandbox techniques).

As mentioned before, this is just the first of a series on malware evasion techniques, so stay tuned for more in the future.

To learn more about Minerva’s Ransomware Protection Platform visit here