SiteLock Incorrectly Labels Spam Content In Databases as Malware

When it comes to the many problems that we hear about with the web security company SiteLock one of the most prominent is that they falsely claim that websites contain malware and then web hosts they are partnered with shut off access to the websites based on those false claims, while suggesting to their customers that they hire SiteLock to clean it up. (It is important to note that while this significant problem, you shouldn’t ignore claims coming from either SiteLock or your web host that the website contains malware or is otherwise hacked.)

There are a lot of questions that issue raises.

One being why would web hosts shut off access to their customers websites based on the word of company known to make false claims? That one is answered in part by the fact that those same web hosts make a lot of money if their customers purchase SiteLock services and by the fact that the owners of SiteLock also run a major web hosting company.

Another question being, what causes the false claims? For that, part of the answer is the SiteLock’s scanner, while labeled as a malware scanner, also tries to detect issues other than malware. That causes problems in trying to resolve real issues because people are being told that they have an issue other than they really have. Another issue with that is that they don’t seem to very careful in their detection of those other issue, so in one situation where we consulted on it looks like a website was falsely claimed to contain malware due to the phrase “hacked by” appearing on a page (we recently ran across a similar issue with the Sucuri SiteCheck scanner). Then people at SiteLock and their web hosting partners either don’t understand the quality issues with the malware scanner’s data or don’t care, leading to owners of websites falsely being told their website contain malware and having them shutdown.

A recent tweet from SiteLock shows another example of this, as they have a pretty bad idea of what constitutes malware in the database:

Malware refers to one of two things when it comes to websites, malicious code in general or malicious code being served to those visiting a website. Spam content itself would not be considered malware.

More problematic with that, is that if you had someone submit a comment with spam content on a WordPress website it would be stored in the database, so if you start labeling any spam keywords in the database as malware you would cause any database with spam comments, even if they were in the trash, as having malware.

That seems like a possible explain of another problem we have been hearing about recently with SiteLock, which is them claiming that backups of website’s databases contain malware.

Why SiteLock’s Poor Cleanups Lead to Website Reinfections

If you follow our blog you will have seen us say before that we are often brought in to re-clean hacked websites after another has cleaned and then it hacked again. And as we have said before, while it isn’t always the fault of a company that did the a clean up that a website has gotten hacked again, what we have found is that in almost all the instance where we are brought in to re-clean websites the first company has cut corners. As one of three main components of a proper cleanup is trying to determine how the website was hacked and when we ask if the source of the hack was determine by the first company that answer is almost always that trying to determine that never even came up.

One of company that comes to mind as one that doesn’t do proper cleanups is SiteLock. As we seen for years they don’t upgrade the software on the website (which is large part of one of the other main components, getting the website secure as possible) and they don’t determine how the website was hacked.

So we were somewhat surprised to see a recent SiteLock had a post on their blog “Why Website Reinfections Happen”, which while written to get around the issue, is really a indictment of how SiteLock’s improper cleanups leaves websites vulnerable to being reinfected.

In the post they start out by explaining why websites get reinfected:

The short answer is that it’s most likely due to unresolved vulnerabilities. While it may seem like you’ve been singled out and targeted by some menacing hackers, most of the time that isn’t the case. The majority of website compromises are preceded by automated campaigns that locate websites vulnerable to a particular exploit the hacker wishes to employ.

That would dictate as part of the original cleanup you would want to resolve the vulnerability, so what does SiteLock claim are the causes of the vulnerabilities.

Up first is outdated software with vulnerabilities:

It is for this reason that we stress not only cleaning the website, but also patching all software and identifying and remediating all vulnerabilities present on the website.

While they stress this, their cleanup don’t actual involve updating the software and neither doing their ongoing security services. They do try to get to what they actual provide by saying this:

It is also advisable to take a more proactive approach in the future by utilizing a web application firewall (WAF) to protect your website.

The problem with this is using a WAF isn’t more proactive, instead it is reactive, as the WAF often would need to have code or a rule written to protect against a vulnerability, so unless the WAF maker is aware of a vulnerability before it is fixed that will happen after the software is able to be upgraded. There is another problem with this that trying to protect in this manner is more likely to not work properly, as can be seen with what happened recently to another security Trend Micro, decided not to keep their one of their WordPress installations up to date.

Also, worth pointing at this point is a post from yesterday where we look at the fact that one of SiteLock’s major web hosting partners (which also happens to be run by SiteLock’s owners) is offering installing outdated and insecure software on their customers websites.

Next up is unfixed vulnerabilities, which are usually newly discovered (unless a software developer doesn’t fix vulnerabilities promptly when they are notified of them):

On the less common end of the spectrum we see compromises due to undocumented vulnerabilities, where the bad guys were the first to the punch with discovering that a vulnerability exists.

To know if there is an unfixed vulnerability that was exploited you would need to know how the website was hacked, which isn’t what SiteLock does. Instead they get back to the WAF:

In this instance, your best defense is taking a proactive approach by implementing and training a web application firewall (WAF) to block future attacks.

There is no explanation of how you are supposed to be able to train the WAF to block future attacks, when you haven’t determined how the attack happened. Going back to previous issue, it also would be more effective to get vulnerability fixed in the software than trying to block attacks, because sometimes even a minor change can evade a block, whereas properly fixing the vulnerability at its root should stop any attack. Doing this would also would likely leave others using the same software vulnerable unless they used a WAF that provided protection against the vulnerability.

Also worth noting here, is that while SiteLock promotes the WAF that is included in some of their services as being their own it is fact Incapsula’s WAF.

A Nexus of Insecurity Between EIG, SiteLock, and MOJO Marketplace

Last year as we started hearing and seeing more and more complaints about the web security SiteLock one thing we wondered was why would web hosting companies continue to partner with a company that was harming their reputation. The answer is in part that they get a lot of money from SiteLock, the Endurance International Group (EIG) has disclosed to investors that they get 55 of the revenue from SiteLock services through their partnership. When you are talking about $300 for a hack cleanup or $100 a month for a protection service, their cut of that could easily be more than they are getting paid by the customer for the service they are actually providing (without the costs that come with actually providing something).

That wasn’t the only explanation for that particular partnership, as turns out that the majority owners of SiteLock are also the CEO and a board member of EIG. While EIG isn’t all the well known by that name, they provide web hosting under a number of well known brands including A Small Orange, Bluehost, FatCow, HostGator, iPage, IPOWER, JustHost and quite a few others.

Web hosts can play an important role in keeping websites secure. They have a responsibility to keep the things in their power secure and they can also do things that help their customers do their part. The type of partnership that SiteLock has with EIG could influence EIG to not take the steps they could to keep websites secure since they can potentially make so much money off websites they host getting hacked. While we would think that might impact them doing extra things to help their customers, it turns out that EIG is not doing something that is their responsibility.

We are currently working on a cleanup of a hacked website hosted with JustHost, where JustHost and SiteLock have pointed to an outdated Joomla installation as being a weakness. While looking around at things we found that JustHost is currently offering to install that version of Joomla, despite it having not been supported for over two years.

From the JustHost cPanel control panel clicking the One-Click Installs button took us to The company behind that website, MOJO Marketplace, is another EIG company, which among other things provides the ability to install various software on websites. Looking over that page we found that not only were they offering to install the version of Joomla, 2.5.28, that JustHost and SiteLock were pointing to as being a weakness, but they are offering plenty of other outdated and insecure software. Below we have highlighted some of those.

If we were not already well aware of what SiteLock is really about, we would asking why SiteLock would be partnered with a web hosting company putting their customer at risk like this. It is worth noting that as far as we are aware none of SiteLock’s protection services include updating software, despite that being an important measure (and them seeming to be aware of the risk of outdated software).


MOJO Marketplace is Installing Joomla 2.5.28

First up MOJO Marketplace is still offering Joomla 2.5.x despite that reaching end of life (EOL) on December 31st, 2014.

MOJO Marketplace is Installing  Joomla 3.6.4

The next release of 3.x, 3.6.5, was released on December 13 of last year and included security fixes.


MOJO Marketplace is Installing Drupal 6.33

Not only has Drupal 6 been EOL over year ago, but there were five security updates after 6.33: 6.34, 6.35, 6.36, 6.37 and 6.38.

MOJO Marketplace is Installing Drupal 7.43

The next release of Drupal 7, 7.44, was released 11 months ago. Not only did that include security fixes, but so did the subsequent 7.52.

MOJO Marketplace is Installing Drupal 8.1.0

The next release of Drupal 8, 8.1.1 was released a year ago. Subsequent to that there have three releases with security fixes: 8.1.3 8.1.7, and 8.3.1.


MOJO Marketplace is Installing Magento

That version is two years out of date, with being released in May, 2015. That version included security fixes, as did 7 subsequent versions:,,,,,, and


MOJO Marketplace is Installing PrestaShop

The PrestaShop version is more than a year out of date, was released last April, and a security fix was released in the subsequent


MOJO Marketplace is Installing Moodle 3.0.4

Moodle 3.0.x was replaced as the most recent major version of Moodle just about a year ago. Support for 3.0.x ended a week ago. Not surprisingly the version of 3.0.x being offered isn’t recent, with the next version 3.0.5, being released 11 months ago. That version included security fixes as well five subsequent releases: 3.0.6, 3.0.7, 3.0.8, 3.0.9, and 3.0.10.


MOJO Marketplace is Installing MediaWiki 12.3.6

MOJO Marketplace isn’t offering the latest major version of MediaWiki, but at least you could explain providing 1.23.x as it long term support release in they were keeping it up to date. But as with the other software they are not doing that. The next release of 1.23.x, 1.23.7, was released in November of 2014. That was a security release, as were 8 subsequent releases: 1.23.8, 1.23.9, 1.23.10, 1.23.11, 1.23.12, 1.23.14, 1.23.15, and 1.23.16. Version 1.23.x reaches EOL this month.

SiteLock Unintentionally Provides Reminder That They Don’t Keep WordPress Websites Secure

One of our long time concerns with the security industry is that that their efforts to sell more advanced security measures make it less likely that people will take more basic security measures. Right now even many security companies are not doing the basics when it comes to security and as a hacking of one of Trend Micro’s websites earlier this year showed, more advanced security measures are not necessarily even as effective as the basics.

Another example of this comes from a recent case study from the security company SiteLock where they highlight a website that is using a version of a WordPress plugin with known vulnerabilities while they falsely claim one of their services is insuring the website is “safe and secure at all times.”

The Unmentioned Business Relationship

Before we get the details of that it is worth noting that SiteLock isn’t being upfront about how they came to be involved with the website mentioned in the case study, which seems important when you consider they are leaving it insecure.

Here is their explanation:

One day Kasal unexpectedly received an email from his hosting provider alerting him that his blog had been infected with malware. Due to the stealthy nature of the attack, there were no obvious signs that his blog had been compromised. “I was unaware that my site had been hacked and at a total loss as to how to find or fix the problem,” he recounts.

Kasal’s hosting provider informed him that his blog would be taken offline unless he removed the malicious code that was inserted on his website. His host recommended he contact SiteLock® to remove the malware and help prevent future attacks.

What they don’t mention is who the web host is or why they recommended SiteLock. Looking at the DNS records the web host is IPOWER. That is one of the many brands names that the Endurance International Group (EIG) does business under. That is rather important in explaining the recommendation, as it turns out that SiteLock’s owners are the CEO and a board member of the company and the company has disclosed that they get 55 percent of revenue coming from the sales of SiteLock’s services through a partnership they have. If there were not those connections we doubt the web host would be recommending SiteLock, considering the many problems with SiteLock (one the reoccurring complaints is that they sell protection services that don’t actually protect websites).

SiteLock Doesn’t Detect Vulnerabilities

The case study doesn’t go in to details as to how the website was cleaned, but no mention was made of doing two important parts of cleanup, making the website secure as possible (which usually mainly involves getting the software up to date) and trying to determine how the website was hacked. Based on our own experience being brought in after them to re-clean websites and everything else we have seen, it is likely those things were not done.

Without knowing what caused the website to be hacked you can’t say what would have prevented it from happening, but we can be fairly sure that SiteLock’s idea of a “proactive approach” isn’t the best way to secure the website going forward:

Once his website was clean, Kasal decided to take a proactive approach to website security by implementing SiteLock® SMART, a daily scanner to help protect his blog from future attacks. SMART provides continuous file scanning to detect vulnerabilities and malware, including backdoor files and malicious code. If malware is identified, it is automatically removed and Kasal is immediately notified.

SMART also provides a full website analysis of each scan, ensuring Kasal’s site is safe and secure at all times.

