The Online Trust Alliance Doesn’t Seem Too Trustworthy

When it comes to words that might be reasonably associated with the web security company SiteLock one of them isn’t “trust”. You don’t have to look farther that Google’s search suggestions to see that:

Google;s second search suggestion for "sitelock" is "sitelock scams".

But if you do want to look farther you could look at the situation where with a couple of their services, their content delivery network (CDN) and web application firewall (WAF) services, they promote the services as if they themselves provide them. For example, they use phrases including “SiteLock servers“, “SiteLock patent-pending technology“, and “our IP addresses“. But in reality the service are provided by another company, Incapsula. Beyond just having a security company lie about something that there doesn’t seem to be a need to, the lie is rather troubling because both of those service involve sending a website’s traffic through a third-party’s systems. While SiteLock’s customers are told those systems are theirs, it turns out they belong to a company that the customers neither are aware or have a business relationship with. That raises some pretty obvious privacy and security concerns.

Based on that we don’t understand how an organization named the Online Trust Alliance would think it is appropriate to name SiteLock to their “Online Trust Audit and Honor Roll”, as announced by a SiteLock press release.

The press release lists what is evaluated for that:

As the only comprehensive, independent online trust benchmark study, the ninth annual OTA Online Trust Audit evaluates websites in three categories: consumer protection, responsible privacy practices and security. Based on a composite weighted analysis, sites that scored 80 percent or better overall, without failing in any one category, received Honor Roll status.

If you look at the complaints from SiteLock customers it sounds like the public is need of protection from SiteLock (just last week looked at an example of SiteLock trying to sell a customer on getting unneeded work done). As for security, while SiteLock’s website may be secure, that isn’t even the case for customers included in SiteLock’s cases studies.

Security Plugins and Plugins by Automattic Haven’t Been Updated To List Them as Compatible With WordPress 4.8

Back on May 31 we received an email from asking us, as developers of several plugins, to make sure that the plugin were listed as being compatible with the then upcoming WordPress 4.8. The beginning of the message reads:

Hello, White Fir Design!

WordPress 4.8 is scheduled to be released on June 8. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.8. This information provides peace of mind to users and helps encourage them to update to the latest version.

As scheduled, that version was released on June 8.

While looking at something the other day we noticed that a security plugin had not been updated to list as being compatible with the new version. Looking at the plugins tagged security it turns out that many haven’t been two weeks after the release of that new version of WordPress. That doesn’t seem to be a great indication as to the state of security plugins, but more striking was that several of the most popular plugins tagged security that have not been updated come from the company Automattic, which is closely associated with WordPress.

First up being Jetpack by, which is tied with 6 other plugins for having the most active installs, 3+ million:

One of those other plugins with the most active installs is another Automattic plugin, which despite shipping with WordPress also isn’t listed with WordPress 4.8:

Getting back to the security tagged plugins, another Automattic plugin not listed as being compatible is VaultPress:

Among the other security tagged plugin that haven’t been updated to be listed as being compatible, you have iThemes Security:

You also have Sucuri Security, which still hasn’t even been listed as being compatible with WordPress 4.7, despite that being released in December:

The parent company of that plugin GoDaddy also hasn’t updated their other plugins to list them as compatible:

Also worth noting, considering SiteLock’s questionable involvement with WordPress, is the SiteLock Security plugin:

Google Handling Advertising For Website Serving “Nulled” WordPress Themes and Plugins With Malicious Code

Recently Google has been deciding to show ads for one of our services on websites serving “nulled” web software, which is paid web software being distributed illegal, possibly with security measures removed from it. That isn’t something we are interested in having our ads run on and we have excluded those websites from showing our ads. Today while looking into a hacked WordPress website that we were contacted about, we noticed that Google is handling the advertising for another such website,, where “nulled” WordPress themes and plugins are being distributed with malicious code in them.

At the top of the homepage are two ad blocks being served by Google (bordered in red):

The website (and the others that had included our ads) seems to pretty clearly be in violation of Google’s AdSense programs policy related to copyright material:

