Locky Ransomware: New Evasion Techniques Discovered

Cyberbit’s Advanced Malware Research Group has recently discovered new evasion techniques used in the new Locky ransomware campaign.

Locky, one of the most dominant ransomware, has recently reappeared in the wild after a pause of several weeks. The new campaign introduces new techniques for evading automatic analysis systems, such as virtualized sandboxes. FireEye analyzed one of these methods in a recent post: the Locky payload properly executes only after receiving a set of parameters in its command line arguments that are passed by the downloader. This technique makes it much harder to analyze the payload in a contained environment, as most automated sandbox solutions do not supply command-line arguments to analyzed payloads.

More recently, Cyberbit’s Advanced Malware Research group discovered these 2 additional evasion techniques:

RDTSC Instruction
RDTSC (Read Time Stamp Counter) is a CPU instruction for reading the Time Stamp Counter (TSC) register. The TSC stores the number of CPU cycles since the last reset. This instruction is often used by malware as part of a timing-based technique to detect whether it is running in an emulated environment, or alternatively, whether it is being analyzed in any way which differs the expected results from a regular infected environment (like when a debugger is present); This technique exploits the fact that most virtualized environments do not take an extra step to emulate virtualized CPU cycles, and in-fact rely on the original implementation of the hosting machines’ CPU. The payload executes the RDTSC command, knowing how many CPU cycles it requires to execute on a real machine. If the resulting cycle count is higher than expected, or if there are significant differences between multiple executions, the payload concludes the difference is contributed by the emulation task overhead, and that it is running on an emulated environment. The recent samples show that Locky used this technique to avoid being analyzed.

Figure 1 below demonstrates how this timing attack works.

1. The RDTSC instruction is called 3 times.
2. The difference, in number of cycles, between the results of the third call and the second call is calculated and stored in EAX.
3. The difference between the second call and the first call in stored in ECX.
4. EAX is divided by ECX. If the result is greater than 10 the function returns 0, in which case the program exits.

GetForegroundWindow

This API function retrieves the handle of the foreground window (the current active window). New Locky samples use this function to constantly check whether the current foreground window has changed. Only after a sufficient number of changes had occurred, Locky continues with its regular flow.

In most analysis systems, including automated systems, and even when analyzing the malware manually, the foreground window often remains unchanged. In this case the sample will simply not start its unpacking process, nor will it continue with encrypting the files on the system. Since the vast majority of sandboxing solutions execute each payload for a limited (short) time, they will ultimately terminate the inspection assuming the sample under test is legitimate

Conclusion

The extra care Locky ransomware takes to avoid being analyzed suggests that the Locky campaign is not over yet and that its authors also analyze the measures taken to break it; trying to render them useless. As new attacks are expected to surface in the near future, ransomware detection measures must should also advance to detecting and responding quickly in the wild.

By Yaniv Assor, Senior Malware Researcher, Cyberbit Advanced Malware Research Group