When Your Sandbox Fails

Working in cybersecurity is like fighting crime in Gotham City. You spend your day squaring off against faceless villains with names like WannaCry, Petya, and Red October, who are constantly coming up with new tactics, technology, and gadgets to get the upper hand. Then, after a good, hard fight, you think you've won the day, only to see old adversaries pop up a few days or even years later — stronger, smarter, and a lot more sophisticated.

For example, an old nemesis returned earlier this year with a new trick up its sleeve. The Emotet banking Trojan, initially introduced in 2014, reappeared on our radar screen, this time with an interesting twist. This new version was an XML document with a .doc extension, allowing it to potentially avoid detection because most sandboxes require true file type. Even though the true file type is XML, it's opened in Word on the endpoint.

Once open in Word, the macro within the XML file spawns a PowerShell script that calls out to a second-stage URL to download the Emotet payload. The payload then enumerates a list of installed apps and checks disk volumes to determine whether it is in a sandbox. If it is, it stops execution and shuts down. In addition, Emotet has long sleep and delay mechanisms to hinder dynamic analysis techniques, which are used by sandboxes to detect malicious activity. Genius!

Other recent threats have used similar tactics to avoid detection by a sandbox. Bebloh, a generic banking Trojan first detected in 2009, recently re-emerged as a variant targeting Japanese users. This specific variant is delivered via webmail as an Excel attachment that includes a macro, which spawns a silent command shell. Interestingly, this variant of Bebloh checks the locale and country settings at each stage of execution.

At first, the macro stops execution and quits the Excel application if the locale setting does not match Japanese. Once the command shell is activated, a PowerShell script is spawned to fetch remote content from a URL pattern that looks like a RAR file but is actually another PowerShell script that contains an embedded base64-encoded and encrypted DLL. The key used to decrypt this DLL is generated based on the country code from the culture set in the operating system. Finally, the decrypted DLL is reflectively injected into memory by another process using PowerShell, and the entry point of the DLL is called to start the malware.

The upshot is that the location settings in a sandbox would have to be set to JP (the code for Japan) throughout the entire environment to detect this infection chain — a highly unlikely configuration scenario. Bebloh checks for system uptime and physical system characteristics, and stops execution if it detects it is in a sandboxed environment.

Phishing is another area where sandboxes fail, because detection is dependent on a file exhibiting malicious behavior. Attackers can leverage a simple PDF file containing a single link to a malicious sign-in form to avoid detection. Documents with a single Uniform Resource Identifier have a very low footprint for sandboxes to detect, and the short TTL domain leaves little evidence for post-event analysis or threat intelligence services.

Emotet, Bebloh, and PDF phishing attacks are worrisome for one very good reason. They use sophisticated — ingenious, really — techniques to avoid detection in a sandbox environment. Sandboxing has traditionally been used as a tried-and-true method for protecting users from web-based threats by quarantining malicious content before it reaches a user's device. In the past, this has been enough. Attacks have been detected and then placed into a sandbox environment, where they can be walled off from the network and analyzed for future remediations. Up until now, this strategy has worked well.

However, sandboxing relies on detection. If a threat is able to mask itself, shut itself down, or evade detection in some way, it pretty much has free rein to infect users' devices, enabling it to eventually make its way into the network and critical business systems. And that's a problem. In a detect-and-respond cybersecurity strategy, once a threat gets past the front gates, it's game over.

This evolution of threat tactics and technology is nothing new. Malware and other web-based attacks are constantly evolving to counter traditional cybersecurity solutions. It seems that for every step forward we make as an industry, threat actors have a countermeasure in hand almost immediately — making cybersecurity a constant back and forth on the front lines.

Network separation and web isolation are two alternatives to a cybersecurity strategy based solely on detection. These solutions simply remove any connection between users' machines and the public internet. Network separation prevents users from accessing the public Internet on any computer connected to the corporate network — often requiring users to rely on two computers. Web isolation allows web browsing but moves the fetch and execute commands off of endpoints and onto a remote isolation server on-site or in the cloud. Rather than trying to detect whether content is safe or risky, network separation and web isolation assume everything is risky and never allow the user to connect directly to the web. (In full disclosure, my company, Menlo Security, along with others in the industry, markets web isolation technology.)

The sandbox is still an important piece of the security stack, but an organization's entire strategy shouldn't be reliant on its ability to detect every threat. Even Batman needs to accept that some attacks are a given and that the best security strategy is to contain the threat, away from the citizens of Gotham, in such a way that they don't even know there was an attack!

Related Content:

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.