AdSense publishers may not display Google ads on pages with content protected by copyright law unless they have the necessary legal rights to display that content. This includes pages that display copyrighted material, pages hosting copyrighted files, or pages that provide links driving traffic to pages that contain copyrighted material.

The malicious code being reported to be served with the software at that website would seem to cause the website to violate a couple of their content guidelines as well:

It doesn’t seem like it would be hard for Google to detect that these websites are engaged in the activity they are, so it seems if they didn’t want them to be in their advertising program they already could be excluded. We have been reporting the ones that have been showing our ads, though. Warns About Similar Websites Distributing Files Containing Viruses

While the website prominently links to a page for filing DMCA takedowns for copyrighted content on the website, the website is promoting that it actually is involved in placing such content on their website, which would seem to remove the safe harbor protection that DMCA provides for websites:

For your money, we'll buy new wordpress themes.

While a WordPress theme’s (or a plugin’s) code would need to be licensed under the GPL and therefore can be legally distributed to others after being purchased, other assets included with them would not.

On the “Submit Your Theme or Plugin” page, they pretty clearly are requesting content that they know wouldn’t be legal for them to distribute. But more striking is that they ask people submitting themes and plugins to not submit them from other similar sites because they “can share files with viruses”:

Here you can send your nulled themes and plugins. Please do not send files from another sites! Another sites can share files with viruses. Share only from themeforest or codecanyon!

Cloudflare Too

Google isn’t the only legitimate company involved with this website, as when we went to check to see where the website’s server was located we found that it is being served through Cloudflare.

A couple of months ago we found them doing the same for a website being used as part of a hack to compromise credit card credentials.

A Single Tweet Nicely Sums Up the Problem With WordPress Allowing SiteLock to Be Involved With WordCamps

The web security company SiteLock has a well earned reputation that can be summed up with what Google suggests when you type in their name:

Google's second suggestion is "sitelock scams".

That obviously isn’t a reputation you would think that any company would want. It would probably be difficult for SiteLock to legitimately change it though since their business model seems to be based around the activity that gets them labeled as such.

It would also be difficult because if they, for example, stopped partnering with web host to try to get people to pay them to clean up hacked website that are not in fact hacked, then they would actually have to really clean up websites to get paid and from everything we have seen they are even worse than the average web security company, which is already quite bad, when doing that. For example, we are often brought in to re-clean hacked websites after some other company had previously had done that and then the website got hacked again. While that isn’t always their fault, in almost every instance we have been told that the determining how the website was hacked never even came up, despite trying to do that that being a basic part of the cleanup and important to make sure the vulnerability that allowed the website to be hacked has been fixed. That is certainly something we have seen with SiteLock. What we haven’t seen with other companies is that SiteLock has caused websites to be broken after doing their work.

Instead of trying to change, SiteLock looks to have focused on various efforts to present a public face very different than the one that their customers and not always willing potential customers can find themselves dealing with. What looks to be an important component of that effort is their involvement and sponsorship in the conferences for WordPress, WordCamps, which uses money they have gotten from their questionable business practices. We think a tweet put out by one of those WordCamps succinctly shows what the problem with WordPress allowing that to occur is:

The claim that SiteLock wants make your WordPress secure is belied by many things we have run across, including a few recent examples: thinking that leaving malicious code on a website for a while is not a threat, not taking the actions needed to prevent hacked websites from being reinfected, and not warning about vulnerable plugins or insuring they are being kept up to date on a website they are supposed to be keeping secure. But maybe the most troubling recent example is that SiteLock is still knowingly spreading false information about the security of the core WordPress software and using it to make a profit. We would love to hear from someone on the WordPress or WordCamp side of things how that makes anyone’s WordPress secure.

At some point, maybe we have already reached that point, you have to say that WordPress is complicit in what is going on here. Back in September of last year we contacted the central WordCamp organization to let them know that about the issues with SiteLock and ask for a comment about the situation or a more general comment on any restrictions on who can be a sponsor. We never got any response from them, though it was pretty clear they saw the message. So it seems that they can’t actually justify what is going on, but are still willing take money SiteLock has gotten through less than above board business activity. We later left a comment on a blog post about SiteLock on the WordCamp US’ website, shortly afterwards the comments left on that post were removed and commenting was disabled, so there does seem to an effort to hide what is going on.

What could explain some of why they continue to allow SiteLock’s participation is that SiteLock’s owners don’t just sponsor WordCamps under the SiteLock brand, but also through brands of the web hosting company Endurance International Group, which they run. For example, at WordCamp Europe they were a higher level sponsor through EIG brands Bluehost and MOJO Marketplace (MOJO Marketplace also doesn’t seem to be too concerned about security):

Joomla 3.7 is Not Hack-Proof

When it comes to bad information on the security of websites, far too often that information is coming from companies offering security services. A recent example we came across, while dealing with a hacked website, involved a Joomla focused web development company that in their marketing their service for upgrading or migrating to Joomla 3.7 claimed that Joomla 3.7 is “hack-proof”:

That certainly isn’t a claim that is made by Joomla (nor would you expect it to be a claim that is likely ever made by someone trying to be taken seriously).

Already a “high” priority SQL injection has been fixed since 3.7.0 was released, which was considered serious enough for Joomla to pre-announce that a security update was coming.

The same company offers to clean up hacked Joomla websites, so they should know better than to make that sort of claim and in fact they seem to understand that vulnerabilities continue to be found in Joomla based part of how they advertise that service:

We will identify possible loop hole in security and install required updates and patches. Because of consent Joomla and component upgrades, this is a critical step to prevent hacking.

In describing their service there was also this troubling claim:

As soon as we are engaged to fix your hacking issues or to prevent your website from hacking, we will do a thorough analysis and prepare an action plan to recover your website at the earliest. Mostly a Joomla upgrade should fix it, but it depends on the kind of website and problem you have.

We deal with lots of hacked Joomla websites and upgrading would not normally fix them. Perpetuating that idea is decidedly not helpful, as if our experience is any indication people with hacked website will often come to that conclusion and then hire someone to upgrade it without mentioning that they are doing that to clean up hack. Trying to upgrade a hacked website could actually make the situation worse, as it might cause the upgrade to go wrong and it could erase important evidence needed to determine how the website hacked, which may be needed to prevent it from being hacked again.

SiteLock Uses Harmless Activity on Website as a Reason to Try to Sell Unneeded Malware Removal to One of Their Customers

When you have a malware infected or otherwise hacked website it can make a lot of sense to hire someone with expertise in handling the cleanup of them to do that for you. Beyond that they would have the knowledge to quickly resolve the issue for you, where we have seen the value of doing that for our clients is that they often can use help understanding what is going on. Often times they are concerned about things that they don’t need to be and we can easily clear things up for them.

Unfortunately, far too often they are concerned about things due to misleading or outright false information being put out by other security companies. That then leads in to the big problem when it comes trying to hire an individual or a company for any type of security service, many of them really don’t know and or care much about security. On top of that there doesn’t appear to be good way to find one that isn’t true about, since these companies don’t seem to have a problem with lying and reviews of them come from customers who often are unlikely to have a good sense of the quality of the service they have gotten since they don’t have the expertise needed to determine that (we have had people saying another company did a good job even after they have hired us to re-do work that wasn’t done right by that company).

We recently had someone that came to us that believed there website had a re-occurrence of a malware issue and were looking for an alternative to the company they were already paying to secure their website, SiteLock, to do deal with it. That was in part because SiteLock had not detected any issue they had noticed.

The first thing we always do when someone comes us to about dealing with a malware infected or otherwise hacked website is to determine that it is in fact hacked. In this situation the belief that the website was infected with malware was based on some things the website’s owner had seen in the log file of HTTP activity. In reviewing those we found that those things were harmless. There were several request for spammy URLs, but the status code of the responses was 404, which indicates that a page with that URL did not exist. The other concerns related to request coming from a Russian search engine and requests coming from the file that does cron jobs for WordPress. Other checks should no current issue with the website.

