Crypto-Ransomware Running Rampant

There's no doubt that ransomware is one of the most popular malware threats of 2014. Zscaler is not alone in this opinion, as other security firms have observed up to a 700% increase in infection rates to ransom-like malicious activity on victim PCs.  It's no wonder the attacks are so effective when for example, the delivery mechanism is designed to impersonate a legitimate service such as a harmless eFax.

This link is seen from a phishing e-mail.

Ransomware attacks can be monetized quickly and efficiently without the need to create a large scale botnet or expose the attacker's affiliate ID via click-fraud schemes. We've seen multiple attack vectors leveraged to target end users. Some vectors we have monitored include phishing email links or a malvertising campaign which leverages exploit kit distribution. Attackers will often pose as legitimate services, such as a law enforcement agency or a mass media outlet, in order to lure the unsuspecting victim into their scheme.

We recently encountered a ransomware campaign leveraging phishing e-mails purporting to be from the Australian Postal Services. The spam campaign themes used by the attackers involve tracking services or mobile invoices containing a link to the malicious content.  Upon completion of a CAPTCHA, the user is provided a zip file which contains a malicious executable posing as a PDF document.

At the time of research, this particular file shows a a detection rate of 16/53 antivirus engines on Virustotal. Before the victim even has a chance to realize their mistake, they are greeted by a message informing them of just how impacted they are.

It's rare for a piece of malware to name itself to the victim...

The goal of Cryptolocker or any other Crypto-Ransomware attack is to encrypt personal files and hold them hostage. The attacker encrypts the files using a specific key which is either obtained during the phone home request to a Command & Control (C2) server, or hard-coded within the malicious executable. In  this case, the malicious executable itself is falsely presenting itself as a valid executable for AQQ IM. 

AQQ is a popular IM application

Cryptolocker's encryption has been an evolving piece of this threat, often relying on asymmetric encryption to lock the victim's files.  In this particular version, the Cryptolocker variant targeted the following folders for encryption:

•  C:\MSOCache\All Users\
•  C:\Users\[Public/Username]\

The ".encrypted" files can only the key controlled by the attacker can release them.

The threat will also drop a file in the Windows directory and an associated registry key to launch the file upon boot.  This will ensure that the threat will remain persistent if the victim attempts to reboot their system.

The autostart value is randomly generated.

Cryptolocker will phone home to a hard-coded malicious domain via SSL. The SSL certificate is signed using the printable string 'debian'. This transaction is the secure communication which will provide the specific key needed to encrypt the victim's files.

Viewing the C:\Windows\uhjrajyj.exe in this case will reveal the hardcoded domain used to phone home.

The phone home address is hard-coded within the malicious payload.

Decrypted SSL traffic reveals the initial call back attempt that contains a POST request with victim's machine name and unique ID as seen below:

Decrypted call back attempt

This variant was found to be using a Domain Generation Algorithm for the C2 server communication, similar to the phone home method of Zeus.GameOver.

DGA activity

These domains are largely returning 504 errors now as they have either not yet been registered or have already been shutdown.  A few do were still live at the time of the research.  Zscaler inspected the associated IP addresses and found them to be hosted in the Russian Federation. The two server IP addresses of note at the time of the blog are 46.161.30.20 and 46.161.30.19.  Active ransomware URLs leading to these servers include:

• usygoseqowapadoh[.]com:443
• usygoseqowapadoh[.]com/topic.php
• octoberpics[.]ru:443
• octoberpics[.]ru/topic.php

Conclusion

Administrators should be on the lookout for the above connections as they likely indicate a compromised system. Given how prevalent this threat is, the U.S. Government recently released an associated alert on the US-CERT site. 

Taking regular backups of your personal files remains a user's best chance at mitigating the threat if they have been hit by this attack. It is also important for system administrators to enforce  strict file-type access control policies surrounding the download of archive and executable files from unknown sources.

Final encounters with a web comment spammer

In the last part of my series on web comment spamming applications, I want to pass along a few things I noticed that were effective at separating the spam apps from the humans. Many of these have been publicly discussed already, but they still are worth repeating. Also, note that none of these techniques provide a permanent, fool-proof way to stop spam apps. These suggestions will curb the tide of comment spam that is being spewed by today’s spam apps--but tomorrow's spam apps, if adapted, would be able to circumvent these mechanisms. Anyways, onto the mechanisms.

Use Javascript
All of the spam apps I've encountered to date do not run Javascript. So you should utilize some Javascript mechanism to manipulate the form before it is submitted. You can dynamically change the form action URL upon loading or submission, update the value of a hidden field to indicate Javascript is present and functioning, etc. Any submission to the wrong form action URL or without the proper hidden field value should be discarded.

The downside of this approach is that it requires the user to have Javascript enabled in their browser. While Javascript is mostly ubiquitous in the Web 2.0 world we live in, browser plugins like NoScript are still highly popular. So you have to make the executive decision on whether you want to require your users to enable Javascript to use your form...which might not be a problem if you already require it for other things (i.e. Web 2.0 elements in use on your site).

Monitor the time it takes to fill out the form
My simple experiment kept track of the time between when a spam app requested the form to when the form was submitted. What I saw was that the form submission was done immediately. There is no way a human would be able to reasonably fill out the fields of the form in under, say, two seconds. This provides a simple way to discard spam simply by keeping track of when the form was requested (via a time value stored in server-side session storage or within a hidden form field) and when the form was received by submission (compare current time with previously stored time).

Now sure, spam apps can get around this by slowing down a bit during the form submission process. But since these apps are trying to spew out tens/hundreds of thousands of spammy form submissions, requiring each submission to slow down causes significant time overhead for the user of the spam app. Are they willing to be patient and wait 10 times longer for their spams to be submitted?

Use CSS to hide some form fields
The spam apps liked to populate every text input field in the form with some kind of value. You can wrap a field in a HTML DIV with a CSS style set to 'display:none', which essentially makes the field invisible. Normal CSS-capable web browsers will not display the field, so the user will never get a chance to enter input data into it. But the spam applications do not account for the hidden DIV, and thus will treat it like any other field on the form (and input a value). Thus all you need to do is see if that invisible form field contains a value upon submission, and if so, discard the submission. For safety, put a nice warning (also in the DIV) to users that they should not fill out the field if they see it; that way, if for some reason a user has a browser which is not CSS-compliant, they are still prompted to leave the field blank.

Textarea input field in HTML comments
I noticed one of the spam apps that hit my form just couldn't resist the temptation of populating data into a textarea input field that was within HTML comments. Normal browsers will ignore everything in comments, including the erroneous textarea field; so any submissions that include that field should be discarded as spam.

Don't use obvious form field names
Avoid using the field name 'email' for a user's email address, etc. In fact, you can turn this to your advantage: have the email field be named 'foo' or something else innocuous, and then check upon submission that the 'foo' field data format matches the format of an email address (which is typically done for validation purposes anyways). Since the spam apps often shove random garbage into fields they do not understand, you can discard any submission that does not contain what looks like an email address in the 'foo' field. Alternatives include checking numeric format in postal code or phone number fields, etc.

Overall, these few simple tricks can help you alleviate the flood of web comment spam that your site might be experiencing. They may not be perfect, but they are simpler to implement than a CAPTCHA and do provide some value from the current crop of web comment spam apps that are roaming the Internet. Every little bit helps.

Until next time,

- Jeff