The Reality Behind Praise for a Hack Cleanup Done by SiteLock

In dealing with hacked websites, we are often brought in to redo hack cleanups after another company has done a cleanup and the website gets hacked again. That isn’t necessarily the fault of the company doing the cleanup, but what we have found is that with those websites the company doing the previously cleanup almost always has unintentionally or intentionally cut corners.

The first thing we ask when it is brought up that there was a previous cleanup is if it was determined how the website was hacked. The answer is almost universally that determining how the website was hacked never even came up. Not only is doing that one of the three basic components of a proper cleanup, but if that isn’t done then you have no way of knowing if the vulnerability that allowed the website to be hacked still exists or not and therefore if the website is still vulnerable.

Even after finding out the company that did the previous cleanup didn’t do things right and having to hire us to re-clean the website we have had people say that the previous company did a good job. It is based on things like that, which leads us to believe that positive comments about companies providing security services are often not all that reliable.

A recent example of that type of issue involves frequent topic of this blog, SiteLock. Here was recent tweet from one of their customers:

It sounds like they did a good job, right?

SiteLock then thanked them:

When we first went to look at the website to see if it looked like it been properly cleaned and secured after seeing these tweets, the website was down due to the web host having restricted access to it (a web host that is run by the owners of SiteLock). As of now this is what you get when visiting it:

You don’t have to be a security expert to see that the hack hasn’t been resolved. Beyond what you can see there, which is “hacked by” message and an otherwise empty website, the website is still running an outdated version of WordPress, 4.5.9.

Based on our experience dealing with people who have been customers of SiteLock this poor result isn’t some outlier from an otherwise high quality provider of hack cleanups.

Mr.ToKeiChun69 Defacement Campaign Seems to Be Targeting Websites Hosted with Endurance International Group (EIG) Brands

Yesterday we were contacted by someone looking for second opinion as to whether the web security company SiteLock’s claim that their website contained malware was true. The website’s owner believed that their web host BlueHost and SiteLock might be trying to scam them.

In the case of this website it wasn’t hard to determine that the website was hacked, as this is what was shown on the homepage:

That type of hack is referred to as a defacement hack.

By malware, that may have been what SiteLock was referring to because as we found while previously giving someone a second opinion, for some reason SiteLock labels evidence of a defacement hack as malware (that seems to be a general issue, as they also labeled a spam link that way as well).

After we let website’s owner know that unfortunately the website was hacked, they responded that they felt it was an inside job. We didn’t believe that to be the case, but instead of just saying that was unlikely, we wanted to be able to provide more concrete evidence.

One way to do that would be to find some other websites hit with same defacement that were not hosted with the same web hosting company or another one partnered with SiteLock. When we did a search on Google for “Mr.ToKeiChun69” the first result was a page documenting defacements by Mr.ToKeiChun69 on the web site, which documents defacements of websites.

In looking at some of the websites that had been defaced by Mr.ToKeiChun69 we found that they all were hosted by web hosting brands owned by the Endurance International Group (EIG). Their brands include BlueHost, as well as A Small Orange, FatCow, HostGator, iPage, IPOWER, JustHost, and quite a few others. SiteLock has a “security partnership” with EIG where SiteLock pays EIG a majority of the fees from services sold through the partnership. The majority owners of SiteLock also run EIG.

While that might lead some to see the worst case, that this was inside job, for us it didn’t. But it did seem rather odd that all the websites would be at one web hosting company and that was possibly an indication that the company has some security problem.

To better understand if there was really a correlation between the web hosting provider and these defacements we did a more thorough check of where the defaced websites were hosted. We checked the first ten websites listed on the 1st, 11th, 21st, 31st, and 41st page of results for this defacement on That checked websites that are dated on there as far back as June 29.

Below are the results. We have listed each domain name, the IP address it currently is hosted on, and finally the ISP listed for that IP address or the web host. The ISP is connected to HostGator and Unified Layer is connected to BlueHost, though the websites might be hosted with other EIG brands.