SiteLock had given them a very different response when they had brought up what the customer had seen the log. SiteLock didn’t address the specifics that were raised and seemed to just assume that the website infected. They implied that the infection coincided with the SiteLock’s web application firewall (WAF) service that was in use being downgraded from “Enterprise level” to the “Premium level” (contrary to SiteLock’s marketing that service is actually provide by another company). To resolve the issue they suggested upgrading the WAF back to “Enterprise level” and having their “Expert Services” clean it up.

If all that were true it would seem to be reasonable to ask why they offer the “Premium level” WAF that permitted the website to get infected. You might also ask why you should pay more to clean up a website when the service you already paying to protect didn’t actual accomplish that.

While it is possible that SiteLock assumption that the website was infected and recommending that more money being spent with them was based on them not understanding that you should determine that a website was hacked before trying to clean it up, everything we have seen points to something else. That being that from everything we have heard and seen when you get in touch with SiteLock you are usually going to interact with commissioned sales person. It wouldn’t be surprising that a person that is not a tech and are getting paid if they can sell you something, would instead of determining that there wasn’t any issue, try to sell this person on an additional service and to a more expensive version of an existing service. It also would be in line with what have heard in numerous other instances when SiteLock failed to provide protection, that the answer was to move to a more expensive service.

SiteLock Still Spreading False Information About the Security of WordPress to Their Customers

Back in September we wrote about how the web security company SiteLock had introduced a new feature that was supposed to warn about vulnerabilities on WordPress websites, but would falsely claim that websites running older WordPress versions had vulnerabilities in them that they didn’t.

This seemed to be caused in part by a fundamental lack of understanding of how WordPress handles security, which involves security fixes being released for older version of WordPress that have the automatic background updates feature (WordPress 3.7 and above). This is something that anyone dealing with hacked WordPress websites should know since part of properly cleaning them involves determining, to the extent possible, how they were hacked and you would need to know what vulnerabilities would exist in a version of WordPress when cleaning it. From everything we have seen SiteLock doesn’t properly clean up hacked websites (and they even use that fact as a reason to upsell their customers), so maybe it shouldn’t be surprising they wouldn’t know this.

It also seems to be caused in part by them not understanding the underlying data source for the vulnerability information, the WPScan Vulnerability Database, as that correctly labels which versions of WordPress are vulnerable to the vulnerabilities (as we will show in a bit).

We know that SiteLock is aware of all of this as they clearly read our post as they filed a DMCA takedown notice to remove an image we had included in the post.

You would think that after becoming aware of this SiteLock would have fixed this, right? Well it turns out 9 months later they are still falsely claiming that WordPress website contain vulnerabilities they don’t.

The other day someone contacted us after they had been told by their web host iPage that they their website had security issues and they should sign up for SiteLock. After doing that they contacted us after seeing our previous post about this issue and thinking that what SiteLock had told them about vulnerabilities on their website wasn’t true.

The website was running WordPress 4.6.6 at the time and SiteLock claimed it had the following medium and high severity vulnerabilities:

Severity: High
Category: csrf
Summary: WordPress 4.2-4.7.2 – Press This CSRF DoS
Description: CSRF DoS vulnerability in WordPress versions 4.2 to 4.7.2 through the Press This functionality.

Severity: Medium
Category: rce
Summary: WordPress 4.3-4.7 – Potential Remote Command Execution (RCE) in PHPMailer
Description: Potential Remote Command Execution (RCE) in PHPMailer used in WordPress versions 4.3 to 4.7.1 can potentially be used to remotely execute commands.

Severity: High
Category: bypass
Summary: WordPress 4.2.0-4.7.1 – Press This UI Available to Unauthorised Users
Description: Authentication bypass vulnerability in WordPress Press This versions 4.2.0 to 4.7.1 allows unauthorized users to access the UI.

Severity: High
Category: csrf
Summary: WordPress 2.8-4.7 – Accessibility Mode Cross-Site Request Forgery (CSRF)
Description: Cross-Site Request Forgery (CSRF) in WordPress versions 2.8 to 4.7 via Accessibility Mode allows unauthorized actions to be performed.