It is strange that they are describing that as being proactive, since it is clearly reactive. If you are detecting malware on a website, it means it has been hacked and it wasn’t protected. There are further problems with that approach, like the inability to undo the compromise of a website’s data and that SiteLock has a limited ability to remove malicious code automatically (when they are even successful at detecting it).

A quick look at the website shows that is a couple of vulnerabilities that SiteLock must not have detected. Looking at the source code of the website’s pages you scan see that the version 2.9.45 of the plugin WordPress Download Manager is in use:

The plugin is several versions and a couple months out of date, with the next version, 2.9.46, having been released on April 17. That version fixed two vulnerabilities in the plugin, which is somewhat obliquely mentioned in the changelog with these two entries:

  • Added nonce check with settings form
  • Blocked unwanted file type upload

This is a perfect example of where doing the basics would be better, because if the website’s owner was keeping their plugins up to date they would actually be protected against those vulnerabilities. They wouldn’t even have to take manual action do that as there are a number of options available, including our Automatic Plugin Updates plugin, to have plugin updates happen automatically.

Keeping plugins up to date is free, unlike SiteLock’s service, but would another paid service actual have warned about those vulnerabilities? We know of one, our Plugin Vulnerabilities service, which warned about both vulnerabilities even before they were fixed (we also were the ones that discovered one of the vulnerabilities).

One last thing to note is that instead of SiteLock being able to tout that it actually detected those vulnerabilities or any other issue, they instead point to the number items checked:

SiteLock captured’s SMART scan results from a 30-day time frame. During the given 30 days, over 170,000 files, 120,000 links and 15,000 pages were thoroughly scanned for malware.

Sheer numbers clearly don’t equal quality.

Site5 Referring to SiteLock as a Third Party Seems Disingenuous At Best

As we have looked closer at the web security company SiteLock over the last year one of the things that has stuck out is how their web hosting partners are not being upfront about the nature of their partnership with SiteLock.

As we have mentioned before when it comes to one of their biggest web hosting partners, Endurance International Group (EIG), the company has disclosed to investors that SiteLock not only pays them more than half fees for services sold through their partnership, but the CEO and a board of EIG also are the major owners of SiteLock. Those seem like things that should be disclosed to their customers as well since there is an obvious potential for conflict of interest with that relationship, for which their customers should be aware of when considering their recommendations regarding SiteLock. Instead we have found previously that one EIG brand, HostGator, wouldn’t even publicly acknowledge those connections. In that instance they referred to SiteLock simply as a “trusted partner”.

We are frequently contacted by people that have had their web host shut down access to the website based on a claim that the website is hacked and recommend that they hire SiteLock to handle resolve the situation. While in many instances the websites are in fact hacked, there are some serious issues with false claims that websites are hacked. So when we are contacted in those situations we want to find out what evidence there is that the website is hacked first, so that we can double check if the website is in fact hacked before starting on a cleanup. Through that we were recently forwarded a report from the web host Site5 (about a website that was actually hacked), which referred to SiteLock is this way:

If you don’t feel comfortable removing the infected files yourself, we recommend contacting a third party professional who can assist with removing malware, such as SiteLock.

Considering that Site5 has been part of EIG for nearly a year and the connection between EIG and SiteLock, calling them a third party, while maybe technically accurate, clearly doesn’t provide their customers a honest understanding of the connection between the companies. (Not surprisingly from everything else we have seen related to EIG, the quality of Site5 service and support looks to have gone downhill since becoming part of EIG, just look at the number of negative reviews they have received on their BBB page since the purchase).

SC Magazine Is Arming Their Readers With False Information

When it comes to the poor state of security these days, two of the important players to get us where we are, are security companies and the security journalists that are covering them. Security companies have shown for years that don’t know and or care much about security. You would think that with the high profile nature of security today and how bad things are, that journalist would be covering that aspect. It wouldn’t take digging very deep to find lots of material. Instead when it comes to journalists covering security they seem to be more interested parroting the claims of security companies instead of doing any actual journalism.

Take the company SiteLock, which you only have to look what Google suggests when you do a search on them to know about their well earned reputation:

Google second suggestion is "siteLock scams".

Despite that, instead of any coverage of how they and their web hosting partners take advantage of people, journalists would rather parrot false claims they make. Last week looked at a recent example where journalists hadn’t bothered to do any fact checking before running with a SiteLock claim of a trending threat, which if they had likely would have warned them about the veracity of their claims.

