Upatre Malware Anti-Sandboxing Mechanism Uncovered
Researchers have been studying the Upatre malware anti-sandboxing mechanism over the course of the past few days, after capturing a number of samples of the malware.
The Upatre malware anti-sandboxing mechanism involves a delay in activity. A 12-minute delay to be precise. That is how long it takes before the malware downloads its malicious payload. The delay is an anti-sandboxing tactic to ensure that the malware is not being executed in a sandbox environment where its actions can be analyzed and studied by security researchers. An early example of this technique can be found in any of the binaries delivered by the spam messages profiled in PhishMe Intelligence database (Threat 4301) using spam email content like that shown in the image below:
Sandbox and analysis evasion is not a new technique for malware. Many of the mechanisms utilized by malware to detect that they are under analysis are exceedingly complex. Those anti-sandboxing mechanisms look for evidence of a sandbox hidden deep in the environment.
This often takes two forms—searching for traces that would indicate that the malware is being run on a virtual machine or searching for tools used by malware researchers to analyze the sample. These tasks require comparison of registry entries, device names, and running processes against known values that would reflect that the environment in which the malware is being run is not a real computer. However, as a result of the ongoing arms race between researchers and threat actors, analysis techniques have been developed that allow for researchers to avoid giving away their presence to the malware’s runtime. In fact, many of these analysis techniques have been implemented in automated and inline sandboxing tools, where advanced and sophisticated virtual machines are used to screen content for malware.
However, the Upatre malware anti-sandboxing mechanism is somewhat different to highly technical anti-sandboxing and analysis techniques. Instead, Upatre malware exploits characteristics of researcher behavior in creating and utilizing analysis environments. A similar tactic is employed by the Dyre Trojan, in that the malware interrogates the number of cores in the computer’s processor, refusing to execute in cases where there is only one. The Dyre Trojan makes the assumption that many analysis sandboxes will utilize a virtualized processor with only one core while nearly all real, consumer-grade computers will have at least two cores in their processors.
A similar line of thinking is employed in the Upatre malware anti-sandboxing mechanism. The assumption made by the threat actor is that no real computer in use by a human being will be booted immediately before executing the malware binary. Instead, this behavior would be characteristic of a sandbox being started immediately before the introduction and execution of a malware binary.
Upatre malware utilizes the Windows GetTickCount function, used to enumerate the number of milliseconds that have passed since the Windows system was started. This is an effective means of tracking the system’s uptime, providing the malware binary an insight into the duration for which the system has been running. This anti-sandboxing mechanism is a simple branch in the malware’s execution logic. If the GetTickCount function returns a value that is too small—less than approximately 720 seconds or twelve minutes—the malware takes a branch that leads directly to a process exit. However, if GetTickCount returns a value greater than the twelve-minute uptime the malware will proceed to download and deobfuscate its Dyre malware payload.
Figure 2 shows the assembly code passed to the processor by an Upatre sample utilizing this uptime constraint. The red-highlighted breakpoint is the beginning of the code section where the value returned by GetTickCount is handled, while the black-highlighted line shows this value stored in the processor’s eax register as the hexadecimal value 0x001EA5E. That corresponds to a decimal value of 125,534 representing the approximately 125,000 milliseconds of uptime for the analysis system. After the return, immediately below the black-highlighted entry, the malware branches to either terminate the process or continue with the download and execution of a Dyre sample.
By denying researchers or sandboxing tools the ability to observe the malware’s runtime behavior, except under certain specific circumstances, the threat actor preserves an element of secrecy for his or her operations. The indicators by which an Upatre sample can be identified are not revealed, thereby preventing those resources from being shared widely among researchers. Furthermore, since the malware’s hostile behavior lies beyond the crucial uptime-dependent branch, many sandbox tools would not provide visibility into the malware’s fully completed runtime, thereby missing crucial intelligence on this rapidly evolving threat.
PhishMe customers have access to the special report on this topic in their documents folder on PhishMe Intelligence. If you are not currently a PhishMe Intelligence customer and would like further information, please contact the PhishMe team today.