5 Ways Hackers Killed the Sandbox — and What to Do About It
Sandboxes, the standard go-to cyberthreat protection module for many organizations, aren’t what they used to be. Once considered a premiere tool for cybersecurity protection, hackers have figured out how to compromise them.
A sandbox, of course, is where a security-conscious IT department will route a file to analyze its contents before releasing it to the user. The sandbox runs the file in an environment isolated from the working system and checks to see if there is any suspicious activity. If there is, the file gets dumped—and if it gets approved, users can feel confident that they can work with it without unleashing malware that could terribly compromise the organization.
At least that’s how it’s supposed to work. But while hackers have moved on and developed increasingly sophisticated techniques to beat the system, sandboxes—which have been around for years—haven’t really changed. Hackers today are armed with a slew of evasion techniques that have all but rendered the sandboxes ineffective, if not virtually irrelevant.
Here are five ways hackers have “killed” the sandbox:
Delayed Execution: This involves a malware attachment delaying its activity until after the sandbox finishes checking it. A sandbox typically analyzes a file for 7 to 20 minutes, so malware can just go to sleep during that processing time, and wake up after 25 minutes. In some cases, malware can be programmed to execute on a particular date or at a particular time, a technique known as the “logic bomb.” For example, Shamoon malware was discovered in 2012 when it was used for targeted attacks on high-revenue businesses in the Middle East. To evade sandboxing, this virus was programmed to execute its logic bomb at a certain date and time.
Hiding Malicious Code in Password-protected Attachments: Unless the sandbox knows the password of a file, it won’t be able to open it to examine attachments or macros, where malware is often stored. These files are usually sent in a phishing scam, where recipients are convinced that the file is legitimate (perhaps from a client), and that it was sent to them password-protected to ensure “security”—with the password written in the email “for their convenience.”
Data Obfuscation and Encryption: Standard sandboxes can’t decipher encrypted traffic, so if hackers send files in this manner, the sandbox won’t catch it. Malware accomplishes this by changing or encrypting its code and communications so that the sandbox can’t analyze it. For example, a trojan called Dridex encrypts API calls so that traditional malware sandboxes can’t read them.
Remotely Called VBA or Javascript: In this scam, hackers include what appears to be nothing more than an innocent link in a file, thus raising no suspicions on the part of the sandbox. The malicious code is downloaded only after the file passes sandbox inspection.
Malware Detection of Sandboxes: This method involves hackers dispatching a file with attached malware that can actually detect if it is in a sandbox environment. For example, according to IBM’s SecurityIntelligence, “Many detection programs also create hashes for file names they analyze. Since a hashed file name is always longer than 30 characters, the threat actors can simply check the length to determine whether their malware is in a sandbox.” Other approaches include malware checking for discrepancies between virtual and physical systems, such as the number of CPU cores; malware looking for devices, such as a printer; or malware checking the availability of antivirus programs by looking for active processes. If the malware detects these telltale signs of sandbox activity, it will simply remain inert until it finds itself in a production environment.
Moving Out of the Sandbox
So what can we do about it? Instead of focusing on the behavior of malware—which, as we have seen, can be easily hidden—solutions need to concentrate on the actual exploit technique behind the malware. While there may be millions of new malware a month, there are a limited number of exploits, and an intelligent system that can monitor those exploits will prove far more effective than a sandbox.
To do that, the monitoring system needs to compare what is going on with what is supposed to be going on. If an array of software in use is supposed to affect an operating system or a CPU in a specific manner and the monitoring system records activity in the processor that does not match the expected profile, that anomaly could be a sign that there is an attempt to exploit. In that event, the system could automatically “arrest” the rogue processes without requiring manual intervention from administrators.
This deterministic, black-and-white view of incoming code is far more effective in protecting IT systems than the behavioral/heuristics-based sandboxes that many organizations rely on. By monitoring the IT system in real time and checking for the exploits that hackers must use if they want to accomplish their goals, threat detection can become far more reliable and effective. And in an era where small changes in behavior can easily go unnoticed, advanced threat technologies must detect an attack before these changes can occur.
