Locky Ransomware Actors Turning To XORed JavaScript to Bypass Traditional Defenses

Share with your network!

Since Proofpoint researchers discovered Locky [1] three months ago, the ransomware has  regularly appeared among the top threats distributed via email by volume every week. Threat actors distributing Locky have used a variety of approaches to bypass security defenses and increase the flexibility of their campaigns, ranging from the use of new malware loaders like RockLoader [2] to attaching malicious JavaScript files [3] directly to high-volume message campaigns. To date, however, these actors have not obfuscated [4] network downloads in ways that we have seen in other malware campaigns. Last week, though, we observed one Locky actor (affiliate ID 1) begin using XOR obfuscation and reversing the bytes on the payloads to evade detection by network security tools.

XOR (eXclusive OR) obfuscation is a relatively common technique in which the bytes of a binary file are compared to an arbitrary byte which acts as a cipher to encode the original binary. For example, the ASCII character "A" is 01000001 in binary. If the ASCII character "B" (01000010 in binary) is used as a cipher in an XOR operation, the individual bits are compared and resolve to 1 if the bits are different and 0 if they are the same, resulting in 00000011. This technique is simple, fast, and generally effective, making it a popular choice among threat actors and a centerpiece of robust encryption solutions. The examples below refer to hexadecimal equivalents; the binary example above was provided for simplicity.

In this case, we observed payloads that were both XORed and reversed. For example,


Figure 1: Sample of XORed and reversed payloads. Note that the last four bytes are a checksum.

After removing the checksum bytes and XORing with 0x73 (ASCII lowercase s):


Figure 2: Sample after XORing with 0x73

The bytes were also reversed, so reversing the XORed bytes results in:


Figure 3: Sample after XORing and reversing

This particular campaign and others that have followed also featured multiple download locations each with a unique payload.

While this type of obfuscation can be particular effective against network security products that primarily scan executables entering the network, they can also be used for sandbox evasion.

The use of multiple download locations with unique payloads for Locky Affid=1 (and before that for Dridex ID 12x) has been observed for months. However, we first observed XORed payloads on May 23rd. These were XORed with 0xFF (11111111 in binary), but not reversed. A later campaign the same day were XORed with 0x73 and reversed. The latter was repeated for a campaign later this week, with the addition of a 4-byte checksum at the end, although most of the payloads appeared to be broken, thus failing the checksum. A campaign on May 25th used the same technique and XOR parameters but all payloads passed the checksum. Even today, the actors began using a pseudorandom number generator to create the XOR bytes, making these efforts much closer to full-fledged encryption rather than simple obfuscation.

These campaigns continue to demonstrate the trend of threat actors shifting delivery mechanisms and adding new layers of obfuscation and evasion to bypass security defenses. In the example above, the initial payload was actually the RockLoader malware loader which then attempted to install Locky from a sophisticated command and control (C&C) architecture. As always, layered approaches to security and user vigilance are critical to preventing infection from threats that are increasingly difficult to detect.



[1] https://www.proofpoint.com/us/threat-insight/post/Dridex-Actors-Get-In-the-Ransomware-Game-With-Locky

[2] https://www.proofpoint.com/us/threat-insight/post/Locky-Ransomware-Cybercriminals-Introduce-New-RockLoader-Malware

[3] https://www.proofpoint.com/us/threat-insight/post/beware-javascript-malicious-email-campaigns-with-js-attachments-explode

[4] https://www.proofpoint.com/us/threat-insight/post/Obfuscation-Techniques-In-Phishing-Attacks



Selected payload hashes

MD5: 95fe78f2a5d8b1451baf924e7d60fcc4 (141312 bytes)

MD5: 92c3ba44eac7ebe947c43ca90cc7f63e (249856 bytes)

MD5: 527290686ec5515f248d4d20c3bb29df (241664 bytes)