Is SiteLock Providing Their Customers Access to All Accounts on GoDaddy Servers?

In looking over complaints about the web security company SiteLock a lot of things come up over and over, take for instance the end of a review of them from earlier this month at the website ConsumerAffairs:

Worst case scenario: a site will become infected with malware. Again, I get the auto-email with no clue to which site is infected. You have to upgrade your account to get it cleaned and then it never stays clean. It continues to get infected every few months and they do nothing to help you prevent or fix it. The one site that I’ve had this happen to, I ended up upgraded to the manual clean & monitoring service. Instead of them cleaning it when it happens, they send that email (you know the one, without any clue as to which domain it is referring) and then I have to call them to request it to be manually cleaned. AGAIN. They don’t just automatically do it, like the service implies. I cannot tell you what a frustrating phone call it is. They have no email or chat support and you are stuck to a phone call with someone who is trying to earn commission and has no interest in supporting you. DON’T USE THEM.

A lot of that isn’t surprising if you follow our blog, as we have discussed that usually when you get in contact with SiteLock you are dealing with a commissioned sales person (and how that looks to lead to untrue information being told to potential customers), the fact they cut corners when doing cleanups and leave websites insecure. It could actually have been worse as this review involved websites hosted at GoDaddy and we have previously discussed instances where websites cleaned through their partnership with SiteLock have left the websites broken.

What was new in this review was the claim of the prior paragraph of the review:

Once I find the account with the issue to reconnect, it is an absolute nightmare to do so. You have to enter the FTP info, then sift through EVERY SINGLE Godaddy site on the server to find yours (I’m not kidding, and I’m sure you can imagine there are a lot of sites on Godaddy’s server – why I have access to every single one of them via SiteLock seems like a security issue in itself). It’s an extremely tedious, SLOW and frustrating process.

It isn’t clear what level of access they are referring to there and what could be done with it, but there shouldn’t be any access to unrelated accounts at all (especially through a security service).

If you have more information on what access they are providing through that please leave a comment on this post or get in touch with us.

SiteLock and Bluehost Falsely Claimed a Website Contained Malware Due to SiteLock’s Poor Scanner

When it comes to the web security company SiteLock, one of the frequent complaints is that they and their web hosting partners falsely claim that websites have malware on them. After that happens the web hosting company frequently suspends access to the website and pushes the customer to hire SiteLock to clean up not existent malware. We thought it would be useful to look at an example of this we were recently consulted on, as those dealing with the possibility of a false claim should know a number of things when dealing with it.

This situation involved the web host Bluehost. Bluehost is one of many brands the company Endurance International Group (EIG) does business under. Some other major ones are A Small Orange, FatCow, HostGator, iPage,  IPOWER, and JustHost. The company’s web hosting brands are very open about having a partnership with SiteLock, what they have, at least in the past, refused to acknowledge publicly is that partnership involves EIG getting 55 percent of revenue for SiteLock services sold through that partnership (that information was disclosed to investors). That obviously raises some serious questions and it probably explains in large part a lot of the problems that arise from that partnership. What they also don’t disclose to their customers is that the majority owners of SiteLock are also a member of the board and the CEO of EIG, so they are well aware of SiteLock’s practices.

What we have repeatedly said is that if you get contacted by SiteLock or one of their web hosting partners claiming that the website is infected or otherwise is hacked, is that should not ignore it. While there are plenty of situations like the one discussed here where there is a false claim, the claim is also often true. For a hacked website, the longer you wait to do properly clean it up, the bigger the problem can be. Instead we recommend that you first get any information that SiteLock and or the web host will provide and then get a second opinion as to whether the website is hacked. We are always happy to provide that and we would hope that other security companies would as well (when someone contacts us about a hacked website we always make sure it is actually hacked before taking on a cleanup).

One of the reasons for getting a second opinion is that someone familiar with hacked websites should understand how to easily check the validity of the claims made. While someone not familiar with the situation might try doing checks that won’t necessarily be very useful. In this situation one the things the website’s owner did was to download a copy of the website’s files and run them through a malware scanner. That likely is going to fail to identify many files that contain malicious code because a malware scanner for a computer isn’t designed to detect those files (our experience is that scanners designed to scan website files don’t produce great results either).

When we were provided the information that the website’s owner had received, the first element that caught our eye was this result of SiteLock’s malware scanner:

What was shown was rather odd as the malware scanner claimed to have detected a defacement hack (labeled as “SiteLock-PHP-HACKEDBY-klw”), which isn’t malware. So at best the scanner was incorrectly labeling a hacked website as containing malware, when it had a different issue.

More problematic is that it looks like they might are flagging websites as being defaced just because they have text that says “hacked by” something. That could produce some rather bad false positives, since this post itself could be claimed to contain malware simply by using that phrase. They also mark that detection as having a severity of “Urgent”, despite that.

So was the website defaced as that scan seemed to indicate? The website was taken down by the point we were contacted, which wouldn’t need to be done just because there was a defacement and makes it harder for someone else to check over things (whether intentional or not, it seems like something that makes it easier to push someone to hire SiteLock to resolve the issue). Looking at the Google cache of the website’s homepage though, we were able to see what happened.

The website’s page contains a section that shows RSS feeds items from other websites. One of those websites had been impacted by a vulnerability in outdated versions of WordPress that allowed defacing posts and the results of that defacement was showing on this website:

That “hacked by” text on showing there didn’t mean this website was infected with malware or otherwise hacked and the website didn’t pose any threat. That is something that anyone from Bluehost or SiteLock familiar with hacked websites should have spotted by looking over the website for a few seconds, but clearly that didn’t happen, even when they suspended access to the website. Both of them have an incentive to not check to make sure the website is hacked, since they have monetary interest in selling security services in this situation even though they are not needed. As we mentioned recently it appears that when you are in contact with SiteLock you are dealing with a commissioned sales person, not a technical person, so they might not even understand what is actually going on either (one situation we looked at recently would strongly seem to indicate that as a possibility).

Looking at the files that Bluehost had listed as being infected, they were just cached copies of the content from the website that had the RSS feed section in them. So there wasn’t any malware in them.

It also seems that no one from Bluehost or SiteLock bothered to contact the other website to let them know that there website was actually hacked, seeing as it was quickly fixed after we notified them of the issue they had.

At this point the website’s owner is planning to move to a new web host, which doesn’t seem like a bad idea (we think that people should avoid web hosts that have partnered with SiteLock even if they have yet to run into this type of situation).

Trend Micro Thinks Their Continued Failure to Take a Basic Security Measure Shouldn’t Define Them

Back in May of last year we noted that cyber security company Trend Micro was failing to keep the installation of WordPress on their blog up to date. What stuck out about this was that this shouldn’t have happened, as WordPress has an automatic background update feature that would normally have done the updates without requiring any interaction by someone at Trend Micro. So either there was some incompatibility between their hosting environment and that feature or they unwisely disabled the feature without making sure to promptly do the updates manually instead. If it was the former, then they could have probably helped not only themselves, but others by working with WordPress to fix the cause of those updates not occurring.

Fast forward to last week where it was reported that another one of their blogs was attacked due to a vulnerability in WordPress that would have not been possible to exploit on the website if they either had gotten automatic background updates working or if they had started promptly updating manually.

The response from the company’s “Global head of security research” makes it sound like the company has no idea what they are doing:

“We got reports from many researchers, regarding attacks using this vector and we deployed a custom policy to block the attacks,” he explained.

“Unfortunately there are many different URLs attackers can use to carry out the same attack, so a couple of fake ‘articles’ ended up posted on CounterMeasures. We have responded and shut down the vulnerability completely to resolve the issue

“Just serves to demonstrate something that I have often repeated in presentations, we are all a potential victim of digital attacks and we can’t afford to take our eyes off the ball at any time. The best way to respond to any attack of this nature is with honesty and alacrity, and that’s what we have endeavoured to do.

“Of course technology and best practice can mitigate the vast majority of intrusion attempts, but when one is successful, even one as low-level as this, you are more defined by how you respond than you are by the fact that it happened.”

