Website malware on the attack

sharkattackI was reading an article about how a group of researchers found some new malware and I was floored.



We’ve been removing this from websites for months. The first instance we found of this was on February 5, 2014. I guess I really need to write more blogs.

Yes, we’ve been finding the .sd0 and files on many compromised websites. What the article doesn’t share is an explanation about the .php file that enables these files to be executed.

Typically you’ll have a few “extra” processes running named “host”. These will run the resource utilization up and must be killed after finding and removing the .sd0 and other .so files in the web folders. Be careful not to just do a:

find . -name “*.so” -exec rm -f {} \;

As sometimes we see ioncube files with .so extensions in the web folders as well.

The .php file contains code for both 32-bit and 64-bit architectures.

It opens /usr/bin/host for reading/binary and contains strings for the .so bytecodes. One other file that gets created is

The php file then creates a cron job and a file. The cron job runs constantly.

All of these must be deleted and the host process must be killed.

These files have been uploaded a variety of ways, but typically we see them in non-updated CMS’s.

Moral to this story,


Thank you for reading…

Edited on Monday July 28, 2014:

Just as I had suspected. The hackers are no longer using just the .sd0. They are using basically the same format, but the filename can be anything starting with period (.) and any random filename.

On servers where you have SSH access, you can go to the public_html folder on your server and try:

find . -type f -executable -exec file -i ‘{}’ \; | grep ‘x-executable; charset=binary’

The key to this whole infection is the server load with skyrocket as the hackers are running their own “host” process which must be killed.

From a command line we used:

kill -KILL pid

You have to get the pid and enter it instead of the pid above. Normall you can get the pid from the top command.

Thank you.


wysija-newsletters WordPress infection

infected wordpress websiteThis weekend (yes we work weekends) we saw an outbreak of VPS and dedicated servers infected by what appears to be a vulnerability in the wysija-newsletters (MailPoet) WordPress plugin.

This plugin was identified as vulnerable over 2 weeks ago and the authors have released a new version. If you’re reading this, then please, please, please, update your plugins immediately and set a reminder in your smartphone, your computer or anywhere and every where else, to check your WordPress and your plugins for updates every 3 days at a minimum.

Hosting accounts, whether the are VPS’s, dedicated servers for on a shared hosting account were hit.

Basically almost every .php file on an account was injected with code across the top of each file. In addition two files were uploaded as well. Usually we saw one license.php file and then another backdoor shell either in the wp-admin or wp-includes folders. Most of the license.php files we found were 201 bytes in size.

One other point of entry left by the hackers is an administrator user with no name. This user must be deleted and all plugins updated.

You’ll notice that all the original date/time stamps of the files are kept. This leads us to believe that the backdoor shell they’ve uploaded allows them to modify almost anything about a file.

The vulnerability allows hackers to bypass admin authentication in wysija-newsletters plugin and upload files. The hackers access those files remotely and start injecting their malicious payload into every .php file their program can find. This means that it will cross sub-domains on the same account.

The attacker will upload a file to: wp-content/uploads/wysija/themes and run it. Fortunately, our protection does not allow php files to be executed in the uploads folder – so even before this was discovered, many of our customers were already protected.

If you have a VPS or dedicated server with only one cPanel and all your sites under that, then basically every website is probably infected on your server. If you’re on a shared hosting account with multiple websites and one of them has the wysija-newsletters plugin (MailPoet), then chances are that all of your websites are infected.

We’ve been working feverishly to get this cleaned up, but some of the infections overwrite the existing file and they’re not always very good. Frequently we’ve have to replace plugins and/or themes because there is code missing from the file after the infection.


Email scam alert

I would like to alert you to a scam. It’s not new, but I wanted to let you know so you don’t fall for this.

It started as an email that looks like this:

A scam that was caught in our in-box

A scam that was caught in our in-box

In the section: “To view copy of the court notice click here” when you click on the link “here” you are taken to:

This link no longer works, but it was trying to infect the computer of the person who clicked on the above link. You must be wary of all emails sent to you that it designed to scare you into some action.

Typically if you hover over the link, depending on your browser, you can see the URL of the intended link. If it has nothing to do with the email, then it’s probably a scam and it should be deleted.

Quite often we’ll see emails where you must click on a link or open an attachment in order to “play along”. This should be your first tip-off.

For this scam, if there is someone taking legal action against you, they will contact you either through mail (snail mail), Fed-X, UPS or some other physical means – not email.

Hopefully you wouldn’t have fallen for this, but I did want to alert you.

Thank you.


The proof is in the logs

Website security made easier by reading log filesEver since I started this business of website security back in 2007 I’ve been reading log files.

Select my favorite easy chair, grab a tablet, a glass of scotch and dive into reading log files. Sound like a fun time?

Most of you will cringe at that. However, I’ve found that with few exceptions, the proof is in the log files. Unfortunately, many hosting providers have the log files off by default. When a new customer comes to us to remove the malware from their website, they always want to know how it happened.

Seems logical doesn’t it?

However, without log files all we have is comparing similar situations. We actually know of one competitor that deletes the log files after we told them what 3rd party services they were using based on the information in the log files.

You see, the log files don’t lie. They may not contain all the information, but they don’t lie.

For instance, often times we remove malware from a WordPress website. That’s not to imply that WordPress is more vulnerable than other CMS’s (Content Management Systems). But they are the most popular which by itself, makes them a huge target.

While removing malware from a WordPress website we look for clues. If the log files have been activated, we run them through our analyzer (automated and written in-house) which either pinpoints the exact point of entry or at least gives us enough evidence to make a highly educated guess.

Too often, we determine the point of entry to be stolen WordPress passwords. This is due to a virus/trojan on someone’s local computer that is waiting for them to login to their WordPress website. It then records the login URL, username and password.

Quite often we’ll see a sequence like this:

POST /wp-login.php HTTP/1.0″ 302

Followed by and entry like this:

GET /wp-admin/theme-editor.php?file=footer.php&theme=

You can only get to the theme-editor if you’re logged in with the proper rights. When we see this in a log file, we know that some WordPress user with administrator rights has logged in and used the theme-editor to modify the footer.php file.

We open the footer.php file and 99.9999% of the time, we find infectious code. The theme-editor can also be used to inject code in any of the of the other files as well. While they’re logged in they might also upload a “media” (not really) file, which is nothing more than a backdoor shell.

You can find so much information in the log files that we get really excited when we have log files to analyze because we know it will lead us to the final reckoning. We find the evidence and we state, “I reckon that’s how the hackers got in!”

If your security company deletes log files or just doesn’t ever activate them, you have to wonder, “Do they really know how my site was infected? Or are they just telling me to install 3 or 4 security plugins and they’re hoping for the best?”

That my friends is something for you to consider.

If you have log files you’d like us to analyze for you, put them in a zip file and email them to me at: I’ll run them through our analyzer and give you our opinion of how your site was infected – no charge.

Thank you.