Behind the Scenes with Ransomware

Locky (.osiris)

O Locky, Locky! Wherefore art thou, Locky?

Alas, could Locky be no more? At the beginning of 2017, data from the field suggested potential Locky infections had decreased dramatically, so we were hoping it was on its way out. Unfortunately, Locky returned with a vengeance, though it had changed its methods somewhat. Upon further investigation, we located a number of binaries in %temp%, “a1.exe” and “a2.exe “, instantly seeing a connection to Nemucod; a name given to a family of Javascript droppers.

After additional research and decompiling several scripts, we’ve come to the conclusion that the same scripts used in previous months to distribute the .crypted “Nemucod” ransomware were suddenly downloading Locky and Kovter instead. Why the change?

Various online reports suggest that Necurs—a set of rootkit/botnet control servers—had gone offline. These were the same servers that sent out massive amounts of spam containing Locky droppers. Based on the information available, we think the bad guys changed their delivery method when these servers fell out of commission. (Incidentally, blocking the %temp% files blocks the infection, so we’re in a good position here!)


The Nemucod script developer used a simple script that runs another script which is then hosted on a compromised website. Those websites then randomize the contents of the script every few minutes. This means that security solutions that still use static signatures are often laughably ineffective at stopping these threats. The randomized website script is not part of the initial script, and is only readable via attachment to the WSCRIPT.exe process.

Initial script received via email:


As you can see, the script above uses “GET” to grab the response text from 1 of 5 compromised websites (var x) and evals that response text.

Sample response text from a compromised site:


When de-obfuscating scripts, I find it simpler to reverse the function used to evaluate the obfuscated content. I de-obfuscated this response script by using the initial script above with the previous function for the variable z2, which is actually eval, as follows:


was modified to


Here’s the final script, which downloads and runs the files (a1.exe and a2.exe).


Below is an example of the network traffic from this script, where the &r parameter is the downloaded payload.




This ransomware is still only being distributed via compromised user accounts on RDP enabled machines. The most recently used extension is “.wallet” and it’s very common to see the ransom note email as *

Below is a ransom note example:




We discovered Spora last month, but data from the field suggests it isn’t too prevalent. The most common infection vector for Spora is Google Installer messages, which are displayed from third party advertisers while browsing the web. The total cost of all services is $120, which is significantly less costly than other ransomware variants, many of which demand at least 2 Bitcoins.

The image below illustrates the different prices for various services.


It also attempts to clear shadow copies via vssadmin.



This ransomware is distributed via compromised JBOSS servers and usually propagates to every system on a network. The most recently used extension is an ironic “.weareyourfriends”. It usually installs in %System32%, since it is typically runs with administrative rights.

Ransomware Staging Tool

Script kiddies looking to make some money need look no further. This ransomware staging tool is exactly what it sounds like: a utility where you just enter your information, browse the folders you want to encrypt, and wait for the money to roll in! We’ve seen a number of variants similar to the binary below. This is so new that it doesn’t yet have its own name, but all variants have been found on compromised RDP systems.



Over the last couple of months, the data we’ve seen underscores how important it is for system admins to secure RDP. Unsecured RDP essentially leaves the front door open for cybercriminals. And since modern criminals can just encrypt your data, instead of having to go through the trouble of stealing it, we shouldn’t make it any easier for them to get what they want.

Categories: Ransomware

Leave a Reply

Related Posts


Webroot Security Predictions for 2018

  Webroot Security Predictions 2018 Ransomware / Malware Backups will not prove enough to stop ransomware as hackers find ways to subvert this strategy.  –  George Anderson, director of product marketing, Webroot Malware campaigns will use Read more…


Webroot – Top 10 Nastiest Ransomware infographic

GET FREE TRIAL Success! Now check your email to confirm your subscription. There was an error submitting your subscription. Please try again. Email Address Subscribe Related


Webroot – Top 10 Nastiest Ransomware Attacks of 2017

Top 10 Ransomware Attacks of 2017 We’re revealing the top 10 nastiest ransomware attacks from the past year. NotPetya came in on our list as the most destructive ransomware attack of 2017, followed closely by Read more…

%d bloggers like this: