This post was prepared with the invaluable assistance of Rahamathulla Hussain and Girish Kulkarni.
During the last couple of weeks, McAfee Labs has observed a huge increase in spam related to Locky, a new ransomware threat spread via spam campaigns. The contents of the spam email are carefully crafted to lure victims using social engineering techniques. McAfee Labs blogged about Locky in March. You can read more about Locky in McAfee Labs Threat Advisory. We have recently observed new campaigns of Locky and have described them below.
Locky arrives through a spam email attachment that evades antispam filters and attempts to trick users via social engineering into opening the attachment. In general practice, these Locky payloads have not been obfuscated in these campaigns. On May 24 we first observed a payload obfuscated with XOR. XOR (exclusive OR) obfuscation is a logical operation that outputs “true” only when inputs differ. This technique is simple, fast, and generally effective to evade the detection. In this case the malware was XORed with 0xFF.
The XORed payload (hash: 7FD3E08F67C6B8CC4031D056F71B9762) looks like the following snippet:
After XORing with 0xFF, the sample appears in its original format, the Locky executable:
XOR and reverse obfuscation
After a couple of days, we observed another enhanced technique used for obfuscation: XORed and reversed. At first, the malware sample (C60DE80123131AC980F4E49DAD20A89D) looks like a junk file. In fact it was XORed with 0x73 and reversed. The encrypted malware sample:
This version of the payload comes with an additional last four bytes as a checksum. After XORing with 0x73 the sample appears like this:
After removing the checksum and reversing the bytes, it is again a Locky executable.
As expected, the attackers have now come up with a new twist, encoding the downloaded file. This step is a new and different deployment behavior to avoid detection. In the last couple of days, we have received several samples of this kind.
After removing the first layer of obfuscation, parts of code become more visible. Now we can see the obfuscated URLs that download the payloads once fully deobfuscated.
After the second layer of deobfuscation, we finally obtain more visible code. Here we can see the URL of three compromised websites from which the script tries to download the payload.
The script will try the second URL if the first download fails, and so on. If successful, it downloads the encoded payload, which at first looks like a junk file.
Let’s take a look at the steps to decode the junk file:
Step 1: Validate the downloaded file by calculating its checksum. The body of this function follows:
Step 3: Run the decryption algorithm on the reversed file. After successful decryption, we see the payload is Locky. We have seen two variants so far, with the only change Key2. The pseudocode for the decryption mechanism follows:
Step 4: After decoding, the file checks the size and a valid MZ signature. If the check fails, it repeats the process in search of a valid payload. The body of the check function looks like this:
Step 5: The script executes the payload after Step 4 is successful.
The cat-and-mouse game between ransomware developers and security vendors goes on. We can expect ransomware to continue to display new evasion techniques.