Severity: Medium
Category: bypass
Summary: WordPress 2.8.1-4.7.2 – Control Characters in Redirect URL Validation
Description: Control Characters vulnerability in WordPress versions 2.8.1 to 4.7.2 through the Redirect URL Validation

Severity: Medium
Category: unknown
Summary: WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)
Description: Cryptographically Weak Pseudo-Random Number Generator (PRNG) vulnerability in WordPress versions 3.0 to 4.7 in the multisite activation key creates the potential to guess/brute-force the activation key.

Severity: High
Category: xss
Summary: WordPress 3.4-4.7 – Stored Cross-Site Scripting (XSS) via Theme Name fallback
Description: Stored Cross-Site Scripting (XSS) WordPress versions 3.4 to 4.7 via Theme Name fallback allows malicious code to be stored on the site.

Severity: High
Category: xss
Summary: WordPress 4.3.0-4.7.1 – Cross-Site Scripting (XSS) in posts list table
Description: Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.3 to 4.7.1 through the posts list table.

Severity: Medium
Category: xss
Summary: WordPress 2.9-4.7 – Authenticated Cross-Site scripting (XSS) in update-core.php
Description: Authenticated Cross-Site scripting (XSS) WordPress versions 2.9 to 4.7 via update-core.php allows malicious code to be injected to the page.

Severity: High
Category: xss
Summary: WordPress 4.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) in YouTube URL Embeds
Description: Authenticated Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.0 to 4.7.2 allows an attacker to inject malicious code on to the site through YouTube URL Embeds.

Severity: High
Category: xss
Summary: WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata
Description: Authenticated Cross-Site Scripting (XSS) vulnerability in WordPress versions 3.6.0 to 4.7.2 allows malicious code to be injected on to the site via Media File Metadata

Severity: High
Category: sqli
Summary: WordPress 3.5-4.7.1 – WP_Query SQL Injection
Description: In WordPress 3.5 to 4.7.1 WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data.

Severity: Medium
Category: unknown
Summary: WordPress <= 4.7 – Post via Email Checks by Default
Description: Post via Email Checks by Default in WordPress version 4.7 and earlier.

Those vulnerabilities don’t exist in WordPress 4.6.6, which can be seen by looking at the relevant entries in the WPScan Vulnerability Database. Let’s take a look at a couple of examples:

For the vulnerability “WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)” the vulnerability was fixed in version 4.6.2:

For the vulnerability “WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata” you can see that it was fixed in version 4.6.4:

It also worth noting here that the severity ratings that SiteLock provides here look to be vastly overstated since none of these vulnerabilities is likely (or has in fact been) exploited on wide scale, which you would expect at least for vulnerabilities rated as being high severity.

iPage isn’t innocent in this, as not only do they get a significant percentage of the price being paid for SiteLock services sold through their partnership, but their parent company also happens to be run by SiteLock’s owners.

You would also think that WordPress might make a point of warning people away from SiteLock since they are profiting off falsely claiming that WordPress websites contain vulnerabilities, but instead they have welcomed them as sponsor and speaker at various WordCamps, WordPress conferences. In fact they thanked them for their “commitment to the WordPress community”:

We’d like to thank each of our 2017 global community sponsors for their commitment to the WordPress community. Their generous contributions support community events like WordCamps and WordPress user groups worldwide.

The Problems Caused By SiteLock Using Nessus as Their Vulnerability Scanner

The other day we mentioned how we often have people that contact us about situations where the web security company SiteLock has contacted them claiming that their website has malware, but SiteLock has not provided any evidence of that. Recently we have started being contacted about situations where SiteLock is contacting a website’s owner claiming that the website has some vulnerability that could lead to the website being hacked. So far in those instances SiteLock has not provided any evidence to back up their claims, so we can’t access their validity directly. But we have continued to see problems with their vulnerability scanner, which seems like it would likely also be what would be the source of their claims.

