At parks and playgrounds, a sandbox is a relatively safe place to play. Little children who tend to fall will softly land on a cushiony pile of sand. The enclosed space also gives them room to experiment with how sand tools, toys, and their own hands and feet interact with the sand environment. A different kind of sandbox offers the same safe experimental environment in the IT world.
A runtime sandbox is a test environment in which IT professionals can release unrecognized code and monitor it to see what it does. This controlled research environment is designed to emulate a host computer, complete with an operating system, software and hardware, that is disconnected from a company’s network and other IT resources. If malicious code is tested in this environment, IT professionals can safely monitor its effects on the dummy computer without causing real damage to the network. This, in turn, can help IT professionals recognize new types of malware, prevent infection and learn how to recover from any incidents.
However, just as IT security measures are becoming more advanced, malware also is becoming smarter. Some malware code is designed to detect a sandbox environment and be on its best behavior, masquerading as benign code while in the sandbox. This allows the malware to evade detection and then conduct its malicious activity once it is allowed onto a company’s network.
There are hundreds of different methods used by various kinds of malware to evade sandboxes and work their ways onto a company’s network. These methods fall into a few broad categories of strategies:
1. Detect a runtime sandbox environment and wait to execute. Because sandboxes are controlled environments, they are “cleaner” than a normal computer environment, and different interactions happen within this environment than in a computer being operated by a regular user, according to IBM Security’s 2017 report “Evading the malware sandbox.” Advanced malware is designed to look for signs of a sandbox environment, including
- - VMware registries
- - abnormal processes running on the computer
- - a lack of normal human interactions, such as scrolling, mouse clicks and normal mouse speed.
2. Wait for sandbox testing to be over before executing. Because sandbox resources are precious, the research system can only spend a few minutes on each test run of suspicious code, IBM Security’s report states. The malware can use a stalling technique whereby it executes useless CPU cycles that look like benign code while in the sandbox. Once the sandbox has determined the code is not a threat and moves it to the normal network environment, the malware takes action.
3. Fragment itself into smaller, benign pieces to avoid detection. The sandbox will evaluate these individual pieces on their own and deem them as harmless, according to cybersecurity company Sonicwall . However, once the target system reassembles the fragments, the malware will execute.
4. Wait for a user interaction before launching. The malware waits for some type of user action, such as clicking on a link or opening or closing a file or app, before executing. If the sandbox does not perform the specified type of user interaction, it will not be able to detect the malware.
5. Obfuscate internal data. Malware authors can encrypt and conceal their strings and communications by replacing program data with hashed values that sandboxes can’t read, IBM Security’s report notes. Similarly, malware can use domain generation algorithms that can keep outsiders guessing about which domain gives updates and instructions to the malware. For example, the Necurs botnet can generate 2,048 domain names for command-and-control servers that die out every four days, according to IBM Security’s report. This makes it difficult to cut off the malware’s access to its domain.
6. Shut down active antivirus software. For example, the Client Maximus malware scans the operating system for active antivirus software processes, according to IBM Security’s report. If it detects any antivirus activity, it shuts down those processes and then executes its payload.
7. Utilize return-oriented programming. For this method, the malware modifies the stack and directs other programs to execute the malicious code, thereby hiding the threat from conventional detection, Sonicwall says.
8. Use a rootkit. This application or set of applications hides the malicious code in the lower operating system layers, where most sandboxes don’t check for malware, according to Sonicwall.
Retaking the playground
A common trend among these techniques is that the advanced malware waits to act until it is in a regular environment. To stay one step ahead of this malware, IT professionals need to develop sandboxes that are more like the desktop and network environments they are protecting, down to the last detail, cybersecurity company VMRay advises. More authentic test environments, complete with the standard software a business uses, will be more likely to catch malware in the act and help IT professionals learn how to contain and stop it. In addition, cybersecurity professionals should look to develop ways to hide sandbox hooks, or “the injected user-mode or kernel-level driver that monitors and intercepts API calls and other malware activity,” to prevent tipping off the malware to the sandbox environment, the company advises.
Furthermore, cybersecurity experts recommend that businesses utilize a multi-engine approach to identifying and containing malware. It is not enough to just employ a signature-based security methodology; IT professionals must analyze the behavior of malware too. A variety of solutions are available to help monitor for malware behavior and check for malware in the variety of places it hides.
These techniques can help IT professionals retake control of the sandbox and better defend their IT networks.