The really simple solution to prevent this vulnerability from being exploited is to make sure you updated from WordPress 4.7.0 or 4.7.1 to 4.7.2, but there is no mention of that. Instead they make some mention of a “custom policy to block the attacks”, which is not necessary if you just updated to 4.7.2.

Amazingly as of this morning the blog is still running WordPress 4.7.1, as can easily be seen by viewing the source code any page on it:

The main Trend Micro blog doesn’t contain a meta generator tag, which makes it easy to spot what version is in use, but if you look at the CSS and JavaScript files being loaded on it you can see repeated use of “4.7.1” in the URLs, which tells you it is also on WordPress 4.7.1:

Defining Trend Micro by their response to getting attacked rather than their failure to take best practices doesn’t seem to make things better here, since they still have failed to properly respond to the situation by updating WordPress. Since they can’t handle the basics, you really would have to wonder about their handling of more serious things. Or you would if the wasn’t already evidence they can’t.


SiteLock Review Shows the Problem of Relying on Customer Reviews To Determine Quality of Security Companies

We have frequently mentioned the fact that many security companies don’t know and or care much about security. That not surprisingly leaves the public with a lot of bad options when they are looking for someone with security expertise to help them deal with a hacked website or other security issues. So how can they find one of the few companies that don’t fall in to one of those categories? We don’t know of an easy way, but we do know that looking at customer reviews of security companies isn’t a good way to do that.

We frequently are brought in to re-clean hacked websites after another company had been brought in to do that. While that isn’t always the company’s fault, we have found that in almost every instance the company doing the cleanup either didn’t know what they were doing or intentionally cut corners. We know that because we always ask in these instances if the previous company had determined how the website was hacked (since if the vulnerability hasn’t been determined and fixed it would leave the website open to being hacked again), and the response is almost always that trying to determine how the website never even came up. Considering that is one of three main components of a proper hack cleanup, that shouldn’t be the case. In more than a few cases even at that point the person we are dealing with said that the previous company did a good job, which doesn’t seem accurate considering they didn’t do things properly and the website was hacked again. If people think they did a good job at that point, we would assume that even more would have said that right after the original work was completed.

To give you another example of this we thought something we ran across involving web security SiteLock is worth highlighting. Here is a review of SiteLock from August of last year that comes from the BBB page for them:

Sitelock has been a great and affordable toll to achieve… security challenges, and enabled to offer our visitors peace of mind. In one and only incident in 2012, Sitelock emailed us as soon as they detected that some malicious software had infiltrated our comment pages…they quickly deleted all malicious code.

The problem with that review is that the website isn’t actually secure and hasn’t been secure for some time. The website is running Joomla 1.5, for which supported ended in September of 2012, over four years ago.

You wouldn’t know that if you were to believe SiteLock, as of today they are claiming it is secure:

It would be easy for SiteLock to determine that the website was running outdated software and isn’t secure, as the source code of each page on the website contains the following line:

<meta name=”generatorcontent=”Joomla! 1.5 – Open Source Content Management” />

So the review’s claim that SiteLock services “offer our visitors peace of mind” is true, but it is because SiteLock is not telling the website’s visitors the truth.

Considering that SiteLock missed such an easy to spot issue, it isn’t hard to believe they might also miss more serious issues, and in fact our past experience shows that it isn’t a theoretical issue. So while the review is positive, the underlying reality is the opposite.

Considering that customers of security services are hiring them in the first place, it isn’t likely that many reviews come from someone who would actually be aware of a failure like SiteLock’s here, so many other reviews of them are probably unintentionally misleading others as well.

Unreliable Claim That 1.5 Million WordPress Pages Defaced Is Reminder of the Terribleness of Security Companies/Journalists

In the last day there have been quite a few security journalists writing articles claiming that 1.5 million pages on WordPress websites have been defaced due to a vulnerability that existed in WordPress 4.7.0 and 4.7.1. In looking over those articles we have found that in some cases the claim isn’t actually sourced at all and what appears be the original source for the figure in the others, which came from a security company, isn’t reliable at all and that the journalists ignored a huge red flag that should have warned them that the claimed figure and the source of should not have been relied on.