What looks to be an overarching issue with their vulnerability scanner is that the underlying technology isn’t really designed to be in the fashion it is. Back in December we stumble on to the fact that at least part of their vulnerability scanner is really just them using a piece of software named Nessus, which as best we can tell that is something that isn’t really designed to be used by end users. Instead it looks like it is designed to be used by security professionals and software developers. For them producing false positives would be less of an issue since they could fairly easily evaluate if there is an issue, whereas end users are not usually going to have that capability. It is even more of a problem if someone is using those unreliable results to try to sell people on security service, as SiteLock might be doing.

An example of the issue can be seen in a recent thread on the WordPress Support Forum, where someone got notified of a claimed security problem in the login page of a WordPress blog:

This was sent to me by SiteLock about a security problem on my wordpress blog. The CGI issue is attached to the login page. Can this be fixed please?

Synopsis: A CGI application hosted on the remote web server is potentially prone to SQL injection attack.

Description: By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.

An attacker may be able to exploit this issue to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system.

Note that this script is experimental and may be prone to false positives.

Solution: Modify the affected CGI scripts so that they properly escape arguments.

Right off the bat this information doesn’t seem end user friendly as it looks as though the reference to CGI script in that is really a reference to any sort of code running on a website (as can be seen by this list of CGI abuses on the website for Nessus).

That confusion lead to a moderator falsely claiming that it would appear the website is compromised:

WordPress does not use CGI for anything, so if you’re getting that on WordPress’s login page, it would appear that your site has been compromised as their tool has identified.

Carefully follow this guide. When you’re done, you may want to implement some (if not all) of the recommended security measures.

Beyond that two things stick out.

The first being the statement noting that “this script is experimental and may be prone to false positives.” Why is something experimental and known to produce false positives being used to produce the results of SiteLock’s vulnerability scans?

The second one being the part that states “By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.”. Changing the values that are sent with a request could produce a very different response for obvious non-security reasons. Say if you changed the value of parameter specify what to be search for on a search page, you would expect to get different results. If you sent an invalid value with a request you might also get a very different result than if you sent a valid one.

Based on everything we have seen from the results of SiteLock’s vulnerability scanner so far, the results don’t look reliable. So we would recommend avoiding it if you are looking to determine the security of your website. If you do have them claiming that there is a vulnerability and you want to be on the safe side, we would recommend you get a second opinion from someone familiar with handling security issue with the software you are using.

Hacker Provides More Information on Fixing Defacement Hack Than SiteLock and HostGator

When it comes to claims that a website contains malware or is otherwise hacked coming from the web security company SiteLock or their web hosting partners our recommendations is to not ignore their claims despite the serious problems with false claims. Instead we recommend getting a second opinion from another company that deals with hacked websites. We are happy to do that for free and a lot of people have been taking us up on that offer.

The first thing we do when contacted about a second opinion is to find out what evidence SiteLock and or the web hosts has provided as to the claimed issue. In doing that we have seen that in most cases the supporting evidence of the claim falls in to one of two very different categories. In the first they have provided a listing of examples of impacted files and in the other they provided no details whatsoever. So far we haven’t seen a strong correlation between either of those and veracity of the claim.

In one recent instance where a website was really hacked they provided no information whatsoever, while the hacker actually provided helpful information.

In response to our question about what evidence the owner of the website mentioned they had received none despite multiple calls a day, but they had noticed a couple of pages in the Google search results with hacked content.

From that we already had a good idea as to what was going on.

When we looked at those pages we found that they had the following message:

Hacked By Not Matter who am i ~ i am white Hat Hacker please update your wordpress

The only vulnerability that has existed in the core WordPress software that has been exploited in a wide scale in years (maybe close to a decade) was vulnerability that allowed modify the content of posts, which existed in WordPress 4.7.0 and 4.7.1. As long as WordPress’ automatic background updates were working properly this vulnerability was not a threat, as it was fixed with a new version well before the vulnerability started being exploited. That issue could have explained how a hacker was able to add that message to the pages they did.

Based on all those things it wasn’t surprising to find that the website was running WordPress 4.7.1.

At that point we recommend that the website’s owner update WordPress, undo any changes made to the post content, and see about making sure that automatic updates are able to function going forward.

