Website security and the 5 million hacked Google accounts

Google-DocsYou’ve undoubtedly heard of this by now. But please read this as you’ll see how this could affect you. I’ll tie this in with the other report of hackers stealing over 1.2 billion login credentials recently and how it relates to website security.

Hackers have reportedly posted a list of approximately 5 million compromised Google accounts on a forum. If you’d like to check to see if your account is one of them you can go here:

If you have a Google account, you should change your password immediately and while you’re at it, change your Google password. If you’re logged into your Gmail account, look in the upper right-hand corner for this icon:website security affected by hacked Google accounts

Hover your cursor over it and select “Settings”. Then select “Accounts and Import”. The first category is “Change password”. Click that, enter your current password (the one the hackers may already have) and then type a new password in twice.

With all the recent hacking news, you should be knowledgeable enough now to know not to re-use passwords. When you’re changing your Google password, please create something entirely new. Make it different from all your other passwords.

Why all of your passwords should be unique

Hackers will use your email address and your password on thousands of different sites to see if any of them work.

In recent news, this could have been the strategy behind various accounts being “hacked” at Here is some information on that:

If hackers crack into a website that contains usernames (email addresses usually) and passwords, they will try those same login credentials on a multitude of websites knowing that many people use the same password on most of their logins.

While you’re updating your Google password, switch on 2 factor authentication. It’s a great way to protect your online presence.

What does this have to do with website security?


You have login credentials for your hosting account, your hosting account email addresses, your database, your WordPress, Joomla or other website software. Do you use the same password across those accounts? If so, be prepared for some work. You’re going to change all of them – now. Not when you have time this weekend – NOW!

Ever wonder how hackers “break” into websites? Often times, they don’t have to. They just login. There’s no hacking there. You can have the most expensive firewall in the world. If hackers have your username and password, there is no website security in the world that will prevent them from infecting your website.

How did the hackers get these login credentials?

We believe that they may have obtained many of them from phishing scams. Over the past 60 days, we’ve removed 7,218 Googledocs phishing setups on websites.

The scam usually begins with a fake email from someone who wants to “share” a document with you. It could be a business offer, secret photo’s or anything else that might make you curious enough to open it. The original email could even appear to be from someone you know.

Hackers frequently infect people’s computers with viruses. These viruses steal the victim’s email address books which are then used to send email to all the people in the address and it appears to be from the original person.

Let’s say one day you get an email from a friend. Maybe someone you correspond with frequently. The email states they want to share a personal document with you. Sounds legitimate doesn’t it?

You open it, enter your Google docs username and password, as your curiosity gets the best of you, only to discover there’s nothing there! Would you find that odd?

Maybe. Maybe not.

Well my friend, your Google login credentials have just been stolen in a phishing scam.

It all comes back to website security

You must be certain your website is not used in any phishing scam. These phishing files are often buried deep in the folder structure of a website. We’ve seen them 11 sub-folders deep and they can be anywhere on a website.

Next, you have to be wary of all emails. Yes, even those sent by what appears to be someone you know. We will be posting a new article about how to increase your spam filtering in cPanel accounts. We’ve tested it and it works well.

Some of our clients running VPS’s for their client’s websites, have expressed concerns over the amount of incoming spam. We conducted some in-depth research, created a strategy, implemented it for a few clients, tested and tweaked it and we now make it as part of our standard services. Contact us if you need help in filtering out more incoming spam.

Normally, you could hover your cursor over the link in an email and you could probably tell with some degree of certainty, whether or not a link was phishing or not. However, with some of the Googledocs phishing, the fake login page is frequently hosted on Google’s servers and uses SSL.

What the hackers have done is created a folder inside of a Google drive account. Then it’s configured to be public and then use the Preview feature to get a URL that publicly accessible. That URL is then pasted into their emails and blasted out to millions.

Need for more website security

In this scenario, the hackers will typically use an infected VPS or dedicated server to send out the spam messages. During the past 60 days, we have removed over 100 million spam messages from email queues. These were messages that were ready to be sent, but hadn’t been delivered yet. Many of these were being used in the Googledocs scam.

Keeping a close watch on your email queue is something that vitally important and something our VPS and dedicated software does.

Enough about us, all of this really needs to be addressed in your overall website strategy. Reputation means everything online and one careless step with your website security could drop you in the search engine rankings, get your VPS or dedicated server blacklisted with the spam blacklists, or you could get listed on a website for hosting phishing files.