First let’s look at a couple of the articles with unsourced claims. The Inquirer’s article is titled “WordPress hacking spree sees 1.5 million web pages defaced“; nowhere in the article is a citation for that claim provided. The closest the article gets is this:

According to a report on the BBCthere are millions of pages that have already been defaced thanks to the vulnerability.

In that BBC article the claim is not sourced either:

One estimate suggests more than 1.5 million pages on blogs have been defaced.

In ITworld’s article “Recent WordPress vulnerability used to deface 1.5 million pages” you get a source, but no explanation as to how the number was calculated, which seems like important information to provide:

Since then the number of defaced pages has grown to over 1.5 million and there are 20 different attack signatures, according to statistics from Feedjit, the company behind the Wordfence security plug-in for WordPress. The number of unique affected websites is estimated at around 40,000, as a site can have multiple defaced pages.

Also worth noting here is that there is an estimate of the number of websites impacted, which seems to be the more relevant number to be the headline number, assuming either was accurate. We don’t think there is much question as to why they went with the pages number, with the current state of security journalism click-baitness is more important than providing high quality reporting.

The Bleeping Computer’s article, “Attacks on WordPress Sites Intensify as Hackers Deface Over 1.5 Million Pages” cites nearly identical numbers as to the number of pages and websites:

Attacks on WordPress sites using a vulnerability in the REST API, patched in WordPress version 4.7.2, have intensified over the past two days, as attackers have now defaced over 1.5 million pages, spread across 39,000 unique domains.

It also looks like they are citing Wordfence for their number of web pages defaced as well:

The number grew to over 100,000 pages the next day, but according to a report from fellow web security firm WordFence, these numbers have skyrocketed today to over 1.5 million pages, as there are now 20 hacking groups involved in a defacement turf war.

When you look at Wordfence’s post the claim of 1.5 million pages is based on Google’s estimate of how many pages contain certain “hacked by” phrases:

On the far right we also include the number of defaced pages for each campaign, according to this morning’s Google results.

Are those reliable? The answer seems to be no. Here is how a BBC article from 2012, “Are search engine result figures accurate?“, starts out:

Enter the name Tim Harford into Google and you get 835,000 results.

Or 325,000, or 285,000… I got these widely differing results on computers within metres of each other in the same office at the same time.

So using those as headline number and not disclosing that it is the source (along with a disclaimer as to the questionable accuracy) seems quite inappropriate. It gets worse though, because in Wordfence’s post they take this misleading number and stretch in even further. In their chart they labeled the 1.5 million page estimate as being the number of “Hacked Sites”, not web pages:

That seems like the sort of thing that should have warned journalists away from that, but security journalists don’t seem to care much for accuracy.

The 39,000 unique domains or around 40,000 websites figure also looks to come from the same chart. The problem that appears to be a measure of websites where Wordfence saw an attempt to exploit this on, not the number of websites hacked:

Considering that any WordPress websites running 4.7.1 when 4.7.2 was released would have been automatically updated to 4.7.2 and protected against the exploit long before the attacks started, unless the automatic updates feature wasn’t working on the website (which we don’t see being the case with many websites) or it was disabled (which people sometimes foolishly do), the number of attacks that could have been successful was probably a small portion of the 39,000 attacked.

Unfortunately what has happened here with these inaccurate claims of the size of exploitation are all too common these days due to the poor state of security companies and security journalists.

Google Sending Out False Alerts That Websites Are Running Outdated WordPress Versions

Back in 2009 Google started notifying webmasters through their Webmasters Tools (later renamed Google Search Console) that they were running outdated software in some instances. That is good idea, but it clearly needs some work as of 2017, seeing as last night we got the following email:

Recommended WordPress update available for

To: Webmaster of,

Google has detected that your site is currently running WordPress 4.7.0 or 4.7.1, an older version of WordPress. Outdated or unpatched software can be vulnerable to hacking and malware exploits that harm potential visitors to your site. Therefore, we suggest you update the software on your site as soon as possible.

Following are one or more example URLs where we found pages that have outdated software. The list is not exhaustive.

Recommended Actions:

1 Update to the latest release of WordPress

Visit the WordPress site for instructions on how to download and install the latest release.