If SiteLock or HostGator had told them that in the first place the issue could have easily been resolved, but it likely wouldn’t have lead to a SiteLock sale, which is possible explanation why they wouldn’t do that. You might be wondering why a web host wouldn’t want their customer to be secured, the answer is in part that HostGator and other Endurance International Group brands received a lot of money when SiteLock sales are made through their partnership. Another part of the answer is that SiteLock’s owners also run the web hosting company.

It isn’t just that they didn’t provide any details; they told them something that is not accurate with this type of issue:

“During a recent SiteLock security scan of your website, malware was detected that could jeopardize the safety of your website and your customers’ data.”

The website doesn’t look to have contained any malware. The reason for the claim that malware was detected appears, based on our previous experiences, to be due to SiteLock’s malware scanner not just be used to detect malware, but any evidence of a hack, but any issue detected incorrectly being labeled as a malware issue.

iPage Provides Conflicting and Bad Advice on Cleaning Hacked Websites

When it comes to dealing with a hacked website, the advice you are going to get from a web host isn’t necessarily very good. For example, we have often seen them tell people their websites must have been hacked due to outdated software, without the web host having done anything to determine if that was true (and in some cases despite the website not even using outdated software). In one recent instance we found that one of the brands of the web hosting company Endurance International Group, JustHost, was pointing toward an outdated version of Joomla as the source of hack, while they were offering to install that version on websites despite support for it ending over two years before. Since the installation occurred through another Endurance brand, MOJO Marketplace, it looks like that version probably being offered for install across their other brands as well.

With that that type of thing happening at Endurance, it might not be surprising to see what we recently came across while doing a consultation with someone with a hacked website using one of their other brands, iPage, in which they provided conflicting and bad advice on dealing with a hacked website.

Here was is most of the original email they sent to their customer about a hacked website:

During a routine scan, we detected suspicious contents that suggest your ‘[redacted]’ account has been compromised. We have temporarily suspended your website to protect your website visitors from getting impacted and also preventing the impact on your website reputation as well as our server’s reputation.

We have uploaded a file ‘websitescan.txt’ within the stats directory of your account which contains the full list of infected files. We need you to take one of two actions suggested below:

Please follow the steps given below to remove the infected contents on your own:
1. Open the ‘websitescan.txt’ file through your FileManager (OR use ‘FTP’ software like FileZilla).
2. Clean or remove each of the listed files.
3. You can also upload a clean copy of web files from your local backup.

Alternatively, we encourage you to contact our preferred partner, SiteLock. In addition to long-term solutions like their Fix and Prevent products, which offer daily scans and removal of malware, SiteLock also provides an emergency service, SiteLock 911. You can call our dedicated SiteLock support representatives using the Toll Free number (United States and Canada customers only): (855) 378 6200. International: +1 415 390-2500. To learn more about SiteLock, please go to:

So in that email they recommend simply cleaning/removing or replacing the files they identified.

When they refer to SiteLock as their preferred partner what they really mean they are getting paid a lot of money to push their services (SiteLock’s owners also happen to run Endurance International Group).

In a follow up email they had these recommendations:

Please remove the malicious contents or replace the infected files with a clean copy of web files from your local backup.

Our best recommendation is to completely remove all the files from the account and restore the contents from a known clean backup. An alternative would be going through a company such as SiteLock to clean and secure all scripts. If this isn’t done and the malicious files that are found through scanning are simply removed, the vulnerability will still exist and you will encounter the files again and again.

Those two paragraphs seem to conflict with each other as the second one states that if “the malicious files that are found through scanning are simply removed, the vulnerability will still exist and you will encounter the files again and again”, but the first paragraph and the first email suggest doing just that.

The larger problem with this is that whether you were to “completely remove all the files from the account and restore the contents from a known clean backup” or remove the indicated files that isn’t going to resolve the vulnerability. The malicious code in files on the website had to get there somehow, so there must be something that allowed that and you would need to fix that. To be sure you had fixed it, instead of just guessing that you had, you would need to figure out how the website was hacked in the first place. Nowhere in the emails do they suggest doing those things and those are things their “preferred partner” SiteLock usually doesn’t do based on everything we have seen with them.