None of which will be good for your website’s reputation.

Do you have a website security strategy in place?

If not, let’s talk. The discussion costs you nothing. Give us a call or send us an email. We’ll be glad to discuss what a good website security plan should include. You’ll be glad you did.

Thank you for reading this far.


revslider plugin vulnerability

website hackedBack in July the revslider WordPress plugin was discovered to have a vulnerability that allowed arbitrary files to be downloaded. This was specifically for version 4.1.4.

This vulnerability has been actively used to infect WordPress websites.

Normally, being able to download a file to your local computer isn’t a huge news flash. However, when you consider this allows people to download your wp-config.php, which contains all the login information for your database, it can be used in a variety of ways by cybercriminals.

I bring this up because we’ve been seeing a number of websites infected this way.

When the hackers download the wp-config.php file, they strip out the database login credentials and then try to login to the database remotely. If successful, they either add another user with administrative rights or change the password to one of the existing users with administrative rights.

Next, they login and either upload a malicious backdoor or use the theme-editor to inject malicious code in the theme files.

I would like to mention that some hosting providers, Bluehost, Hostmonster, JustHost and many others, don’t allow remote access to phpMyAdmin in the cPanel by default. You have to whitelist an IP address to enable remote access to phpMyAdmin.

That basically kills this specific attack in their environments. However, that’s only this specific attack. Other files could be downloaded that would provide the attackers enough information to be able to infect the website.

Also, some website owners use the same username and password as their cPanel. This could be disastrous. Never use the same password as your cPanel. Never.

As always, keep all your plugins and WordPress updated.


Thank you for reading. If you have this plugin contact me for a way to test your site (no charge).

Send me an email:


Research predicts websites likely to be infected with malware

Research into website malwareResearch conducted by Kyle Soska and Nicolas Christin of Carnegie Mellon University proves that with some degree of accuracy, they can predict which websites will be successfully infected with malware.

“Our approach relies on an online classification algorithm that can automatically detect whether a server is likely to become malicious,” the researchers stated.

Their research uses an algorithm that analyzed websites before they were infected and after they were infected.

“we use machine-learning tools to attempt to detect websites that have not been compromised yet, but
that are likely to become malicious in the future, over a reasonably long horizon (approximately one year)” they stated in their research paper.

Whether or not their predictions come true, it could be used to alert website owners before their website becomes infected with malware.

Many website owners are more reactive – they often don’t consider website security until after they’ve been infected. However, with this research, they could be warned ahead of time and take corrective action before their website and their business becomes victimized by website malware.

“Our goal is to build a classifier which can predict with high certainty if a given website will become malicious in the future.”

“At a high level, the classifier determines if a given website shares a set of features with websites known to have been malicious. A key aspect of our approach is that the feature list used to make this determination is automatically extracted from a training set of malicious and benign webpages, and is updated over time, as threats evolve.”

Could this actually help?

Only time will tell, but it does present some interesting ideas.


The latest round of WordPress infections

WordPress plugin custom-contact-forms used to infect websites
This past week has seen another influx of infected WordPress sites. This time, it’s another plugin: custom-contact-forms.

Their website shows a total of 630,792 downloads as of this blog post, so it appears to be quite popular.

It was last updated on August 4, 2014, however, again, it does not seem like many people are keeping their WordPress AND plugins updated.

What we’re seeing is in the wp-content/plugins/custom-contact-forms/import folder, typically 2 files that have a series of numbers and end with .sql.php. The files we’ve seen usually have some bogus looking Joomla code in them. Yes, you read that correctly, Joomla looking code.

There have other files as well, but these appear to be the hackers first uploads to a vulnerable website.

From there the hackers have uploaded phishing files, other backdoors, emailers and other malicious code.

Many of the most recent infections we’ve found are on either VPS’s or dedicated servers. If they have all the websites on one cPanel, then the hackers can and do, infect many of the other websites as well.

A scenario we see frequently is where there are let’s say 10 websites on a single cPanel. The hackers will find a way in on website number 3. They don’t leave their code there, because they don’t want to attract your attention to that site. They’ll infect say, websites 5, 6, 7 and 8.

That way you focus your malware removal efforts on that site and they keep coming in on website number 3. They may also put backdoor shells on websites 1 and 2. These backdoor shells allow them to have remote access to your files after you remove their original point of entry on website number 3.