2 Check your site for hacked content

Because there was a vulnerability on your site, it’s possible that your site might have been compromised. We recommend you check your site for any suspicious activity. You can see if Google has detected any hacked content on your site in the Security Issues section of Search Console.

3 Stay up to date on new releases

Remember that older or unpatched software might be vulnerable to hacking or malware, so it’s important to install new software releases when they come out.

Need more help?

Read more about outdated software and vulnerabilities in our Help Center.
Check your site for hacked content using the Hacked Sites Troubleshooter.
If your site was compromised, read our guide for hacked sites.
Ask questions in our forum for more help – mention message type [WNC-641200].

Because this blog, like hopefully almost all WordPress installations, hasn’t had the automatic background updates feature disabled, it already was updated. In fact the update to 4.7.2 happened as of midday on January 26, the day the update was released. That was 11 days before the email was sent out. Seeing as we haven’t removed the meta generator tag from the blog, the version is included on every page’s source like this:

<meta name="generator" content="WordPress 4.7.2" />

Our guess would be that they are still processing pages crawled from before the update happened, which include the previous version number, and they are basing the claim of outdated software on that, which is obviously problematic.

It also worth noting that they are failing to capitalize the “p” in WordPress, instead referring to it as “WordPress”.

Minor WordPress Updates Are The Ones You Want To Make Sure Are Applied Right Away

When it comes to the security of websites one of the major problems we see is that often the basics are not being done (even by security companies), one of the most important is keeping software up to date, which prevents known vulnerabilities that have been fixed in a newer version of the software from being exploited.

Back in 2013 the developers of WordPress took a step to protect websites running WordPress from this by introducing a new updates system in WordPress 3.7 that automatically applies minor WordPress updates (the ability to have major WordPress, plugin, and theme updates also exist in that functionality). Alongside that they started releasing security updates for older major releases that have that update functionality, in the form of minor updates. So unless something causes that feature to not work or it has been intentionally disabled, any websites still running WordPress 3.7 or above would still be being protected against vulnerabilities discovered in WordPress.

As far as we are aware only the most recent major version of WordPress is officially supported, so you should be making sure you are on the latest version, but those running older major versions should still be relatively secure as long as they are on the latest minor release of that.

Disabling those automatic updates cannot be done in the settings of WordPress, so it isn’t something that could be accidentally done. Instead someone has to make an active decision to do that (by using a plugin or making a change to a file) and it would generally be a bad one. The reasons for doing that usually seem rather bad, take for example the website of WordPress security plugin where that looked to have happened, the company behind later told us that had been done because they had modified core files, which you shouldn’t be doing (that the developer of security plugin would be modifying core files like that would be concerning on its own and it probably isn’t surprising then that we later found a couple of vulnerabilities in the plugin).

That brings us to fairly widespread reports of websites that have been hacked due to not having applied the latest WordPress update (without having looked at the websites’ data and logging we can’t say how many of those claims are true and how many of those websites were hacked due to other issues). One message that showed up about this in the monitoring of the WordPress support forum we do, to keep track of vulnerabilities in plugins for our Plugin Vulnerabilities service, had a troubling explanation for not being on the latest version:

WordPress 4.7.2 was patched at some rest-api vulnerability and some other stuff according to change log. I usually checkout the change log every time whenever an update is available. This was the first time I didn’t check that and only imagined the 0.1 version difference to be a slight upgrade. But I was wrong.

While some minor updates just include bug fixes (the last one being in April of last year), most are security updates. By comparison, a major update is not likely to introduce a security fix. So the updates you want to apply right away are the minor ones or better yet don’t disabled the automatic updates, so you don’t have to worry about making this decisions. Major updates, not minor updates are the ones that have more of a chance of causing a problem (say if a plugin hasn’t been updated to be compatible with the new version).

If you are still using a very old version of WordPress on your website, you may want to have a test of the upgrade done before upgrading the production website to the latest major version so that any issues can be resolved first. Doing a test of the upgrade is included in our upgrade service for WordPress.

When You Get In Touch With SiteLock You Are Dealing With a Commissioned Sales Person

