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.

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.

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.