Nuts and Bolts Malware Lead image: Lead Image © Rostislav Zatonskiy, 123RF.com
Lead Image © Rostislav Zatonskiy, 123RF.com
 

Malware analysis in the sandbox

Under the Microscope

In malware analysis, a sandbox can provide insight into the software and its run-time environment. While a sandbox can prevent the execution of malicious code with built-in detection mechanisms, malware developers can use countermeasures to take advantage of those same detection mechanisms. By Matthias W¸bbeling

Over a year ago, the WannaCry malware infected almost a quarter of a million Windows computers around the world, encrypting data and demanding a ransom within a very short time. Due to an already closed vulnerability in Microsoft's SMB protocol, the worm was able to spread in no time at all – of course, only on computers that had not yet installed an update, which had been available since March 2017. The victims of the blackmail Trojan include some well-known corporations.

WannaCry's success was therefore largely due to sluggish update strategies. Despite all security updates, the WannaCry's further spread was accidentally stopped by the malware's own protection mechanism ("kill switch"). A young English security researcher discovered this kill switch during malware analysis. Before considering the role of the sandbox with WannaCry, I first need to differentiate between the two possibilities for analyzing malware: static and dynamic analysis.

Static Analysis

In static analysis, the file with the malicious code is not executed; instead it is opened and analyzed in a disassembler. IDA by Belgium's Hex-Rays [1] is one well-known disassembler. After opening, IDA first analyzes the binary file and prepares the information it contains. Figure 1 shows the control flow graph of a gzip function. IDA displays the CPU instructions of the individual blocks in the assembler, allowing the analyst to follow the program flow.

The gzip control flow graph as a diagram.
Figure 1: The gzip control flow graph as a diagram.

Because the program is not executed, there is of course no risk that the malware will manipulate the analysis system. To make life more difficult for analysts, many malware developers use tools to obfuscate the actual functionality. Such obfuscation then leads to unclear control flow graphs and hard-to-read assembler code.

Dynamic Analysis

In dynamic analysis, the malicious code is executed, and the execution's side effects are documented. Analysts are particularly interested in the program's interaction with the operating system: Which system functions does the program call with which parameters? Which files does it read from or write to? Which keys in the Windows registry does the program access? The answers to these questions provide valuable information on how the malware works.

Sandboxes are used in this case, because, of course, the malicious software must not run unprotected on the analysis system. Cuckoo [2] is a well-known free sandbox that lets you run malware in protected environments, such as virtual machines (VMs) with VirtualBox, and log the results. If you want to analyze a binary file dynamically without first setting up a Cuckoo environment, then online services, such as malwr.com, hosted by the Shadowserver Foundation [3], are recommended. Upload the file in question, and shortly afterward you can view the system calls, network connections, created files, and other execution parameters. Figure 2 shows the requested domain and corresponding IP address after running malwr.com.

malwr.com analyzes malware and related domains. (Note: At the time of print, this website was preparing a relaunch.)
Figure 2: malwr.com analyzes malware and related domains. (Note: At the time of print, this website was preparing a relaunch.)

Countermeasures

Of course, the malware developers also know how the currently available sandboxes work. This knowledge gives them a small advantage: They can develop mechanisms that detect execution within a sandbox and then do not trigger any damaging actions. Because a VM's environment always differs slightly from that of a physical CPU without virtualization, this gives the malware developer a reasonably reliable detection option.

One simple trick is to query the built-in graphics card. In the case of VirtualBox, the name of the card in the Windows 7 device manager is "VirtualBox Graphics Adapter for Windows Vista and 7." If a sophisticated piece of malware detects virtualization, it stops immediately. Professional sandbox manufacturers try to exclude such obvious features, with more or less useful results. In the worst case, only the (complex) static analysis choice remains if the malware refuses to execute.

WannaCry Kill Switch

The WannaCry developers adapted their detection mechanism for the special way that sandboxes handle Internet access. Many sandboxes provide an Internet emulator to limit and control, but not prevent, the malware's communication capabilities. The Internet emulator then responds to all Internet connection attempts on behalf of the requested servers. This usually happens regardless of whether or not the domain names and IP addresses actually exist.

When WannaCry is run in a sandbox, the functionality to encrypt systems and attack other vulnerable systems suddenly stops working. The shutdown was caused by the sandbox's Internet emulator. WannaCry queries a previously unregistered, cryptically structured domain. On any commercial system, the request causes a connection error because the name cannot be resolved by the DNS.

If this connection error occurs, everything seems to be okay, and the malware begins to infect other systems. However, if a connection is possible, the malware developers suspect that their malicious code is being analyzed, and nothing else happens. The spread of WannaCry in May 2017 was finally stopped by the fact that the English analysis team simply registered the previously unregistered domain. At the time, the analysis team did not even know exactly what would happen [4].

Conclusions

Sandboxes allow the dynamic analysis of malware and the investigation of effects when running in a secure environment. While analysts optimize their sandboxes to remain as hidden as possible from the malware, the dark side also optimizes the corresponding detection mechanisms.

In the case of WannaCry, the detection mechanism blew up in the attacker's face. The malware's own protection function led to a far-reaching shutdown of the malicious functions, thus preventing damage to some companies that were still vulnerable.

This article has provided a little insight into the world of analysis and countermeasure techniques. Finally, and not without a touch of irony, there is no escaping the fact that, as a legitimate user, you are probably safest inside an obvious sandbox. The only problem being that running software in a sandbox will probably not give you the performance you need.