Website Ransomware – CTB-Locker Goes Blockchain


During the last couple of years, website ransomware has become one of the most actively developing types of malware. After infamous fake anti-viruses, this it the second most prominent wave of malware that makes money by directly selling “malware removal” services to users of infected computers. But unlike fake anti-viruses, that were mostly harmless, and used as a social engineering technique to make people pay for removal of non-existing threats, ransomware is a much more serious beast. It doesn’t pretend to be a good guy. It actually makes your computer unusable unless you pay the ransom.

So what happened? Why don’t we see large scale fake anti-virus campaigns any more while ransomware is all the rage? I guess the answer is the payment method.

Read More

Website Malware – Evolution of Pseudo Darkleech


Last March we described a WordPress attack that was responsible for hidden iframe injections that resembled Darkleech injections: declarations of styles with random names and coordinates, iframes with No-IP host names, and random dimensions where the random parts changed on every page load.

Back then, we identified that it was not a server-level infection. The malicious PHP code was injected into the wp-includes/nav-menu.php file. It fetched the actual iframe code on the fly from a remote server.

Since then, we’ve been regularly cleaning sites infected with this malware. While the PHP code in the wp-includes/nav-menu.php file didn’t change much, the site visitor facing part of this attack has changed significantly.

First of all, the attack became stealthier. It won’t reveal itself if a request comes from any of the networks (including whole countries) that the attackers are not interested in.

Read More

vBulletin Exploits in the Wild


**Update: CheckPoint disclosed more details here: Check Point Discovers Critical vBulletin 0-Day.

The vBulletin team patched a serious object injection vulnerability yesterday, that can lead to full command execution on any site running on an out-of-date vBulletin version. The patch supports the latest versions, from 5.1.4 to 5.1.9.

The vulnerability is serious and easy to exploit; it was used to hack and deface the main website. As a precaution, all passwords were reset; you will have to create a new one before you can access again and download the patches.

Exploits in the Wild

This vulnerability seems to have been around for a bit. We were able to trace exploit attempts to the end of October, they were targeting a few high profile vBulletin sites protected by our Website Firewall.

The exploit was shared publicly yesterday. It attacks the decodeArguments Ajax API hook. Here is an example of an exploit attempt in the wild:

108.47.xx.yy – – [02/Nov/2015:22:18:21 -0500] “GET /vbforum[/]ajax/api/hook/decodeArguments?

Once decoded, it executes:


This shows the attacker the result of phpinfo indicating that his exploit succeeded. If this test payload works, the attacker will proceed with a full compromise. We are not seeing widespread exploitation attempts yet, as just a few high profile sites were targeted, but we expect it to change soon as it makes its way into the automation engines.

Patch and Protect

If we have not emphasized before, you have to patch your vBulletin site now! Websites behind our WAF are (and always were) protected against this vulnerability due to our virtual hardening technology. If you can not patch your vBulletin site, we recommend looking at a solution to stop these exploits before they reach you.

WordPress Malware – VisitorTracker Campaign Update

For the last 3 weeks we have been tracking a malware campaign that has been compromising thousands of WordPress sites with the VisitorTracker malware code.

We initially posted some details about this issue on this blog post: WordPress Malware – Active VisitorTracker Campaign, but as the campaign and the malicious code has evolved, we decided provide an update to what is going on.

To give an idea of the size of this campaign, we tracked the number of compromised sites we have detected over the last 3 weeks:


As you can see from the above graph, it started relatively small, peaked about 10 days ago, slowed down again and gained a lot of traction over the last 3 days.

Read More

.htaccess Tricks in Global.asa Files


As you might know a lot of hacks use Apache configuration .htaccess files to override default web site behavior: add conditional redirects, create virtual paths (e.g mod_rewrite), auto-append code to PHP scripts, etc.

In the world of IIS/ASP there is also an equivalent — Global.asa files. This file contains common declarations for all ASP scripts and should be placed in an ASP application root directory. If this file exists, ASP sessions include this file automatically.

Read More

Website Malware – The SWF iFrame Injector Evolves

Last year, we released a post about a malware injector found in an Adobe Flash (.swf) file. In that post, we showed how a SWF file is used to inject an invisible, malicious iFrame.

It appears that the author of that Flash malware continued with this method of infection. Now we are seeing more varieties infecting both WordPress and Joomla websites. Though it’s uncertain how many iterations existed in the wild when we first reported the issue, this time we’ve found a lot of websites where the infection looks similar:
Identifying the Flash Infection

The similarities are easy to spot once you know what they are. The malicious .SWF file is always stored in /images/banners/ and the file name is three random characters followed by .SWF with an ID parameter appended:
Read More

WordPress Malware Causes Psuedo-Darkleech Infection

Source: The National Archives (UK)

Source: The National Archives (UK)

Darkleech is a nasty malware infection that infects web servers at the root level. It use malicious Apache modules to insert hidden iframes with certain responses. It’s difficult to detect because the malware is only active when both the server and site admins are not logged in and the iframe is only injected once a day (or once a week in some versions) per IP address. This means that the infection symptoms are difficult to reproduce. Since it’s a server-level infection even the most thorough remote scans won’t reveal anything. Even when the culprit is identified, website owners may not be able to resolve the issue without help of a server administrator.

Despite the detection difficulties, it was quite easy to tell that the server was infected with Darkleech when we saw the malicious code — it has followed the same recognizable pattern since 2012:
Read More

Inverted WordPress Trojan

A trojan (or trojan horse) is software that does (or pretends to be doing) something useful but also contains a secret malicious payload that inconspicuously does something bad. In WordPress, typical trojans are plugins and themes (usually pirated) which may have backdoors, send out spam, or inject hidden links and malware. The trojan model is easy to understand: package malware inside something useful and have webmasters install it themselves.

This week I came across something that I can call an inverted trojan — malware (installed without webmaster consent) that added useful features to WordPress.

Read More

Why A Free Obfuscator Is Not Always Free.

We all love our code but some of us love it so much that we don’t want anyone else to read or understand it. When you think about it, that’s understandable – hours and hours of hard dev work, days of testing and weeks (months?, years?) of fixing bugs and after all of this, someone steals, changes or modifies your hard work.

To address these concerns, many developers will obfuscate their code.

Read More

Analyzing Malicious Redirects in the IP.Board CMS

Although the majority of our posts describe WordPress and Joomla attacks (no wonder, given their market-share), there are still attacks that target smaller CMS’s and we help clean all kinds of sites. This post will be about conditional redirects in IP.Board forums (currently #27 with 0.3% of the CMS market).

Conditional Redirects

The symptoms of the problem were typical. Some (not all) visitors who clicked on Google search results were redirected to a malicious site filestore321 .com/download .php?id=hexnumber. The redirect worked only once per visitor and subsequent attempts to trigger it would fail.

Read More