I had been preparing this write-up for over a week now, but I see that SiteLock beat me to the punch in their blog.

As some of you know, we specialize in root cause analysis. I’ve built an incredible engine to analyze how websites were infected. Some of it is correlation analysis – matching the infection patterns and traffic to previously serviced websites.

Other times, it’s just plain old forensic analysis.

Initial Detection of /wp-base-seo/wp-seo-main.php

Originally it was our anomaly detection that identified the malicious code in the bogus plugin (/wp-base-seo/wp-seo-main.php). Then our behavior analysis confirmed it (if it walks like a duck and talks like a duck…). In order to speed-up our detection, we designed and implemented some signatures to positively identify this in the most efficient manner.

As much as I would have liked to be the first to reveal that bogus plugin, I was not – and kudos to SiteLock.

However, the one thing they lack in their report is root cause analysis.

My post here is to reveal how this bogus plugin was installed on the 31 sites we found with it.

One of the main problems with root cause analysis is that if you have log files, which most Hostgator accounts do not have activated (until we work on them), the majority of the log entries are benign – they are just recordings of normal traffic to that website.

Our machine learning system has this covered quite well. Since we’ve been analyzing log files since our inception in 2006, we had a lot of log files to feed into our machine learning system. This analysis of normal traffic and “not-so” normal traffic has created some very insightful information.

Last, you have to correlate the log entries to the infectious files and their timing. This helps in determining what the possible original point of entry was. This isn’t always easy as hackers will often change the date/time stamp of files to match other files in the same folder in an effort to conceal their work.

Oh, and since most websites appear to be on shared hosting accounts, you have to find the specific site that was first used in the successful attack.

Luckily, we have that system.

Cut the B.S. what’s the root cause?

In all 31 websites that we serviced with this bogus plugin, we found this wp-base-seo was installed as a plugin through the administrator level user.

Each case proved that the administrator was not “brute-forced”, meaning the hackers guessed the administrator level user password with multiple login attempts with different passwords, but the login credentials were actually stolen with a password stealing trojan on the person’s local computer.

How can we possibly know this?

When the log files go back far enough, we see there aren’t any multiple login attempts.

It was just a one-time successful login. No previous repeated attempts. You see, if it was a “brute-force” attack, there would be multiple login attempts as the hacker’s are trying different username and password combinations. We see these typically coming from various IP addresses, but the timing and frequency indicates to us that these are all part of the same attack.

Also, if the breach was due to a brute-force attack, since each of these customers had changed their administrator username, the hackers would have to know what the username was as well.

Typically in a log file we’ll see entries like this:

GET /?author=1 HTTP/1.1″ 301
GET /?author=2 HTTP/1.1″ 301
GET /?author=3 HTTP/1.1″ 301
GET /?author=4 HTTP/1.1″ 301
GET /?author=5 HTTP/1.1″ 301

This is the hacker probing for the username of the author – and we did not see this anywhere in the log files. The author is usually the administrator. Remember, if they want to brute-force a website, they need the username AND the password. The hackers have a long, long list of potential passwords, but they also need the username.

Possible scenarios

Could it be that the hackers did their probing for the username prior to the log files we were able to analyze?

Yes, that is a possibility.

Could the hackers have found the password prior to the log files we had access to?

Yes, that is also a possibility.

However, in our conversations with these customers, many of them make it a point to change their administrator user’s password frequently (a few of them were changing it every week).

With a different username than admin, frequent password changes and successful logins from an IP address associated with a website, we can begin to sense this account was compromised by stolen passwords.

The proof is again in the log files. We see a successful login, then successful plugin installation.

To verify this we look in the database and see that the plugin has entries in the database as well. We consider this confirmation that the plugin was installed with administrator level access.

Why go through all this?

Well we need to determine how this happened. You see, without knowing this was the result of stolen login credentials, you, as a website owner would be subjected to repeat infections. No firewall in the world will prevent your site from being infected if the hackers have the “keys to the kingdom” (admin level login credentials).

If the hackers did not have admin level access, then we can eliminate that as a possible point of entry. Then we know the original point of entry was either outdated WordPress, an outdated plugin or some other vulnerability. We know the hackers could have just uploaded the files in the /wp-content/plugins/wp-base-seo folder.

We needed to know definitively how these sites were infected.

There you have it. We’re not saying that all of the websites infected with this: /wp-base-seo/wp-seo-main.php bogus plugin were infected the same way. All we have is our analysis of the 31 websites we serviced that had this plugin.

It was reported that the websites may have had a vulnerable version of the Revolution Slider (revslider) plugin installed and that may have been the point of entry. However, in the 31 websites we analyzed, only 2 of them had the Revolution Slider plugin installed – but they were updated before the websites were infected.

Let me know if you have any questions about this information. You can email at traef@wewatchyourwebsite.com

Please share with your friends. Knowledge is potential power – when it’s shared!