This is a contributed piece by Brian Laing, VP Product Development at Lastline
When sandboxing caught on as an innovative security technique a few years ago, it posed the biggest existential threat malware creators had ever faced. Conventional defences such as anti-virus software had obvious limitations – they detected known bad malware signatures – but sandboxes promised to extend that to any malware, including sophisticated attacks exploiting zero day flaws.
On paper, the concept appeared fool-proof: Sandboxes ran unknown files in an environment that segregates them from the underlying operating system, applications, and services. This approach limits the malware’s ability to compromise a system, while enabling the security program to have greater visibility into malicious behaviour.
This approach initially presented a major barrier to malware authors because it was, in effect, a way of testing every file arriving in a network before it was run by a real user. What mattered was what the file was trying to do not whether it had been seen before.
Unfortunately, cybercriminals found a variety of ways to fool or beat the first-generation of behavioural sandboxing technologies, primarily by detecting the presence of these sandboxes and modifying the malware’s behaviour accordingly. Successful evasion techniques include the following:
Execution delay - A common technique is to delay the execution of the malware when it detects a sandbox, a stalling technique that is particularly useful against automated systems that must analyse huge file volumes. The malware is present but the sandbox analysis times out and it goes undetected. This matters to malware authors – every hour or day they can avoid being detected is more time to find real victims.
Fragmentation - Modern malware is often divided into multiple components that only execute when fully assembled. Sandboxing that does not understand this will fail to spot the danger in a file fragment that, when combined with the other fragments and fully assembled by the victim’s computer, represents risk.
Environmental awareness - Today’s advanced malware looks for tell-tale artefacts that indicate a sandbox. As an example, the Dyre banking Trojan is programmed to detect CPU cores. If it finds only one (unheard of in today’s multi-core world) it deduces that it must be running inside a sandbox. It even performs a check to detect mouse movement, keyboard clicks, the lack of which is a tell-tale sign of automated sandboxes.
Other examples simply check for the presence of hypervisors such as VMware – job done.
Exploiting vulnerabilities - The advanced Turla/Uroburos nation state malware from 2014 exploited a software flaw to escape Windows Kernel Patch Protection sandboxing. With full kernel access it was effectively invisible. This showed the brittleness of operating system virtualisation.
Blacklist avoidance - To avoid detection, sophisticated malware frequently changes the domain of its command and control operation(s). Malware detection systems that rely on blacklists to identify when a connection to a malicious domain is requested become ineffective.
Filename analysis - Among a variety of techniques, the Ursnif banking Trojan can detect whether a sandbox is running by noting whether files are prefixed (as they commonly are in sandboxing) with SHA256 or MD5 hashes. If they are, it does not execute.
Non-Windows binaries - It sounds obvious but some sandboxing systems are built on the assumption that malicious binaries will be targeted at Windows. Non-Windows binaries will yield a false negative.
This list is by no means exhaustive but illustrates the point that today’s advanced malware can detect and evade first-generation sandboxes in a multitude of ways that severely impair their effectiveness. The risk, then, is that an over-reliance on first-generation sandboxing allows defenders to sink into a false – and dangerous - sense of security.
Misdiagnosis - Even when malware runs in the sandbox it is possible to misidentify it. Good examples of this include Remote Access Trojans (RATs) that perform functions that look very much the same as legitimate programs such as support tools.
A few sandbox vendors have responded to the ability of malware to evade first-generation sandboxes with a new generation of the technology that overcome the limitations of legacy designs.
Anti-evasion - If malware is performing some of the actions mentioned above – logging mouse clicks or keystrokes, checking OS parameter, CPU cores and so on – that is a bad sign and should immediately elevate the file as suspicious.
Full-system emulation - Unlike sandboxes that examine malware inside a virtualised environment, full-system emulation runs it inside a real copy of the operating system running on emulated hardware. This is potentially much slower but is much harder (though not impossible) for malware to detect and therefore evade.
Differential analysis - Execute malware in two different virtualised analysis environments and observe any difference. Differences could indicate an attempt to game the system as malware will behave differently depending on the system it thinks it is executing on.
Bare metal - Run malware in a real environment (indistinguishable from genuine environments) and develop a system for restoring it after every run. This presents practical challenges because the environment must be separate from the analysis engine and must also reboot after every run.
Sandboxing will continue in this war of attrition for the foreseeable future with malware writers writing new evasions and sandbox makers working out how to contain and detect these. Ultimately, whichever sandbox design you use, it is important to understand that they are not intended to be an impermeable layer of defence on their own and must always be configured as part of a larger system of defence.
Jon Collins’ in-depth look at tech and society
Phil Muncaster reports on China and beyond