To better understand modern malware detection methods, it’s a good idea to look at sandboxes. In cybersecurity, the use of sandboxes has gained a lot of traction over the last decade or so. With the plethora of new malware coming our way every day, security researchers needed something to test new programs without investing too much of their precious time.
Sandboxes provide ideal, secluded environments to screen certain malware types without giving that malware a chance to spread. Based on the observed behavior, the samples can then be classified as harmless, malicious, or “needs a closer look.”
Running programs in such a secluded environment is referred to as sandboxing and the environment the samples are allowed to run in are called sandboxes.
Definition of sandboxing
Let’s start with a definition so we know what we are talking about. There are many definitions around but I’m partial to this one:
“Sandboxing is a software management strategy that isolates applications from critical system resources and other programs. Sandboxing helps reduce the impact any individual program or app will have on your system.”
I’m not partial to this definition because it is more correct than other definitions, but because it says exactly what we want from a sandbox in malware research: No impact on critical system resources. We want the malware to show us what it does, but we don’t want it to disturb our monitoring or infect other important systems. Preferably, we want it to create a full report and be able to reset the sandbox quickly so it’s ready for the next sample.
Malware detection and sandboxing
Coming from that definition, we can say that a cybersecurity sandbox is a physical or virtual environment used to open files or run programs without the chance of any sample interfering with our monitoring or permanently affecting the device they are running on. Sandboxing is used to test code or applications that could be malicious before serving it up to critical devices.
In cybersecurity, sandboxing is used as a method to test software which would end up being categorized as “safe” or “unsafe” after the test. In many cases, the code will be allowed to run and a machine learning (ML) algorithm or another type of Artificial Intelligence (AI) will be used to classify the sample or move it further upstream for closer determination.
Malware and online sandboxes
As sandbox technology development further progressed and as the demand for a quick method to test software arose, we saw the introduction of online sandboxes. These are websites where you can submit a sample and receive a report about the actions of the sample as observed by the online sandbox.
It still takes an experienced eye to determine from these reports whether the submitted sample was malicious or not, but for many system administrators in a small organization, it’s a quick check that lets them decide whether they want to allow something to run inside their security perimeter.
Some of these online sandboxes have even taken this procedure one step further and allow user input during the monitoring process.
This is an ideal setup for those types of situations where the intended victim needs to unzip a password-protected attachment and enable content in a Word document. Or those pesky adware installers that require you to scroll through their End User License Agreement (EULA) and click on “Agree” and “Install.” As you can imagine. these will not do much on a fully automated sandbox, but for a malware analyst, these samples would fall into the category that requires human attention anyway.
Sandbox sensitivity
In the ongoing “arms race” between malware writers and security professionals, malware writers started to add routines to their programs that check if they are running in a virtual environment. When the programs detect that they are running in a sandbox or on a virtual machine (VM), they throw an error or just stop running silently. Some even perform some harmless task to throw us off their track. Either way, these sandbox-evading malware samples don’t execute their malicious code when they detect that they are running inside a controlled environment. Their main concern is that researchers would be able to monitor the behavior and come up with counter strategies, like blocking the URLs that the sample tries to contact.
Some of the methods that malware uses to determine whether it is running in a sandbox are:
- Delaying execution to make use of the time-out that is built into most sandboxes.
- Hardware fingerprinting. Sandboxes and Virtual Machines can be recognized as they are typically different from physical machines. A much lower usage of resources, for example, is one such indicator.
- Measuring user interaction. Some malware requires the user to be active for it to run, even if it’s only a moving mouse-pointer.
- Network detection. Some samples will not run on non-networked systems.
- Checking other running programs. Some samples look for processes that are known to be used for monitoring and refuse to run when they are active. Also the absence of other software may be considered an indicator of running on a sandbox.
Sandboxes and virtual machines
In the previous paragraph we referenced both virtual machines and sandboxes. However, while sandboxes and virtual machines share enough characteristics to get them confused for one another, they are in fact two different technologies.
What really sets them apart is that the Virtual Machine is always acting as if it were a complete system. A sandbox can be made much more limited. For instance, a sandbox can be made to run only in the browser and none of the other applications on the system would notice it was even there. On the other hand, a Virtual Machine that is entirely separated from the rest of the world, including its host, would be considered a sandbox.
To make the circle complete, so to speak, we have seen malware delivered in the form of a VM. This type of attack was observed in two separate families, Maze and Ragnar Locker. The Maze threat actors bundled a VirtualBox installer and the weaponized VM virtual drive inside a msi file (Windows installer package). The attackers then used a batch script called starter.bat to launch the attack from within the VM.
If you’d like to know more technical details about these attacks, here’s some recommended reading: Maze attackers adopt Ragnar Locker virtual machine technique
The future of sandboxing
Keeping in mind that containerization and virtual machines are becoming more common as a replacement for physical machines, we wonder whether cybercriminals can afford to cancel their attack when they find out they are running on a sandbox or virtual machine.
On the other hand, the malware detection methods developed around sandboxes are getting more sophisticated every day.
So, could this be the field where the arms race is in favor of the good guys? Only the future will be able tell us.
Stay safe, everyone!