For this reason, we recommend that each website be on it’s own cPanel. Yes, it’s a hassle, but so is having all of your websites down while the one is the original point of entry.

This entire sequence of events can be prevented if you’re very diligent about keeping your WordPress and it’s plugins updated – daily.

Thank you for reading. If you have any questions, please do not hesitate to ask here. Also, if you want to share this, please do.


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.


Has security moved from prevention to detection and response?

Recently, Symantec’s senior vice president of information security Brian Dye declared that anti-virus is dead, as told to the Wall Street Journal.

Is it?

Has the security industry moved away from prevention to early detection and quick response?

I know when I started WeWatchYourWebsite back in 2007, I started preaching prevention. However, it became evident that nobody was interested. It appeared that people, even then, were more interested in early detection and quick remediation.

If you look at many of the startups and large security companies, it becomes real clear that most of the industry is focused on early detection and quick remediation. Is this like closing the barn door after the horses are out?

Is this giving up on prevention and focusing instead on early detection? That, to me, is like admitting defeat to the cyber criminals of the world.

Or, is it a different strategy?

In combat, whether your battlefield is on soil or a chess board, one key strategy is to lure your opponent into an area and then close in and destroy them.

Could this work in cyber security?

Of course, we’ll never catch the cyber criminals, unless they’re really lazy, but can we capture their methods? That would be considered a victory.

battleIn the book, “The Art of War” it states:

All warfare is based on deception. Hence, when able to attack, we must seem unable; when using our forces, we must seem inactive; when we are near, we must make the enemy believe we are far away; when far away, we must make him believe we are near.

If our deception is to lure the cyber criminal into our website, but record and report everything, then we can consider that a victory for the masses. That information can be used to protect other websites and prevent other sites from being successfully breached.

What do you think?

Should focus be placed on detection and response? Is that a sound strategy?

Share your thoughts…

Thank you.


Real live password hacking


Bad passwords

We recently worked on an infected website that was a bit unusual.

Often times we see websites hacked due to stolen passwords. Some times we remove malware from websites that were infected due to easily guessable passwords. Passwords like:

  • p@ssw0rD
  • pa$$woRd
  • pA55W0Rd
  • etc…

These are all passwords that the hackers try in their “brute force” attacks. In the event you’re not familiar with a brute force attack, it’s essentially the hackers trying thousands or millions of usernames with thousands or millions of passwords.

When the hackers know what the username is, it reduces their attempts, but a strong password always prevails.

In this unusual case, we found the infected code on a cPanel account. That’s not unusual. Not that cPanel is easy to hack – it’s not, but often times the username for a cPanel account is easy to ascertain.

For instance, if you’re main domain for your cPanel account is and there is no other domain similar to that, you might have a cPanel username of rumplest – or some variation of that.

Knowing that, you can start putting together a list of potential passwords:

  • rump1e$t
  • rumpl3st
  • rump1e5t
  • rumpl3$t
  • rumpl35t
  • rump1es+
  • rump1es7
  • rumpl3s7
  • etc…

Basic premise here is to replace each l (“L”) with either the number 1, or an upper-case I, or the vertical bar (|). The number 3 can represent an e, an s can be replaced with either the $ or a number 5. The letter “t” can be replaced with either the plus sign “+” or the number 7. The letter “a” can be replaced with the “@” sign, etc…


We’ve seen programs the hackers have that will take a word or phrase and by applying some basic password rules to it, will generate a long list of potential passwords. In this specific case, their program generated 72 different potential passwords.

The infected files we found were in a folder above public_html. So we almost rule out an application type infection. It did not appear to come from an outdated version of WordPress. However, we scanned the log files, which luckily for us, were already activated, and they turned up nothing.

We have files above public_html, no forensic trace in the log files – how could this be?

It seems the customer was using a password that was just an obfuscated version of the cPanel username.

Our conclusion on this one was that since this site had the tools the hackers were using to try and infect other cPanel accounts, we presumed, due to lack of any other evidence, that this one, with it’s password falling into the parameters of the tools hackers use, was infected the same way. Accompany that with where the files were and that the log files looked like they had been tampered with, lead us to believe our conclusion was correct.

Moral to this story is never use easy guessable passwords – never. Don’t think you can get away with just obfuscating the username into a password. Obviously that doesn’t work either.

If you have an infected website and would like to see if we can figure out how it happened, send me an email: We’ll have questions for you, but we should be able to give you an idea of how it happened.

Go ahead, give a try…

Thank you.