As we have found out more about the web security company SiteLock over time a lot of things that we previously heard and saw about them have come to make more sense.

One those things was we found out that is that when you get in touch with SiteLock you are likely dealing with a commissioned sales person. That seems to go a long way to explaining, for example, why when people who are already paying for SiteLock protection services get hacked that the response from SiteLock is to try to sell them additional services or even more expensive services similar to what they already have, as that person interest in selling them something, not in trying to resolve what went wrong with the protection SiteLock was supposed to be providing. That also leads to other issues, like dealing with someone that either doesn’t understand much about security, leading them to make rather ominous sounding claims, or saying things they know to be untrue to try to scare people in to spending more.

Something else we ran across recently seems to show how those commissioned sales people view potential customers, who in many cases have just had their websites hacked or  access to their website blocked based on a claim that the website is hacked (which is not always true), which seems in line with what we mentioned in the previous paragraph. In a review of the company by a salesperson on Glassdoor they said this:

If you are willing to work weekends you will make a TON of money!
My commission checks in sales range from minimum $3500-$7300.
The only company where we’ll never be able to call all the leads if we tried. So many untouched leads because the market for our product is so large.

So people who are dealing with a stressful situation are simply leads to them.

Not surprisingly with how they sell people on their services they have a lot of customers that are canceling as mentioned in another review on Glassdoor:

Company has a high churn rate with regards to customers which directly impacted bonuses of their employees. (Myself included) There were 2(back-to-back) months where our inbound sales team did not receive our commissions despite passing our monthly goal as a team entirely.

That is even though they make it rather difficult to cancel their service and even though you are apparently dealing with sales people even when you try to cancel the service.

Avoiding SiteLock

If your web host is pushing you to use SiteLock due to a claim that your website is hacked then your best bet, from everything we have seen and heard, is to simply avoid using them, as the commissioned sales people are only tip of the iceberg with the bad experience many people come away with. While they do push SiteLock, if you ask the web host they will let you know that SiteLock is not required to do the cleanup.

Seeing as your web host likely gets a majority of what you pay to SiteLock (one major web hosting company that is run by SiteLock’s owners disclosed to investors that they receive 55% of the revenue from their partnership) despite not doing the work, you are necessarily going to overpay when going with SiteLock.

For the type of low quality cleanups that we have seen them providing you can find an equivalent service from many other providers for much less than they charge and we provide a high quality cleanup that often costs less than SiteLock charges (we will first check to make sure your website is hacked, so you are not paying for an unneeded cleanup).

Be Wary of Security Companies That Don’t Allow Comments on Their Blog Posts

Last week we discussed an example how security companies’ blog posts can show that they lack the expertise they claim to have:

One way to determine if a security company actual has the abilities they claim is to look at their blog posts, since we often find those expose a lack of knowledge that can be covered for in vague marketing material.

The example we used was the security company WeWatchYourWebsite confusing a hacker trying to exploit a vulnerability that didn’t exist on a website with hackers looking for already infected websites.

We got a comment from the company, which can only be described as childish, and strangely seemed to be trying to dispute what we wrote by reiterating what we said (maybe they didn’t bother to read the post?). One element of it sticks out though:

Of course I’m certain your ego won’t allow this comment to ever show on your site.

(We did say it was childish.)

We did approve the comment, as we do with any comment that is at least vaguely related to the post being commented on. By comparison WeWatchYourWebsite doesn’t allow comments on their posts:

Does that mean they that the company has a big ego? We don’t know, but we do know that it means that people have no possibility of alerting others that what they are writing isn’t correct at the source. They are not alone in this as we have seen a number of security company that say things that are wildly inaccurate or outright false in blog posts and do not even allowing the possibility of a comment that corrects them (in other cases they don’t approve comments that don’t praise them).

If you see a company not allowing comments, it should give you second thoughts about doing business with them.

Also, you have to wonder about the kind of person that would write something that they think is so bad that they preemptively claim it won’t be approved or claim that they will be deleted.

Don’t Ignore a Message From SiteLock or Your Web Host That Your Website Has Malware