Earlier this week we looked at another one of SiteLock’s claims of trending threat, which once again was based on falsehoods. Most notable claiming that a backdoor script with incredibly well known malicious code was not widely recognized:

The code within the shell used to gain the initial foothold is currently listed in the SiteLock malware database, but does not appear to be widely recognized as a threat by many website security vendors at this time. You may use the code snippet below to manually add the shell to your security mechanisms.

In the case of both of SiteLock’s claimed trending threats SC Magazine provided parroted coverage. With the more recent article we left a comment that pointed to a number of the problems in their reporting, but so far it hasn’t been approved, so anyone reading the article is left without a possible counterpoint to the inaccurate information in it.

Providing their readers with false information isn’t in line with how SC Magazine describes themselves in the footer of their website:

SC Media arms cybersecurity professionals with the in-depth, unbiased business and technical information they need to tackle the countless security challenges they face and establish risk management and compliance postures that underpin overall business strategies.

To give some idea of the problems with just that one article, let’s take a look at a few issues with the article.

Here is paragraph that has the false claim that code stays hidden from security programs:

The code manages to stay hidden from many security programs, Kipp noted, suggesting cybersecurity teams manually add this piece of code to their security programs so it can identify an attack.

SiteLock didn’t provide any evidence to back this up and from our years of experience we can say that it either isn’t true or the web security industry is in much, much worse shape than even we think it is in. What is also worth noting there is the link in that sentence, which goes to Looking at that you can probably tell that that page doesn’t actual contain any code, instead it is a sales page. It isn’t clear what they could have been intending to link to because there is no link to any code in SiteLock’s post.

The following paragraph refers to taking control of a computer, but the claimed threat involves taking over websites not computers:

The malware not only enables an attacker to obtain administrative control of a computer, but it also makes the computer’s information publicly available on the web. The reason for this is oddly practical, from the cybercriminals point of view.

SiteLock Services Don’t Update Web Software

We also found the final paragraphs of the article interesting:

Because the malware only goes after known issues with these CMS programs Kipp said it is imperative that those using this software are up to date with their security patches.

“This should really drive home the importance of patching your CMS platform to website owners. Automated campaigns like these are run on an ongoing basis, which attack websites on an almost indiscriminate basis. The majority of web attacks aren’t targeting websites based on their content or popularity, but based on their use of vulnerable outdated software. These are the low-hanging fruit of the web, he said.

First off SiteLock’s report makes no mention of the need to update software, but more importantly as far as we aware SiteLock’s security services don’t involve keeping software on a website up to date, as can be seen in a previous post we did specifically mentioning they don’t do that and one about websites they included in case studies that were running outdated software. That discrepancy between what they say is important here and what they are selling to their customers seems like something a journalist might want to ask them about.

It is also worth noting that SiteLock doesn’t cite any specific vulnerabilities being exploited, which would lead us, based on plenty of experience with that type of claim, to believe that they likely don’t know how the websites were being exploited. We have often seen outdated software blamed as the source of hacks in cases where the person making the claim hadn’t reviewed any evidence that would actually support the claim and in some cases where the software was actually being kept up to date.

A Security Service That Doesn’t Determine How a Hack Happened Isn’t Actually That Helpful

We are frequently brought in to re-clean hacked websites after another company had cleaned it and then it got hacked again. While the re-hacking is not always the fault of whoever did the first cleanup, we have found that companies doing those cleanups are cutting corners. The first thing that we ask after it is brought up that someone previously cleaned up the website, is if they determined how the website was hacked and gotten that fixed. If that hasn’t happened it obviously leaves open the possibility of the website being hacked again. The answer is almost universally that doing that never even came up. It shouldn’t be that way since trying to determine that is one of the three basic parts of a proper cleanup. So either these companies (we have heard it about a lot of different companies over the years) don’t know what they are doing or are intentionally cutting corners.

We recently ran across a reminder that the web security company SiteLock either doesn’t understand the importance of doing that or doesn’t want to have to do the work required to things properly, as they didn’t tell truth about needing to do this. In a thread on the WordPress support forum, which came up in our monitoring for discussions of vulnerabilities in WordPress plugins that we do for our Plugin Vulnerabilities service, a SiteLock customer had been notified their website had been hacked:

We signed up for SiteLock which was helpful and told us this morning that we had a malware warning for “defaced pages” – sure enough, the list they provided was full of similar material to the last one. This time it said “just for fun” and “hacked by GeNeRaL.” Since we’re on the latest version of WP, and we had updated our password to one of the long, random, extra-complex ones that WP suggests, I don’t know what to do to prevent this. I deleted all of the blog posts, but is there anything better we should be doing?

There are a lot of things that could be focused on there. The fact that they received a malware warning for “defaced pages”, despite that not being a malware issue (that lack of clarity is even more problematic when they are falsely claiming that a website has an issue identified by their scanner). The fact their customer either is not be able to or not feeling they can get in touch with the people they are paying to protect their website about a concern they have. But will focus on the claim that SiteLock was helpful despite clearly leaving this person unaware of what caused the issue, which is in fact the most important part here.

Before we get to that though, we have to mention an example of the poor quality responses from moderators when you post about security issues on the WordPress Support Forum in this thread. As is often the case this person did not get relevant advice from a moderator:

Take a deep breath and carefully follow this guide. When you’re done, you may want to implement some (if not all) of the recommended security measures.

If you’re unable to clean your site(s) successfully, there are reputable organizations that can clean your sites for you. Sucuri and Wordfence are a couple.

Not only did they not address the specifics of the poster question, they promoted two security companies. Neither of those companies are ones that we would refer to as reputable. We just had a post on Sucuri claiming one of their customers website that had malicious code to compromise credit card info entered on it was clean and recently had one on their scanner producing a rather bad false positive that lead to them claiming our website was defaced (we also frequently see moderator pointing to people to their poor quality scanner). With Wordfence, they don’t seem to understand the basics of security and spreads falsehoods about the security of WordPress. Why someone connected with WordPress would be promoting a company spreading falsehoods about the security of WordPress is as baffling as it is troubling.

The response from someone at SiteLock in the thread didn’t raise the need to determine how the website was hacked, instead they stated:

The bottom line is that you’re most likely in the clear regarding that particular incursion, but continuing to run malware scans on an ongoing basis is your best way to be certain.

Even if a malware scanner is good at what it does (and SiteLock’s doesn’t seem to be) from a technical perspective it simply cannot detect everything. Of course doing things right would increase SiteLock’s costs, whereas telling someone to continuing to use their service to have scans continue would make them more money.

The thread went on for a bit and ended with the person not being able to get in touch with someone at SiteLock that would actually determine how the website was hacked:

I tried to ask for you when I called, but it sounds like they couldn’t find you at the time. The rep I spoke with checked the site in question and said there are only 95 pages. Do you think it’s an issue with SiteLock not noticing it, or is it more likely that this more recent hack cropped up as a result of some other vulnerability (a plugin, theme, something else)?

Despite the service not doing what should be done they thought they had been helpful and were open to possibly giving more money to SiteLock:

We’ll most likely want to add on several other domains to this account and possibly upgrade. Thanks for your help!

Every time someone does something like that it hurts everybody because it helps bad security companies like SiteLock spread, which means that he needed improvements to security are less likely to happen because those companies keep pushing people away from focusing on the things that would actually improve security.

SiteLock Threat Intercept Falsely Claims That Widely Known Backdoor Code isn’t Recognized as a Threat

Last week we looked at the fact that web security company SiteLock’s recent claim of a trending threat had an obvious falsehood in it, which was that a malicious WordPress plugin was a forgery of legitimate plugin despite the supposed legitimate plugin not existing. The rest of their post on the issue lacked evidence to back up their claims and it seemed that the malicious plugin might be rather old and not a new trend. Unfortunately a number of security news source repeated their claims verbatim instead of doing any fact checking (with two of them we left comments on their posts mentioning that the legitimate plugin didn’t exist, but neither of them have approved our comment to show on the posts yet)

Based on that and everything else we have seen from SiteLock isn’t really surprising to see that they made an obviously false claim with their next claimed trend as well.

Before you even get to the contents of the post there already is something that looks us to be a good red-flag that the post isn’t something that should be taken seriously, it’s this graphic:

It reminds of the overused breaking news graphics on cable news, which seem to be used for things that don’t seem to qualify far too often.