Page 1

  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (

Page 11

  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (

Page 21

  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (

Page 31

  • (Unified Layer)
  • (Unified Layer)
  • (Unified Layer)
  • (
  • (
  • (
  • (
  • (
  • (
  • (

Page 41

  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (
  • (A2 Hosting)
  • (

With 49 of the 50 websites currently being hosted with EIG that would certainly seem to point to there is some correlation between the web host and the hackings. As with something that doesn’t have a connection to a web host, you would expect to see a fair amount of different web hosts showing up with that many websites.

So what about the one website that isn’t currently hosted with EIG? It turns out it was hosted with them at the time it was defaced. The IP address of the website on June 29 according to was, which is one connected to HostGator. The records for the domain name were changed on July 4, which is probably when the web hosting was changed.

We don’t know what the cause of this is. It could be that the person or persons behind the Mr.ToKeiChun69 defacements is only targeting EIG hosted websites, has been unsuccessful in targeting websites at other web hosts, or only notifying of websites hosted with EIG. What would seem more likely is that they are taking advantage of some security issue in EIG’s systems.

To be clear we don’t think that this is an inside job.

We notified the person that contacted us about the correlation, which they hopefully will pass along to BlueHost.

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.

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 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.

Sucuri Claimed Customer’s Website Was Clean Despite It Comprising Credit Card Info Entered on It

Back in June of 2012 we wrote a post mentioning that looking at false positives produced by a malware scanner would give an idea of the quality of the scanner. In that post we looked at a rather bad false positive from web security company Sucuri’s scanner. Moving forward nearly five years it is clear that Sucuri hasn’t improved the quality of their scanner as a month ago we looked at them falsely claiming our website was defaced because we have a page named “Hacked Website Cleanup”. When your scanner is that bad, it doesn’t seem all together surprising that it would manage to miss things that it should catch as well and a recent situation we were brought in to deal with confirmed that. But much worse, it also reconfirmed everything we have seen in the past that Sucuri is company that either really doesn’t have much clue about what they are doing or doesn’t care to do things right, and in this situation that lead to people’s credit card information being compromised.

A week after we wrote the post about Sucuri falsely labeling our website as being defaced we were contacted by someone with Magento website that was having credit card information entered on it compromised. Sucuri, who they had brought on while before to deal with the situation, was telling them that website was clean, despite the compromises continuing to happen. Since that claim that the website was clean was pretty clearly not true, the person behind the website was then looking for someone competent to properly resolve the situation.

If credit card information is being compromised when entered on a website, the default assumption should be that the website is hacked. About the only other possibility we can think of is if the payment processor is compromised (which is lot less likely). So upon believing it was clean, Sucuri should have realized they were missing something and figured out what they were doing wrong, but they didn’t.

One of the questions we asked about the situation right after being contacted was who is the payment processor, if it was a major one then the payment processor could be ruled out as the source. It was a major one.

At that point we assumed that code causing the credit card info must be well hidden seeing as Sucuri couldn’t find anything. But after getting the response about the payment processor, we did quick check of the website from the outside and we immediately ran across part of the problem. It wasn’t even detected using any highly advanced proprietary technology, but off the shelf tools.

What we noticed was that there was JavaScript being loaded from the domain through this script tag:

That was clearly meant to look like it was loading some type of tracking code.

The code in the file being loaded from that was highly obfuscated (when we ran through a tool to deobfuscate it, all it could pull out is that the code was requesting another file that was an encryption library for JavaScript):

At that point, considering the code didn’t look legitimate, instead of spending a lot of time trying to get a more complete deobfuscation before moving forward, we did a few other quick checks to try to assess the legitimacy of the domain the code was being loaded from.

First, we tried to trace where the server the domain was hosted on was, but found that it traced back to Cloudflare, which could have pointed to this being legitimate or it could have been someone with malicious intentions protecting themselves through Cloudflare (which is apparently a fairly common thing).

Second, we looked at the domain name registration, which didn’t look all that suspicious, but the domain was only registered on March 17.

Finally we tried to take a look at the website, but we found that there was nothing served at or There also was nothing that came up for it in a Google search.

At that point we could safely say that this was at least part of problem. At the same time we noticed that despite something fairly obviously malicious being on the website Sucuri was telling the public the opposite about the website, as the website had this badge claiming it was “Secured by Sucuri” at the bottom:

Clicking that brought up this:

Not only did they claim the website was clean, but that their service “provides peace of mind that the website is not infected”, despite that not being true.

After we got access to the logins, we found that script tag shown earlier was stored in Magento’s settings in the database (as shown from phpMyAdmin):


This turned out to not be the only fairly hard to miss portion of the hack that Sucuri missed. In the root directory of the website was the backdoor script that the hacker was using to take actions on the website. That was something that Sucuri should have noticed at multiple points. Those points being during a visual inspection of the filesystem (since you need to get an understanding of what all is part of the website when first assessing the situation), during the reviewing the website files for malicious code (it wasn’t something that was obfuscated in a way that would make detection difficult), and when reviewing the log files to try to determine the source of the hack. In looking at the logs we found that the backdoor script had most recently been accessed two days after was registered.

The backdoor script looks like it might have been on the website for nearly a couple of years, so we were not able to say what was the source of that was, but continued reviewing of the logs files showed that after it was removed and the various logins changed the hacker no longer had access to the website. So getting this resolved was rather simple for a competent company, which this incident shows Sucuri is far from.

Correlation is Not Causation When It Comes to the Source of Website Hackings

One of the reasons we are so critical of web security companies spreading falsehoods about security is that even without running into that people whose websites have been hacked often believe things that are wrong about the situation. This makes it harder to get the hacking properly resolved because either they are trying to deal with it in ways that don’t have any impact or they want someone else to do those things for them. Often times most of time spent communicating with clients with hacked websites is trying to clear up misconceptions, whether of the clients own creation or something coming from another security company. In some cases people are so convinced with these falsehoods that they are not interested in having the websites properly cleaned up, which leaves the website vulnerable going forward.

One common issue we run into is people believing whatever was the last action they took related to the website before they noticed it was hacked was the cause of the hack. As an example of this, we recently had someone contact us that in all likelihood had been hacked due to their running an outdated version of WordPress, 4.7.1, which has a vulnerability that allowed posts to be modified by anyone. Exploitation of that vulnerability is usually easily fixed by simply updating WordPress and reverting the posts back to an older revision. At the point they had contacted us they had already done those things, so there wasn’t really anything more that likely needed to be done. When we let them know that, they responded that:

Thanks, but the hack date is the same day we installed this plugin, which is kind of weird.   Anti-Malware Security and Brute-Force Firewall

What are the chances that installing a security plugin with 100,000+ active installs would cause such a hack? Probably close to none, but despite that, this person made that connection (that isn’t a knock on them as this type of thing comes up frequently).

The further problem we often find with this type of assumed correlation is that the correlation doesn’t actually exist, as the website was hacked not when the website’s owner became aware of it being hacked, but at some earlier time.

Finding the Real Source of the Hacking

The best bet for finding out how a website was hacked is probably to hire a company that does proper hack cleanups, which includes trying to determine how the website was hacked. Even when hiring someone that does that (like us) often times it cannot be determined with certainty how the website was hacked, as important evidence, usually log files, is gone by the time the website is being cleaned up. In that case someone that deals with lots of websites should still be able to make a fairly good educated guess as to how the website was hacked based on the remaining evidence, the particulars of the situation, and how that compares to other hacked websites they have dealt with where it was possible to make a more definitive determination as to the source.

Even if the source of the hack is not able to be determined we have found that doing the work needed to try to do that helps to make sure the website is fully cleaned. It can also help to make sure the source can be determined if the vulnerability stills exists and gets exploited again after the website has been cleaned up.

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.

WP Fix It Markets Their WordPress Infection Malware Virus Removal Service With Falsehoods

Of the people that hire us to clean up their hacked website maybe close to half of them bring up the fact that they previously hired someone else to clean up the website and then it got hacked again. While that is not always the previous cleaner’s fault, it appears that a lot of it can be explained by the fact that most companies doing hack cleanups either don’t know what they even should be doing or they are intentionally cutting corners.

The first thing we always after the client mentions that someone had previous cleaned things up, is whether they determined how the website was hacked. The answer is almost universally that trying to do that never even came up. That is despite that being one of the three main components of a proper hack cleanup. If you don’t do that then it is entirely possible that the vulnerability may still exist on the website, leaving the website open to being hacked again. If you are lucking after getting a subpar cleanup, the vulnerability might have been fixed without it being determined first or no one tries to exploit the vulnerability again on the website and you don’t get hacked again. If you are less lucky then you quickly end up with a hacked website again.

If you don’t want to have hire multiple companies to finally get your website cleaned you should make the sure company you are hiring in the first place actually does try to determine how the website was hacked and does the other component of a proper cleanup that we see frequently is not done, securing the website, which usually mainly involves getting the software on the website up to date.

Beyond doing that there are plenty of other red flags that a company is probably one you should avoid. To give an example of that, let’s take a look at one company we ran across recently that has service promoted with a lot of red flags. WP Fix It’s WordPress Infection Malware Virus Removal service ( Below we look at a number of those, first quoting from their marketing materials and then discussing why it should be a red flag.

A Security Plugin Won’t Safe Guard Your Website Against Future Attack

Security Enhancements

It is critical that you have security in place at all times. Our Infection Specialist will complete the highest level of protection by installing a tried and trusted security plugin which will safe guard your site against future attacks.

While you can find a multitude of review and recommendations when it comes to WordPress security plugins what you won’t find almost any of is actually testing of these plugins to see if they can actual protect against vulnerabilities. In fact other than the testing we have been doing through our Plugin Vulnerabilities service, we only have found one other instance of someone doing that type of testing. The lack of that is a reminder of the lack of seriousness when it comes to most people claiming to be interested in the security of WordPress.

What isn’t an explanation for the lack of testing is that the plugins provide such great protection that testing to see if they don’t provide protection isn’t needed. Take for example a vulnerability we just tested them against last week. Recently the security NinTechNet discovered that the plugin Delete All Comments had an arbitrary file upload vulnerability, which allows hackers to upload malicious files to website and then do almost anything they want on the website. They discovered that while doing a hack cleanup. Since the vulnerability exists in the current version of the plugin, if they hadn’t determined that, then that website would have remained vulnerable even if the software on the website was brought up to date and would have been open to being hacked again. The plugin recently had 30,000+ active installs according to, so there are lot of websites that are currently vulnerable and this is where a security plugin could be useful. Unfortunately in our testing none of the 15 plugins we tested stop the vulnerability from being exploited.

Through the four tests we have done so far, most of the plugins we have tested have provided no protection whatsoever. Of the few instances where there was some protection, in all but one of them we found that the protection could be easily bypassed. The one time that we didn’t find a bypass there was a major tradeoff to get the protection, only Administrators level users were allowed to upload files. On a lot of websites where there is a single WordPress account that isn’t an issue, but for other websites lower level users are blocked from uploading media files would be an unacceptable limitation.

While WP Fix Its claim doesn’t specify what the plugin they install “will safe guard your site against future attacks” is, one review of their service from September indicates that it is Sucuri Security. In our testing that plugins has not provided any protection, which isn’t really surprising since it doesn’t even look to have any features that would prevent the vast majority of hacks. So you either have a situation where WP Fix It doesn’t have any clue as to whether the plugin can do what they claim or they are lying about what it can do, neither of which seems like something that you would want in someone doing a hack cleanup.

Brute Force Attacks Are Not Happening

Brute Force Attack Prevention

A common attack point on WordPress is to hammer the wp-login.php file over and over until they get in or the server dies. Each tried attempt is a request to the server which slows things down. Our Infection Specialist will guard your site against this.

When it comes to glaringly bad information about WordPress security the false claim that there are a lot of attempts to brute force WordPress admin passwords is probably the most widespread. As we discussed back in August, the evidence provided by security companies actual shows that these attacks are not happening. If you see someone claiming that they are they are, the either don’t understand security or they are lying to you. What does occur in some instances our dictionary attacks, which involve an attacker trying to log in using common passwords. As long as you are using a strong password these are not a threat to you. Unless you are an overloaded server they also shouldn’t cause the server to die or cause a noticeable slowdown.

Security Companies Can’t Speed Up Getting Security Warnings Removed

Blacklist Removal

Some infections may trigger a blacklist of your website online. This means that when people try to visit your site they are warned that the content in harmful and urges them not to proceed. We will take the needed steps to remove all these warnings right away and allow visitors to surf your site without issues.

Getting Google or someone else’s malware or hack warning removed for your website is usually a fully automated process, which is easy to request and which a security company has no control over how long it takes. Where a security company can probably best help out, if they handle a lot of these, is with understanding why the review is taking so long or the odd information being returned during that, as we have found with Google’s warning that “This site may be hacked”. Of course if they mentioned that, they would also be disclosing that the warning doesn’t always get removed “right away” as this company claims and they don’t have any ability to control that timing.

Unrelated Work Isn’t A Sign of Competency

Database Optimization & Cleanup

Your database is the sweet spot of all your saved website content and data. Over time databases can become very bloated storing tons of information that you site does not need anymore. Our Infection Specialist will optimize your entire database.

Optimizing a database has nothing to do with a hack cleanup, even if the small percentage of hacks that involve the hacker making some change to the database, so it is really odd that they would doing that during hack cleanup.

A Low Quality Cleanup

Based on all that it doesn’t look these guys have much security knowledge, so you might wonder how they can actually handle doing a cleanup. The answer it seems is that they are not actually doing much themselves, in one of their blog posts ( they include steps to do a cleanup, which at the end they stat “We also can do all this for you”, and they actually detection of malicious code is done by the plugin Anti-Malware Security and Brute-Force Firewall. Our experience is that automated detection like this is able to spot some malicious code, but won’t get better hidden stuff, so relying on something like that isn’t going to provide the best cleanup.

Joomla Firewalls Are Not a Replacement For Properly Cleaning Up a Hacked Website

When it comes to the security of websites what we often see is that a lot of focus is add-on security products instead of focusing on doing the basics. The reality is doing the basics is going to do a lot more to protect you than any security products. As an example, over at our Plugin Vulnerabilities service we recently tested 11 WordPress security plugin against a very exploitable vulnerability in a plugin and found that only 2 of the plugins provided any protection and for those two we easily found a way to bypass them. By comparison, simply updating the plugin after the vulnerability was fixed would protect you from the vulnerability.

This type of wisdom recently came up in the context of a hacked Joomla website we brought in to clean up. We were originally contacted by someone involved with the website about the following warning they were receiving on the website from Chrome warning that “The site ahead contains malware”:

This site ahead contains malware

The warning referred to another website, so they were not sure if it was due to their website being hacked or if maybe the other website was hosted on the same server and being on the same server was causing the warning. The reason the warning mentioned another website was that it was a cross-site warning, which is shown when content is loaded from another website that is being flagged by Google for malware. In this case it was caused by the following malicious JavaScript code that was being included on the website’s pages:


We explained them what was going on (if you have a question related to a possible hacked website we are always available for free consultation to discuss it) and then we were brought in to clean up the website.

The JavaScript code shown before was easy to find because it stored in the index.php of the various templates on the website, without any obfuscation.

One of the next steps in the cleanup was determining how the code got on the website. While determining how a website is hacked is one of three important pieces of a proper hack cleanup, many, maybe most, companies doing hack cleanups don’t do this. Not to surprisingly the website where that doesn’t happen often get hacked again, and we are often brought in at that point to re-clean it.

What looked to be the cause of the malicious JavaScript code being added to the template files was a POST request to the file /libraries/fof/integration/joomla/general24.php. While that directory is one for core Joomla files, that file isn’t. Instead it was file a hacker had placed on the website at some point before, based on the last modified date it would appear it was placed there three months before. The logging doesn’t go back that far so we were unable to see how that file had been added to the website.

That was not the only malicious file on the website. One of the easiest to spot was one in the root directory of the installation, due to the filename, ee79bb.php, not being something you would expect to see there. There were also several malicious files that had been renamed so that could be executed. At that point we found out that website had been hacked before, but it not been cleaned in a professional manner before.

Firewall Extensions Didn’t Stop The Hacking

While the website had not been fully cleaned before, two firewalls had been added, RSFirewall! and the firewall that is part of Admin Tools. Neither of those protected against the request sent to the general24.php file or based on their logging look to have had any impact as a number of other malicious look to have been added on the website over a period of months. That isn’t necessarily their fault, as once a hacker has some access it is much harder to detect that the requests are malicious in nature, but it is a reminder that security add-ons are not a replacement for proper security practices.

It is worth noting that with both RSFirewall! and the firewall that is part of Admin Tools, bold claims are made to their security capability with being backed up by and evidence. For RSFirewall! is describe thusly:

RSFirewall! is the most advanced Joomla! security service that you can use to protect your Joomla! website from intrusions and hacker attacks. RSFirewall! is backed up by a team of experts that are trained to be always up to date with the latest known vulnerabilities and security updates.

Nowhere is there anything that actually backs up those claims. Also troubling is the fact that it boasts protection against brute force attacks, despite those not actually happening.

Admin Tools firewall is describe in somewhat less bold way:

Our Web Application Firewall protects your site against the vast majority of common attacks. You won’t find any security tool more feature-complete than this.

But again, nowhere is there anything that actually backs up those claims.