When it comes to the poor state of web security we often find that security companies play an important role in that. That includes making up threats and telling people they need to take advanced security measure, while many, including those same companies are still failing to do the basics.

Another area we have seen this involves the security company SiteLock and their web hosting partners. We have written numerous posts about SiteLock’s bad practices, one of them being that they and their web hosting partners (who get paid handsomely to push their services) sometimes falsely claim that websites contain malware or have otherwise been hacked. What we have consistently said though is that you shouldn’t assume that the website isn’t hacked and recommended getting a second opinion (something we are happy to provide for free). Unfortunately people often conflate SiteLock’s many bad practices, with the idea that any claim by them or their partnered web hosts that a website is hacked as being false.

For example, yesterday we ran across someone on Twitter claiming that Bluehost was falsely stating a website had malware on it:

We asked how them how they determined that and the answer was they hadn’t actually done that:

We then tried to explain that while there are false claims made by them and the web hosting partners, the claims are often true and suggested that they get a second opinion from a security company (and letting them know we do that for free), at that point they blocked us.

If the website did contain malware, which seems to be of decent likelihood, then their tweets help perpetuate the issue.

Ignoring the Evidence

What makes the false claims is even more problematic is that it feeds in to an existing belief that we have often seen with people assuming that claims that their website are hacked are not true, even when coming from parties that have no profit motive (like Google).

When it comes to SiteLock and their web hosting partners we see two very different scenarios.

In some cases access to the website is shut off immediately and they haven’t provide any evidence of the supposed hack that lead to that happening, which makes the claim legitimately seem questionable.

In others they actually provide evidence, which should be easily checked, but is instead ignored. Take for example, someone, also hosted with Bluehost, that contacted us recently. They had been sent the following email by their web host:

Your [redacted] account has been deactivated due to the detection
of malware. The infected files need to be cleaned or replaced with clean
copies from your backups before your account can be reactivated.

Examples: /home1/[redacted]/public_html/config.php.suspected



To thoroughly secure your account, please review the following:
* Remove unfamiliar or unused files, and repair files that have been
* Update all scripts, programs, plugins, and themes to the latest
* Research the scripts, programs, plugins, and themes you are using
and remove any with known, unresolved security vulnerabilities.
* Update the passwords for your hosting login, FTP accounts, and all
scripts/programs you are using. If you need assistance creating secure
passwords, please refer to this knowledge base article:
* Remove unused FTP accounts and all cron jobs.
* Secure the PHP configuration settings in your php.ini file.
* Update the file permissions of your files and folders to prevent
unauthorized changes.
* Secure your home computer by using an up-to-date anti-virus program.
If you’re already using one, try another program that scans for
different issues.
You may want to consider a security service, such as SiteLock, to scan
your website files and alert you if malicious content is found. Some
packages will also monitor your account for file changes and actively
remove malware if detected. Click here to see the packages we offer:

Please remove all malware and thoroughly secure your account before
contacting the Terms of Service Department to reactivate your account.
You may be asked to find a new hosting provider if your account is
deactivated three times within a 60-day period.

Thank you,

Bluehost Support
For support, go to

Over a month later they were notified by SiteLock that the website had been deactivated. Even then they didn’t look at the files that Bluehost had provided as examples of the malware infection, while questioning if they were really hacked.

When we took a look at the names of the files and their locations mentioned in that email, we noticed one of them wouldn’t normally be in that location in a Joomla website. That isn’t something we expect that the average person would know, but it does show how easy it should be for someone that has actual expertise with dealing hacked websites using the software running your website to double check the claims for you.

Looking at the content of the files, we think that even a layman would think that something was off with them. And for us it was obvious by just looking at them that they really were part of a hack and not a false positive, so we could easily confirm that the claim was actually true in this case.

Get a Free Consultation From Us

If you are have been contacted by SiteLock or a web host (whether a SiteLock partner or not) claiming your website is hacked, feel free to contact us to have a free check done to see if the website is really hacked and if it is we will provide you with a free consultation on how you can best deal with the issue.

If your web host is pushing you to use SiteLock you should be aware of a number of items before making any decisions and you should know that we can provide you with a better alternative for cleaning up the website for less money.