The main portion of the post is a good example of the poor quality content put out by security companies. Frequently they will dress things up to make something trivial or in some cases made up, seem more serious. In this case with this infographic:

They even give the claimed trend a name (because trying to brand vulnerabilities was not enough).

At the heart of the claimed trending threat is that websites running outdated software can be hacked:

The vectors used to infect websites appear to be well-documented vulnerabilities in older versions of website platforms.

Which isn’t anything new. It is worth noting that SiteLock doesn’t cite any specific vulnerabilities, which would leave us to believe they don’t actual know the source of hacks. We have often found security companies and web hosts will claim that website have been hacked through outdated software based on zero evidence (in some cases we have seen this claimed when the software of the website was actually being kept up to date). From everything we have seen SiteLock usually doesn’t determine how websites are hacked when cleaning them up, despite that being one three main pieces of doing that correctly, which increases the chances that they don’t actually know in this instance either.

If there was something worth noting here it relates to the possible compromise of cPanel login credentials, not CMS credentials, through the hack. SiteLock make no direct mention of that, only mentioning to change the cPanel password if using that, which is another indication that SiteLock doesn’t have much security expertise and experience.

SiteLock Doesn’t Suggest Taking the Action to Prevent the Real Threat

The last section the post is what seems to be the real point of their post, to promote one of their products, which doesn’t actually fix the claimed root of this, which is outdated and vulnerable software. It starts this way:

Here’s what you need to do

As this trend both provides administrator-level control over the target website environment as well as publicly discloses credentials, action must be taken to counter both threats.

Since again, the important threat is the vulnerability being exploited to allow the hacker access to the website in the first place, not what could be done if it is exploited since that can be stopped from happening, you would expect the first action they suggest be to make sure the software on a website up to date, instead it is:

  • Run a malware scan to locate the presence of any shell files. (see: SiteLock Malware Scanners)

In fact updating the software on the website isn’t listed at all. Do they want websites to remain vulnerable to being hacked? It is worth noting that we are not aware of any SiteLock ongoing security services that include them keeping a website’s software up to date (not surprisingly we have seen numerous instances of their customers using those services getting hacked.)

False Claim

Finally let’s look at the false claim, which is this:

The code within the shell used to gain the initial foothold is currently listed in the SiteLock malware database, but does not appear to be widely recognized as a threat by many website security vendors at this time. You may use the code snippet below to manually add the shell to your security mechanisms.

Looking at the screenshot they provided of the backdoor script, there is a line code that would immediately stick out to anyone that regularly deals with hacked websites:

That would be this part “$default_action = ‘filesman'”. Looking back it looks like backdoor scripts with that line of code have been in existence at least since 2010.

The idea that the code wouldn’t be “widely recognized as a threat by many website security vendors at this time” indicates SiteLock is clueless, is lying, or thinks the rest of web security industry is even worse than them (which might explain their laughable claim to be the global leaders in website security). None of those possibilities is something that should be able to be said about a security company.

SiteLock Will Try To Sell You Services You Don’t Need and Can’t Use

Over the last year or so, as we have seen and heard more about the web security company SiteLock’s practices, it has become more clear that a lot of what they are doing can reasonably described as scamming. Take for example a recent issue brought up on the customer complaints section of their BBB page, which starts with the complainant being contacted by one of SiteLock’s sales people (who are commissioned, which will be relevant in a moment):

The… details are as follows: I spoke to someone back in October after Sitelock called me warning that I needed more security on my websites. Sitelock was very persistent, with an employee calling me and leaving messages daily until I finally agreed to speak with him. After being convinced that there was a danger to my domain during a very long conversation with one of the employees, I agreed to move forward although the price seemed outrageous, and was then passed on to the billing department.

All of this sounds like numerous other stories we have heard when people contact us after interacting with SiteLock (most of them have luckily avoided signing up for something from SiteLock before contacting us to get a second opinion) and we have read online. A legitimate security company wouldn’t keep calling someone like this, but a commissioned sales person is likely mainly interested in getting a commission, not in what a legitimate security company would do.

Based on that what comes next isn’t surprising, but it is interesting that others at SiteLock are clearly aware that something wrong is going on:

The woman at the billing department actually pointed out to me that my sites were hosted on Shopify, and therefor would not be eligable for Sitelock security as they were being hosted by Shopify’s own very protected servers and were actually not at risk in any way, nor could Sitelock be of use to me. She told me I did not need the service I was sold.

