Ransomware: Locky, TeslaCrypt, Other Malware Families Use New Tool To Evade Detection

Today we identified a new tool actively being used by the Locky ransomware family to evade detection and potentially infect endpoints. Unit 42 identified slight changes in Locky detonations through the AutoFocus threat intelligence service, correlating global data to discover a new tool being used to pack multiple ransomware families. Adversaries are constantly seeking new techniques to bypass security controls, and based on data from AutoFocus, this represents a widespread update to their tradecraft.

In our analysis, multiple malware samples stood out due to what seemed like obfuscated API calls coming from a dictionary of embedded terms to resolve system functions and hide their true capabilities from commonly used static analysis tools.

(Oddly named variables passed to API calls)

Tampering with the API calls takes away the ability to classify based on key names, thus increasing the likelihood that the malware will go undetected. This, however, is where it gets interesting, as it appears this was just the first in a series of misdirections designed to throw off analysts.

When looking at the new samples, the import tables for libraries to load on execution would differ significantly and not actually be used at all during execution. This prevented any sort of meaningful detection by import hashing. Additionally, looking at the executable version information showed varying information per sample but a clear pattern that can be used for future identification.

LegalCopyright

Copyright \xa9 2017

InternalName

Phoneticist

FileVersion

218, 158, 104, 112

CompanyName

Cyber Power Systems Inc.

ProductName

Nesting Punk

ProductVersion

221, 202, 46, 180

FileDescription

Skittles

LegalCopyright

Copyright \xa9 2015

InternalName

Grated

FileVersion

82, 233, 256, 103

CompanyName

SafeNet Inc.

ProductName

Geomagnetic Espadrilles

ProductVersion

176, 194, 91, 229

FileDescription

Connectivity

Within each sample of malware we found different embedded strings, some used and some unused.

(Word list)

Upon closer inspection, it appears that the author uses a lot of the terms to generate noise and pointless instructions in an attempt to make analysis more difficult. In the below picture, highlighted in red, is where this sample begins to get serious about unpacking and walks the PEB structure to identify the base address of kernel32.dll.

(Start of the PEB walk)

On every run, it advances forward one DWORD and eventually compares a value that is XOR’d against 0x958B9963 to see if it’s found kernel32.dll.

(Upon finding the intended target DLL it saves it into a register)

Now that it has the base address for kernel32.dll, it begins to enumerate functions, continually changing the variables on the stack during this process to further misdirect their intentions.

(Function iteration)

(Finding the target)

Once it identifies the location of the VirtualAlloc function within kernel32, it begins to position the necessary variables to call on the stack while continuing to try and hide within the noise. As shown below, once the stack is setup, it does a direct JMP to VirtualAlloc, providing a return address that eventually leads to a couple of decoding routines.

(JMP to VirtualAlloc to allocate space for the encoded data)

(Decoding data into allocated space)

Once finished with this phase, the malware shifts execution into the newly decoded data and continues to modify itself through multiple iterations.

(Self-modifying its code at run-time)

Recall from the beginning of this post that abnormal arguments passed to API calls were the first clue something had changed. In this phase, you can follow the self-modification to the next set of red herrings before it gets down to business again.

(Code continues to JMP to new offsets, modifying all subsequent instructions)

(JMP after JMP, with one actual instruction hidden deep within)

This will eventually lead to a call for LoadLibraryA with bogus names that do not map, which end-up failing and return a NULL result effectively serving no purpose but to confuse.

(More red herrings)

Once this all completes, it will allocate another region of memory and then copy over and decode the actual malware, similar to the above process.

(The final payload of the packer)

When we extract the payload, we can validate that it is indeed Locky and accurately gets detected.

Palo Alto Networks has identified this technique being picked up recently by the Locky ransomware, but we have also identified samples of TeslaCrypt and Andromeda malware families, dating back to March 14, 2016, that exhibit the technique. It is important to note that this obfuscation can be detected by dynamic analysis, which is used in combination with static analysis by WildFire service to protect Palo Alto Networks customers from this threat.

WildFire is able to detect this new packing technique being utilized across the malware families described in this post, as well as detect each family after unpacking. Users of AutoFocus can find more information on impacted malware families with the Locky, TeslaCrypt and Andromeda tags.