By

Hackers now "touch" all files

This is going to be a short post.

While working on cleaning a number of websites this past week, I’ve noticed something very different.

One of the steps we take when cleaning a website is to record the last modified date of a file with malscripts injected. This helps us identify other possible infected files. In fact our automated tools were (“were” being the key word) doing the same thing. When an infected file was found, our tool would record the date and time of the file and search all the other files with the same last modified time and scan those files first.

It’s amazing how predictable and how patterned this strategy worked.

That is until this past week.

Then we started seeing a process where the hackers (or cybercriminals, if you will) will “touch” every file.
(Note: In a Linux environment, there is a “touch” command that will create a file if it’s not already there or at least change the date and time of a file if it does exist. I’m certain there’s a way to do this in a Windows environment as well.)

This does make it more difficult to see what other files may have been affected (or infected) by the hacker’s automated program. Often times we look for the obvious pattern when trying to identify injected malscripts. We’ll just have to stick to our original strategy of checking for any changes made to files.

It’s amazing how effective monitoring change works. Once you have a known, clean copy of a website then monitor for any changes, you see everything. Soon we’ll be relaunching our service that includes full-scale, site wide change monitoring. Any changes detected will be further analyzed for potentially malicious behaviour. Any potentially malicious changes will be recorded and the website contact’s notified.

This is one sure way of knowing exactly where the malscript was injected and when. Then it’s an easy step to remove it or block it.

We’re also working on a new method of preventing websites from being hacked in the first place.
As always, check our main website for when we announce our relaunching.

Check out our new site: http://www.wewatchyourwebsite.com and let me know what you think.

Any comments?

By

The "onload if this" website infection

Of course the title of this post is only part of the infection.

The typical type of infection I’m going to discuss first looks more like this:

The domain this iframe directs to and the long string of characters (kzjev…) before the closing iframe tag can be different, but from what I’ve seen, the rest is typically the same.

Other domains we’ve seen include, but are not limited to:

the-another-life
theeasyriver
iquotient
testodrome
whendeath
intelekt-testing
ig-testing
zria
worldrat
qualitysuper
deth-test
iq-mozgi
dedlife
mozg-testing
testossteron

Using PowerGrep, we’ve been able to remove this infection quite quickly, however, just removing it doesn’t mean your website is safe – not by a long shot.

Upon further analysis, we found that these infections were remotely controlled, locally injected. 

What I mean is that the control of the infection is handled remotely, however, the infection process itself is local to the files on the website.

First of all, in some of the sites that had these infections, we found the old gifimg.php file in the images folders. Some sites have various plugins and some of the plugins have their own images folder. The gifimg.php was in there as well so look through all folders for the gifimg.php file. As you may know from our previous post, this file allows the hackers to send commands to your website from where ever they are – this is remotely controlled part.

Keep in mind that not all of the websites where we found the “onload if this” infection had the gifimg.php file. Just because you don’t find that file doesn’t mean you don’t have the “onload if this” infection.

Before we get too focused on the “onload if this” type of infections, let me state that other infections were injected the exact same way.

This infection was found using the same method as the “onload if this” infection:
sunsetfibersinfection

Here again, we’ve seen various other URLs such as:

albaser.com
unilanguage.net
akrjewellers.com

just to list a few.

The infectious code that generates this infection is:

Which deobfuscates to:

The base64_decode in the above script deobfuscates to:

Which, as you can see, is one of the domains listed above. The original PHP script injects this malscript into various pages it finds throughout the site.

You can search for and delete this script (inside the script tags) all you want. If it comes back over and over again, then you might have the original php code, or something similar in one your files.  It’s these repeat infections that are the worst because you could waste hours of time scanning through your files, looking at the code, removing everything you believe is malicious and then it comes right back again – over and over.

Typically for a repeat infection our advice would have been to scan your PC for viruses and trojans with a different anti-virus program than what you’ve been using. However, in this case, that might eliminate the original infection, but the repeat infections are the result of this php code.

Unfortunately, the only way you can detect this is to find it in the code on your website. We requested full FTP access from the clients who had this infection so we could look at all the files. No remote (meaning a scanner that scans from outside your website) can find this. The PHP code dynamically generates the webpage so you’ll never see the malicious remote control code in the source code of your browser.

How did these sites get infected originally?

By the same method used to infect thousands if not millions of sites – via stolen FTP login credentials. FTP login credentials are saved on a local computer and stealing them gives hackers a valid method for accessing the files on a website – valid login credentials.

I’m working up a full write-up on steps to take to prevent compromised FTP login credentials, but it’s not ready just yet.

If your website is getting hacked over and over again, you should scan all your website files for any occurrence of this string:

eval(base64_decode

Don’t just delete any file with that string in it because we have seen various files where that is used legitimately, however, close examination of any file with that string is suggested.

If you need assistance in locating this code or deobfuscating code let me know and I’ll try to help you.

If you have any other domains or URLs to add to our lists above, please send them to me at traef@wewatchyourwebsite.com or post them as a comment here.