There is something quite wrong when the billing department seems to be more aware of whether some can use services than the sales people that are selling them, which gets back to the issue of scamming going on (the sales person gets a commission whether the service is used or not).

Unfortunately, that didn’t end their interaction with SiteLock:

I chose to believe that the original employee who called me telling me my sites were in danger was not intending anything dishonest, but that he didn’t realize where my sites were hosted and gave me the wrong information. I no longer think this was an honest mistake after being repeatedly charged. I told the woman in billing that, obviously, I agreed that I did not need to go through with the subscription, and it was cancelled. Since that time, I have been repeatedly billed, totalling $1023.99, and I’m sure I will again be billed next month as Sitelock has not responded to my requests for refunds and termination of any services.

This isn’t the first time we have heard of how hard SiteLock makes it to cancel services once they have gotten you signed up, which seems quite intentional at this point.

Part of SiteLock’s response to this is rather incredible:

We always put our customers first, and strive to deliver exceptional customer satisfaction.

Do they think that people will believe that selling a very expensive service that someone didn’t need based on what seem to be lies, is in anyway putting customers first?

It appears this customer was able to get the situation resolved to their satisfaction, so if you are in the same situation it looks like filing a complaint with the BBB could resolve the issue (if it does, please let us know in the comments section below). You should also make sure to leave a review there as well, so people looking into their service know what is really going on.

Journalists Spread SiteLock’s Fake Claim Involving Nonexistent Legitimate Plugin

When it comes to security journalism, there doesn’t seem to be much actual journalism going on. Instead much of what passes for news coverage these days simply involves repeating the claims of security companies, without doing any fact checking of those claims. This would be a problem just based on the low quality of information coming from security companies, but it looks to us that security companies have realized that in getting coverage what matters is not the truth but saying something that a journalist think they can get clicks by repeating.

A good case in point of journalist simply repeating a security company’s claims we ran across recently was a claimed trending WordPress security issue. Beyond the fact that no evidence was presented that actually backs up the claim that the issue was trending or that the issue was is some way actually significant (and deserved to be covered instead of another issue), something else stood out to us. In the security companies SiteLock’s post on this issue, they claim a “fake” plugin involved in the issue is a forgery of a legitimate plugin:

It is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

In coverage of the issue, that claim was repeated by journalists. Here is how it was reported in the Threatpost’s article:

The fake WP-Base-SEO plugin is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

Here is how it was reported in Infosecurity Magazine’s article:

Dubbed WP-Base-SEO, the plugin is a forgery of a legitimate search engine optimization plugin, called WordPress SEO Tools, according to SiteLock, the firm that originally uncovered the threat.

Finally here how it was reported in SC Magazine’s article, this time without naming the claimed legitimate plugin:

The fake plugin is called WP-Base-SEO and is based on a legitimate SEO module so it is easily overlooked during security scans and seems to be a viable tool by a web team intent on boosting its traffic, said a research team at SiteLock.

The problem with all this is that the supposed legitimate plugin WordPress SEO Tools doesn’t exist. If you do a Google search on the name or on WP SEO Tools it doesn’t bring up results for a plugin with that name. Looking at the Subversion repository that underlies the Plugin Directory, where most plugins are found, there are not entries for a plugin with the slug wordpress-seo-tools or wp-seo-tools.

This should have been something that journalists could have easily checked and if they had look into that they might have realized something was amiss here.

In a quick check over this, something else also stands out to us. While the reason for this issue getting covered is that the “fake” plugin is supposed to be trending, it looks as it might be rather old (or at least based on something that hasn’t been updated in a long time). That is particular noticeable in the screenshot provided by SiteLock of the plugin’s header comments:

The copyright there is 2013, though on its own wouldn’t mean much, what is more noticeable in dating this is this the Plugin URI, which is If you visit that URL now you are redirected to, which is the address of the Plugin Directory. So why would the URL include “extend” when it doesn’t exist the URL you are redirected to? The answer is that the “extend” used to be part of the URL, but that was removed on May 22, 2013 (the switch to HTTPs occurred in 2014). Based on that it is entirely possible this malicious plugin isn’t a new issue, just being promoted that way so that a security company could get coverage.