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.

Rudy Giuliani Not the Only Trump Advisor With a Website Using Insecure and Very Out of Date Software

Last week we discussed that the website of Rudy Giuliani’s security company was running an outdated and insecure version of Joomla. Since then the website has been taken down. What we also mentioned in that post was that it wasn’t clear what his company actually did in terms of cybersecurity. Motherboard seems to have answered that question:

Since 2003, his consulting firm Giuliani Partners and its subsidiary Giuliani Security and Safety has at least nominally advised clients on cybersecurity, but people who have worked with his firm say the advice is focused more on liability mitigation for companies rather than implementing best security practices.

“If you hired them on a cyber engagement, they are going to tell you what your legal obligations are and how to manage the legal risk related to cyber,” a cybersecurity executive in New York who has experience with Giuliani Security and Safety and requested to remain anonymous told Motherboard. “Basically, not to prevent a Target [breach], but how to prevent a Target CEO being fired.”

Considering that from everything we have seen most security companies don’t seem to know and or care much about security, this isn’t as troubling to us as it should be for others not aware of what is going on in the industry.

In an interview Mr. Giuliani did with MarketWatch from a year ago, you get more of a sense of what the industry is all about:

MW: So Giuliani Partners began penetration-testing companies — attacking from the outside to find vulnerabilities hackers may exploit — back in 2003?

RG: 2004, 2005 by the time we got started.

MW: How many clients did you have back then?

RG: Maybe 30.

MW: Did you find that anyone cared about cybersecurity back then?

RG: These were all friends of mine, friends of his. They’d give me a nice meeting and they’d look at me, and they’d look at the bill. And the bill was high, but it wasn’t high for them — $10 million, $20 million, something like that. It wasn’t like the kind of money they’re spending now. (laughs)

From what we have seen of penetration testing we have a hard time believing the underlying cost of the work was a fraction of what was spent. A lot of it involves running automated tools over systems, which largely warn you about vulnerabilities that exist in outdated software (for which the money would be better served keeping the software up to date).

The next line in the article indicates that big dollars spent doesn’t necessarily produce results:

(Note: J.P. Morgan Chase had a $250 million cybersecurity budget when it was breached in 2014; CEO Jamie Dimon said after the breach that the bank would double cybersecurity spending.)

Newt Gingrich’s Outdated Website

Considering the prominence that cybersecurity has taken in US politics you might think that would lead to prominent players taking actions to make sure they are secured (by hiring someone, not doing themselves, obviously). That isn’t the case with the website of former House Speaker and Donald Trump advisor Newt Gingrich, The website is still running WordPress 3.7:

The Gingrich Productions Website is Running WordPress Version 3.7

The next version of WordPress, 3.7.1, was released in October of 2013.

Keeping the software running a website update is a basic security measure.

What makes this a bid odd is that WordPress introduced a new update system in WordPress 3.7, which automatically applies minor WordPress updates. Along side that WordPress started releasing security updates for older versions of WordPress, so normally the website would have been getting security updates without requiring any manual intervention since then (the latest version of WordPress is still the only one official supported, so websites should still be keeping WordPress up to date with the latest major release). Seeing as the updates didn’t happen, either that feature was disabled or it had some conflict with the website’s hosting environment.

Whatever the cause, 14 security updates for WordPress 3.7 have been missed: 3.7.2, 3.7.4, 3.7.5, 3.7.6, 3.7.8, 3.7.9, 3.7.10, 3.7.11, 3.7.12, 3.7.13, 3.7.14, 3.7.15, 3.7.16, 3.7.17

Unlike the website of Rudy Giuliani’s security company, which looks like it might not have been actively managed since 2014. This website is still very much active, seeing as the News section of Gingrich Productions has entries from just days ago.

No WeWatchYourWebsite, That Is Not Hackers Looking For Infected Websites

We are often brought in to re-cleanup malware infected websites after another company has done a clean up and the website gets infected again (or was never actually fully cleaned).  The website getting infected again isn’t always the fault of the company doing the clean up, for example we sometimes have clients that don’t takes steps on their end that we told they needed to do (we take any steps that we can during our work), which leads to the website being infected again. But when someone comes to us and mentions a previous clean up has been done, we always ask if the previous cleaner determined how the website was infected (seeing as if that isn’t found and fixed the website could still be vulnerable). In almost every instance the response has been that determining how the website got infected never even came up, much less was attempted.

Avoiding companies that don’t mention that they determine how the website was infected as part of a cleanup would help you avoid some situations that would lead to you having to hire multiple companies to clean up the website. That has a major limitation though as we have found many security companies are much better at sounding like they know what they are doing then actually doing it. Only someone that actually knows what they are doing is likely to be able to spot that a company is not telling the truth, which isn’t likely when someone is hiring a company to do this work for them.

To give an example of this let’s take a look at something we recently ran across with a company named WeWatchYourWebsite. They promote that they do was they “Root Cause Analysis”:

If your website has ever been infected, you want to know “how” it happened. This sets our service alone at the top. We provide you with real proof of how your site was infected. Was it a faulty plugin? Outdated software?

We’ve invested the time required to create a system that will determine how your site was infected – and then we inform you. This along with steps you need to take to help us – help you keep your website safe and secure.

That would be impressive if true, but it isn’t. Not only do we determine how the website was infected, so they are “alone at the top”, but we actually get that issue fixed. We also make sure the website is secured by updating the software (even if that isn’t the cause), because that is one three basic steps to a proper cleanup. By comparison WeWatchYourWebsite doesn’t do that, instead trying to detect attacks and block them, that really isn’t a good idea and they don’t provide any independent third-party evidence that it is actually effective at that. Our experience with other products making similar claims is that they provide limited to no protection.

The other thing that makes this sound less impressive is that they tout that their malware removal is “automated”. Considering that the cleaning up the malware and other malicious code often provides valuable information on the source of the infection. Having something fully automated is not conducive to doing that. In our experience this often also leads to poor results for the cleanup.

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. In the case of WeWatchYourWebsite, one of their recent posts shows a basic lack of understanding of how hackers operate and what log files of activity on the website, which are often key piece to definitively determine the source of a hack, actually show.

In a post from December 29, they claimed to provide an example of a hacker looking for infected WordPress websites. While hackers do sometimes re-check websites they have infected to make sure that is still true and hackers do try exploit malicious code that might have been placed on there by another hacker, what is shown in the post is not that. Let’s take you through it:

Investigating some interesting entries in log files from our customers, we see that hackers apparently are still looking for infected WordPress websites.

First we see this:

(IP address blanked to protect the infected) – – [28/Dec/2016:20:44:14 -0500] “GET / HTTP/1.1” 200 72904 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31”

The big tipoff here is the size of the GET request: 72904.

That first request is just a request for the homepage. From the outside we can’t see what the purpose of that would be. It could be used to see how a URL that actually exists responds on the website, it could be used as a comparison after making some change to the website later on, it could be used to determine that the website is running WordPress and its location on the website, or something else entirely.

We are not sure what it supposed to mean that the size of the request is a “big tipoff”, since that is just the size of the homepage served to the requester. It is possible that WeWatchYourWebsite falsely believes that is the size of request sent to the website, not the size of what was sent back.

And then this:

(IP address blanked to protect the infected) – – [28/Dec/2016:20:44:16 -0500] “ POST ///wp-admin/admin-post.php?page=wysija_campaigns&action=themes HTTP/1.1” 403 – “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31”


We captured the GET request and after comparing it to the attacks on the old, vulnerable version of that WordPress plugin we see that the hackers were doing some open reconnaissance on WordPress sites. We say “open” because this site never had the MailPoet plugin installed.

The second request is not “open reconnaissance”, that is the hacker trying to exploit a vulnerability that had existed in older versions of MailPoet.

(IP address blanked to protect the infected) – – [28/Dec/2016:20:44:19 -0500] “GET //xGSx.php HTTP/1.1” 404 45488 “-” “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31”
The above is them testing to see if their attack worked. It didn’t
Here they seem to understand that isn’t reconnaissance, since they are referring to one of the previous requests as an attack.
All of this is just to show that even though you think previously infected WordPress website may have been cleaned up from any previous malware, the hackers will always be looking just to be sure you have.
Hackers do sometimes check if the malware or other malicious code they have placed on a website is still there, but what was shown here was someone trying to exploit a vulnerability on the website. Considering that WeWatchYourWebsite stated that this plugin was never installed, it really is odd that they came to this conclusion that the hacker was re-checking things.
The last line might explain what is really going on here:
You may want to read about our methods of malware detection:
It looks like the post was really about getting to promoting their service, but it really ends up being a warning that this company doesn’t know what they are talking about.

When a WordPress Security Plugin Gets Praised for Creating a Problem

When it comes to the poor state of security information surrounding WordPress one of problems we see is security companies making up threats and then claiming that their product or services can fix them. One example of that we have discussed in the past is the widely peddled falsehood that there are a lot of brute force attacks against WordPress admin password. What is actually happening looks to be mainly dictionary attacks, which involves a hacker trying to log in using common passwords. The simple solution to prevent these from being successful is to use a strong password, something that WordPress is already good at helping you accomplish.

One of the problems with not addressing the real issue here, is that a solution not designed for the actual threat can actually cause more problems. For example, if you limit the number of failed logins attempts that can be made to try prevent a brute force attack (since that would involve trying every possible password), not only can it cause problems getting back in to the website if you have trouble remembering your password, but it can make it easy for someone to lock you out of your own website depending on how the lockout is handled (a form of a denial of service (DOS) attack).

That brings us to another problem when it comes to WordPress security information, which is that public often is providing reviews and recommendations that lead others in the wrong direction security wise. Take a review for the security plugin BulletProof Security we came across while working on another post. The review is title “Saved My Site”, but what it actually describes is the plugin creating a problem:

Got slammed by hackers who discovered my username. I was locked out of my admin area due to multiple attempts at login which I did not do.
I deleted the plugin, then I created a couple of new strangely spelled admin usernames names and long passwords, reinstalled the plugin and I am good to go.

The WordPress username is not intended to be secret, so someone discovering it shouldn’t be an issue. The issue here is that a plugin is locking the person out due to actions they didn’t take, which had obvious negative consequence. At the same time it wouldn’t necessarily protect against a dictionary attack if the hacker simple slowed their login attempts to below where it would be stopped by such a plugin.

Considering that the plugin is named BulletProof Security and it has overwhelmingly received 5 star reviews (and an average 4.7 stars), you might be surprised to hear the plugin is far from bulletproof. In testing over at our Plugin Vulnerabilities service it has failed to provide any protection against exploitation of four real vulnerabilities that existed in other plugins. Unfortunately highly positive reviews for a plugin that fails to provide the protection it promises is not limited to this plugin, but is a widespread issue.

The Website of Rudy Giuliani’s Security Company is Powered by an Outdated and Insecure Version of Joomla

When it comes to cyber security you don’t have to look far to see why things are currently in such bad shape, as we have often found that even security companies themselves are not doing the basic security step of keeping the software on their own website up to date. So looking to the private sector to improve the situation is a questionable call.

Incoming US President Donald Trump is going to be advised on the issue by former New York City Mayor Rudy Giuliani, who has a company that provides cyber security consulting of an unclear nature. ZDNet’s Zero Day blog reports they have been unable to find what the company actually does:

For the past few months while Giuliani’s name was floated for positions for the Republican’s presidential campaign, we’ve tried to find out exactly what his company does, or can do better than any other security firm — to no avail.

So is the website of Rudy Giuliani’s security company at least in better shape than other cyber security companies? No:

The Giuliani Security & Safety Website is Running Joomla Version 3.1.1

The next release of Joomla, 3.1.4, (3.1.2 and 3.1.3 were not officially released) was released in July of 2013. The next version after that, which was released in August of that year, included a security fix. There have been numerous updates since then, including many that included security fixes.

The copyright date on the website is 2014, so even it hasn’t been actively managed since then, their keeping the software up to date stopped before that happened.

Other evidence out there doesn’t exactly point to Rudy Giuliani really having a great grasp of technology matters. For example, back in September he claimed the software used to wipe Hillary’s Clinton’s emails was “expensive” and “very expensive”:

The servers containing the emails was not only erased by merely deleting the email, but expensive BleachBit software was used to do it. This software is very expensive and is used by criminals seeking to hide evidence from law enforcement.

That is despite the fact that the software is free, something you can easily find out if you do search and pull up the software’s home page or the Wikipedia page about it.

Cancelling SiteLock Services Sounds Like It Is Just As Bad As Everything Else With Them

Yesterday we looked at an example of the web security company SiteLock trying to mislead someone on what leads to websites being hacked to get them to purchase a reoccurring service with a long term commitment instead a one-time service. Using their one-time cleanup is also a bad option since it doesn’t include fixing vulnerability that allowed the website to be hacked, while costing more than we charge in many instances for a proper cleanup that actually includes the work to secure the website (you can also get a lower quality cleanup from many companies for much less that SiteLock charges). If you make the mistake of signing up for one of SiteLock’s ongoing services you are in for more problems based on what we have seen mentioned by their customers.

In the past we have had people comment and discussed that these service don’t protect websites from getting hacked and SiteLock explaining the solution is to pay them even more.

At least in some instances people are being charged without receiving any invoice or other notice of the ongoing charges.

Then there is trying to cancel, which we have seen numerous complaints from their customers about.

First off, according to their customer agreement you have to call in to a cancel the service:

All cancellation requests must be submitted by calling our Customer Care Department at (415) 390-2500 and must be made prior to the expiration of the Service term.

In one customer’s complaint they mentioned something that really isn’t that surprising to hear about what happens when you call:

It is not possible to each the billing department except by phone and when you call you are connected with a telemarketer that try’s to upsell you and they become rude when they realize there is not going to be a sale.

The “billing department” is actually a salesroom.

You might be waiting a long time to even get to that as one review on SiteLock’s BBB page reported that:

I tried to cancel my account and it is nearly impossible. Was on hold for over 45 minutes and the person said they did and low and behold….billed the next 2 months.

And here is another complaint with someone taking even more time

I’ve spent two hours, over 4 phone calls attempting to cancel the service by phone. I’m currently on another extended hold waiting for a ‘cancellation agent’.

(While it sounds like making you call is about trying to make it difficult to cancel or try to sell to you again, it turns out that for a web services business they don’t seem to be very web savvy, as one of their web hosting partners list that you need to call SiteLock to have their CDN’s cache of your website manually cleared as well.)

If that isn’t bad enough if you don’t cancel at least thirty days prior to end of the subscription period you are going to being paying for another one according to their customer agreement:

Such cancellation must be made at least thirty (30) days prior to the end of Customer’s current subscription period.

Considering that these are web services that should easily be turned on and off, this sort of lead time doesn’t make sense.

In other instances people have complained about various cancellation fees as well, even though with what the services include that doesn’t seem like it would be a reasonable thing.

SiteLock Misleads Potential Customers About Why Websites Get Hacked To Lock Them In To Long Term Commitments

One of the oddest claims that we have seen related to the web security company SiteLock was that they “don’t control how the hosts sell their services to customers”, which came from a journalist and seemed to be based on their conversation with a SiteLock employee. It’s odd because in what kind of partnership would one partner not have any control over how their services are being sold, but especially in the case of SiteLock’s partnerships where they are paying the web hosts a lot of money to partner with them (one web hosting company disclosed to investors that they get 55% of the revenue of sales of SiteLock services) and when many of the partnered web hosting brands are run by SiteLock’s owners. The other thing that made this so odd is that from everything we have seen the problematic way their services are sold usually involves sales made by SiteLock themselves. The web hosts just push their customers to SiteLock and then when their customer gets in touch with SiteLock they are put in touch with a commissioned sales person, which is where the problems really start.

We have seen and heard plenty snippets of what that involves in the past, but we recently ran across an example of an email from SiteLock that shows how they try to trick people into overpriced services. Not surprisingly considering that they are willing to tell people things that are not true even when the truth doesn’t seem to be a big deal, much of what they said is far from the truth.

Let’s start from the beginning of the email:

It looks like the issue your website is having is more than just infected files and you’re goign to need a manual clean. I recommend the SecureSite plan. I recommend this plan because you’re going to need several cleans during this process (of being under a targeted attack) but the malware itself isnt the biggest issue. The biggest issue the vulnerability that is allowing a hacker (or bots controlled by a hacker) to inject code or infect your files.

SiteLock makes a big deal of their automatic malware removal and how that sets them apart, but what we often see is they tell people that it won’t handle the issue on their website and they are going to need a manual clean, which comes with an additional cost. In one case they also claimed that a website couldn’t be automatically cleaned “without risking bringing down our site”.

A real problem with automated malware removal is that when cleaning up malware or other malicious code what is found can often provide important information on how the website was hacked, so if the cleanup is fully automated the cleaner is potentially going to miss important information needed to get the website secured. Normally SiteLock doesn’t actually determine how the website is hacked, so that doesn’t matter, but not doing that leaves the website open to the possibility of being hacked again. While doing that is actually a basic part of a cleanup, as will come up later SiteLock will charge even more money to do that (for a lot of cleanups they charge more to just remove the malicious code than we do for a proper cleanup including getting the website secured).

There is always going to be a vulnerability that allowed a hacker in, otherwise how would the hack have even happened.

The claim that website is being targeted isn’t actually true, unless you count every hack as being a targeted one. The explanation of how the website is being targeted doesn’t make sense:

You are being targeted by this hacker, they already know how and where the vulnerability exists and they will not stop sending bots to you until your website is destroyed or until the bots “hit a wall”. Typically about 4-5 months of rejected attempts the hacker will send the bots elsewhere as they’re usually after low hanging fruit. They’re hacking 10s of thousands of sites at a time and usually the goal is stealing traffic or placing malware on your site to get onto peoples computers to steal information. After the vulnerability is fixed, they’ll move on, I wish I could elaborate on what’s causing this right now but I don’t want to just guess, the data in the manual clean will give me exactly the information I need whether it’s having our technicians recode entry fields on the website or if something needs to be done on a server level via your host.

From dealing with many hacked websites we get the sense that this is written by someone who has no idea what actually happens with hacking attempts on websites, which they probably don’t, since it was coming from a sales person not a technical person.

The reality is that most hackings are not targeted at specific websites; instead hackers try to exploit the same vulnerability across many websites, which is often referred to as a mass hack. Either the website is vulnerable and the hacker will take further actions once they successfully exploit the vulnerability or they will move on to other websites. Often times there look to be numerous different people or groups trying to exploit the same vulnerability, so a vulnerable website might get hacked more than once (that is good reason to promptly deal with a hacked website once you become aware it has been hacked).

Hackers are not usually interested in destroying websites. The closet we see with that are defacements hacks where a hacker causes a website’s pages normal content to be replaced with a message from the hacker. The website’s content would normally not be destroyed by that. In other cases hackers are interested in using the website to do something else, say sending spam emails, which wouldn’t destroy it at all. Of course if you are trying to scare people, then telling hackers are trying to destroy their website would make sense.

Another part of shouldn’t really make sense even if you are not familiar with hacked websites. The email claims that “Typically about 4-5 months of rejected attempts the hacker will send the bots elsewhere as they’re usually after low hanging fruit.” Why would a hacker keep trying to exploit a vulnerability for months on end when either the vulnerability is exploitable or isn’t? The answer would seem to be that they are trying to lock you in to a six month commitment to one of their services, again this coming from a salesperson.

After the manual clean we will also your host (if your website is suspended) so that they can re-instate the account if you’ve been deactivated, we will also take care of any blacklisting issues (Google, Norton, AVG, Avast, Bing , Yahoo, etc… if there is a warning screen stating that your website is malicious or that it has malicious content). You do have the option of purchasing a one time clean from us but typically within 24 – 72 hrs, you’ll need another clean due to the bots attacking you. One time cleans are also $300 per clean, per domain and vulnerability fixes are the same price of $300 per domain.

A proper one time cleanup would actually involve determining how the website has gotten hacked and making sure it is fixed. Their pricing is just outrageous. If you want a poor quality cleanup that doesn’t involve doing things properly, you can spend a lot less than $300. For many websites we charge less than $300 to do things properly, meanwhile SiteLock wants $600 to do that. The idea that they would even sell a service that they know leaves a website vulnerable is rather troubling.

I would also be happy to review the services with you after 6 months to make sure that bot traffic has decreased, I encourage you to reach out to me so we can determine whether you’re still being targeted. I can proudly say that 100% of my customers that follow my recommendations (after the clean, as far as general maintenance) not only are malware free and no longer the victim of a targeted attack but also likely will not have a need for unlimited cleans and can explore other options (we have nearly 70 different products and services).

Here we get to them trying to get you to a six month commitment, the price of this wasn’t mentioned, but we have recently had people mention that they are trying get them to sign up for services that are $100 a month (in some instances it is even higher than that). That would be the same price as their overpriced cleanup and securing service, but with the added difficulty of trying to cancel the service at six months. The fact that they offer a service with unlimited cleanups is a good indication that they don’t properly secure websites, since if you do a proper cleanup the website shouldn’t be able to be exploited through the same issue again at all.

Considering that very few websites are ever targeted by hackers, the person receiving this email likely was never targeted in the first place.

SiteLock Provides More Evidence That They Are Not Being Truthful About Who Provides Their CDN and WAF Services

Back in November we discussed evidence we had found that indicated that the web security company SiteLock’s TrueSpeed CDN and TrueShield Web Application Firewall services were actually provided by another company Incapsula, while SiteLock made it sound like they are providing them directly. At the time we mentioned that is “troubling as all of the customer’s website’s traffic is going to be running through a company that they don’t have a relationship with or are even likely to know is involved”. It is also troubling to think that a security company would be lying to their customers like that, since a big part of security is trust. If they are lying about something like this, where we don’t see why they even would need to, you reasonably have to wonder if there is something they wouldn’t be willing to lie about.

A recent post on SiteLock’s blog provided further confirmation that these services are actually provided by Incapsula while at the same time making it sound like SiteLock is providing them directly. In the December 18 post SiteLock TrueShield Updates they let their customers know of new IP addresses being used by those services that some of their customers would need to whitelist. Those IP addresses are

If you look up who those belong to it is Incapsula: example 1, example 2, and example 3.

In the post there is no mention of Incapsula, but they is plenty that would make you think that SiteLock is actually providing the services. In a large font they refer to the IP addresses being used by the services as “ours”:

If you are adding our IP addresses for the *FIRST TIME* 

In explaining why the new IP addresses are being added they mention their servers and IP address, despite those pretty clearly being Incapsula’s instead (emphasis ours):

The SiteLock servers periodically make requests for updated content from your website’s hosting server. This ensures that we are delivering the freshest content to your visitors. During periods of high traffic, we may make more frequent requests for content than during off-peak periods. Cloud technology of this kind uses a finite number of unique IP addresses to fulfill these requests, making this behavior appear as a security threat to some firewall services. This can be due to the large number of requests from a disproportionately low number of perceived unique visitors. Whitelisting or creating firewall exceptions for our servers’ IP addresses prevents your other security systems from blocking legitimate traffic relayed through our servers.

If we were not already familiar with a litany issues with SiteLock (you can see some of those by looking over our previous post about them) we would say this would be a good reason to avoid them, but with all the others you should have more reasons to avoid them then you should possibly need.

Wordfence Spreads Falsehood on Database Prefix Security Hardening to Push Their Plugin

In the past we have written about how the WordPress focused security company Wordfence is making up threats in an effort to promote their plugin (and therefore their paid service). We have received pushback on that, some of which can be summed in that even if Wordfence isn’t telling the truth, their plugin might provide protection against what is really going on. Or as one of the comments reads less gracefully:

To the layperson, they don’t give a crap if it’s a dictionary attack or a brute force attack. An attack is an attack is an attack. If they happen to have some passwords in that dictionary and wordfence does stop it, is there not value in that?

That might be a reasonable argument if Wordfence was just telling people to use their plugin in addition to taking other steps. Ignoring the fact that their plugin has actually introduced additional vulnerabilities on websites due to the vulnerabilities that have existed in it, taking an extra step shouldn’t hurt the websites security, so it wouldn’t be that big of an issue.

The problem with that is that Wordfence intent in making these claims is pretty clearly to promote their plugin instead of actually promoting better security. A recent post of theirs shows this, as they make the claim that a common security hardening step of WordPress provides no protection and then quickly turn to promoting their plugin as an alternative. The truth though is they are wrong about this, probably because of their lack of security knowledge, which would be a good reason for them not to be handing out this type advice in the first place (or using it to promote their plugin).

No Protection

In the post on December 28 blog post, titled “WordPress Table Prefix: Changing It Does Nothing to Improve Security“, Wordfence claims (emphasis theirs):

Changing your WordPress table prefix is risky to implement and it does absolutely nothing to enhance your site security.

A little later they state this (emphasis theirs):

An idea became popular a few years ago that went something like this: If an attacker has access to your database via SQL injection, you can prevent them from accessing your data by renaming your tables to some unique prefix.

What Wordfence seems to have missed entirely is that a SQL injection isn’t the only way an attacker can get access to a database, which we will come back to in a bit.

Past their details that are supposed to back their claim up you get to real reason for the post, to promote their plugin:

Changing the WordPress Database Table Prefix is ‘Security Theater’

Changing the WordPress table prefix is what we refer to in the industry as ‘security theater’. In other words, it is busy-work that makes you feel more secure but does nothing to make you more secure. It only adds risk and complexity.

We have another cool sounding phrase that describes this: ‘Security through obscurity’. What this means is that you’re trying to secure yourself by making things harder for an attacker to find. In the security industry this is widely accepted as a pointless exercise.

Things that do actually make you more secure against attacks are a WordPress Firewall, like the one included free with Wordfence. This actually blocks SQL injection attacks before an attacker can gain access to your database.

The Wordfence firewall includes rules to block SQL injection attacks. It even includes a sophisticated SQL parsing engine that understands SQL the same way a database does. When we see incoming SQL, we intelligently parse it to determine if the intent is malicious or not. If it’s a SQL injection attack, we block it. If we detect it’s a site user or administrator doing something safe like posting a blog post, we allow it through.

(The claim made there that “Security through obscurity” “is widely accepted as a pointless exercise” in the “security industry” is not actually true, as a quick look through the results a Internet search for the term would show, but as usual it looks like Wordfence doesn’t know what they are talking about.)

Wordfence’s Firewall is a Defective Hammer

There is common saying, of which one variation is “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” The problem with that is not everything is a nail. Even when something is a nail, if your hammer is defective, it won’t necessarily be able to hammer the nail. Wordfence pretty clearly sees their firewall as a hammer and ignores the fact that it is often not effective.

We have done six tests of Wordfence’s plugin against real vulnerabilities in other plugins over at our Plugin Vulnerabilities service (four of them done as part of testing multiple security plugins). The results for their plugin and therefore its firewall haven’t been good. In four of them no protection was provided. In the other two the protection was easily bypassed. It turns out that Wordfence is actually aware to at least to a certain of the limitations of their firewall, but instead of being realistic about it, they spin the issue, apparently hoping (so far correctly) that they can get away with that.

Wordfence’s plugin isn’t an outlier, as in the four tests that involved multiple security plugins only one of them provide non-bypassable protection in one test and that came the tradeoff that Editor-level and below users wouldn’t be able to upload media. The obvious take away from that testing is that security plugins don’t provide much protection. Another take away we have had from that testing that is relevant here.

In a test of a vulnerability that allowed a file included with an attackers request to be uploaded to the website, we found that Wordfence prevented exploitation in our basic test. That was due to Wordfence seeing that a file being sent with the request had a PHP extension. That was easily bypassed though because one of the other items sent with the request was the name you wanted the file being uploaded to be saved as. So for example, you could upload the file as “malicious.txt” instead “malicious.php” and then specify the file be named “malicious.php” when saved to the file system. Wordfence wouldn’t stop the request without the PHP extension, but the file would still have a PHP extension after being uploaded on the website due to the name specified. Our take away from that is that vulnerabilities don’t always play nicely with assumptions made by security products.

Updating the Database

Recently for our Plugin Vulnerabilities service we were reviewing a report of a SQL injection vulnerability in the plugin ZX_CSV Upload, which allows “simple upload & update data from CSV to DB plugins”. The report noted that you had to be logged in as an Administrator to exploit. Seeing as an Administrator can normally do almost anything, they would normally have the ability to do the equivalent of SQL injection. So there wouldn’t really be a security vulnerability there unless this could be used to do something malicious using cross-site request forgery (CSRF). CSRF involves causing someone to take an action they didn’t intend. When we went to look to see if that was the case with this plugin we noticed a more obvious issues, the intended functionality of the plugin was susceptible to CSRF.

In practical terms this vulnerability could be used to update the database to add a new Administrator user controlled by an attacker, if they could get a logged in Administrator to access a page they control.

In our post on the issue we noted:

You would need to know what the prefix for the database is, so changing that would actually come in to play with a vulnerability (which it rarely does despite the big deal made about changing it in various security plugins and tutorials).

That post was put out on December 19, so if Wordfence was following sources putting out good information they could have avoided their false claim changing the database prefix “does absolutely nothing to enhance your site security”.

Making this even worse in our testing Wordfence’s plugin (and therefore firewall) doesn’t protect against exploitation of this vulnerability, while changing the prefix actually could.

It is worth noting that this plugin only had 10+ installs, so any exploitation of it is unlikely, but another vulnerability could open a similar possibility on a wider scale. Wordfence assumed incorrectly that the only time that the prefix comes in to play is with SQL injection, which this vulnerability makes clear isn’t the case.

Guessing the Prefix

If the database prefix hasn’t been changed the only limitation to exploiting it on a website using the plugin would be getting a logged in Administrator to access a page you control, which isn’t necessarily easy (at this point we don’t see any evidence of any wide scale attempt to exploit vulnerabilities that require getting that to happen, so you would only likely to be at risk in a targeted attack). But what if the prefix had been changed, you would need to make enough requests to guess the right one as well. So how many possibilities would there be?

MySQL database table names (and therefore the prefix) permit the following characters “0-9”, “a-z” , “A-Z”, “$”, “_”.  Depending on the operating system the table name will or won’t be case sensitive. For our purposes then let’s assume that the prefix is all lower case and the dollar sign isn’t used.

If you only letters are used you have the following number of combinations depending on prefix length:

  • 1 character prefix: 26 combinations
  • 2: 676
  • 3: 17,576
  • 4: 456,976
  • 5: 11,881,376
  • 6: 308,915,776
  • 7: 8,031,810,176

If you also include numbers you have the following number of combinations:

  • 1 character prefix: 36 combinations
  • 2: 1,296
  • 3: 46,656
  • 4: 1,679,616
  • 5: 60,466,176
  • 6: 2,176,782,336
  • 7: 78,364,164,096

The chances that you could cause the logged in Administrator’s web browser make enough completed requests to be successful in guessing the right prefix seems would depend on the prefix length. Maybe it could work with a short one, but once you are talking about the possibility of billions requests per table you are updating, the websites likely couldn’t handle the load if the computer and the network between them could before the user closed the web page causing the request to be sent.

So how long does a WordPress security plugin make it when changing it? The iThemes Security plugin, which has 800,000+ active installs according to, created one for us that was 7 characters and included numbers when we tried it features to change it, “ej952ng”.

Layered Security

Based on that, changing the database prefix has the possibility of being useful additional security step for a website at risk of targeted hacking as part of a layered approach to security (whether emphasizing that that type of action while even security companies, including Wordfence, are failing to do more basic security measures is its own issue).

So does Wordfence not believe in layered security? Actually they do, but when it involves it is a chance to push their plugin with a made up claim:

On some sites it’s a disaster if they’re compromised. The data theft can never be undone even if they recover from a hack. They want to employ every measure they can to be secure – and in our industry that’s a standard approach: We refer to it as a layered approach to security.

On others sites, it’s just a case of restoring from backups if you get hacked and moving on.

That is why we offer options like these that are configurable.

Here Are What Malicious WordPress Login Attempts Actually Look Like

Recently we discussed how the WordPress security company Wordfence continues to spread the falsehood that there are a lot brute force attacks on WordPress admin passwords (and then promotes that their plugin is the solution to the problem). An actual brute force attack would involve billions or more attempts and Wordfence’s data showed only millions attempts a day over 100,000s of websites, so 10s of attempts per website. What they actual look to be seeing are dictionary attacks, which involve an attacker trying to log in with common passwords.

The distinction is important because to protect against those all you need to do is use a strong password and you don’t need to install any plugins or continually monitor for failed login attempts (as lot of people are doing due to being mislead about what is going on). We also have have found that people will sometimes get very concerned that they have been hacked when warned by plugins that brute force attacks are going on, but when we explain to them what is actually going on that concern is cleared up because they are already using a strong password.

We thought it would be helpful to show what a couple of these dictionary attacks look like and to see how WordPress’ password strength indicator would rate the passwords tried.

The main portion of our website is powered by Drupal (this blog is powered by WordPress), despite that, we regularly have attempts to login to the main portion of our website as if it was running WordPress through attempts sent to The fact that is happening is reminder that much of the malicious attempts against websites are incredibly crude and that the success rate of hacking attempts is incredibly small. We have been logging login attempts though that for some time and here a couple of recent sets that shows what kind of login attempts are actually going on.

For password strength, we tested it through this blog, running WordPress 4.7, so the relevant domain name was being used to calculate the rating.

The first involves 21 attempts from a Tunisian IP address, where username “admin” was used alongside the following passwords (the password strength is listed in parenthesis):

  • admin (Very weak)
  • demo (Very weak)
  • admin123 (Very weak)
  • 123456 (Very weak)
  • 123456789 (Very weak)
  • 123 (Very weak)
  • 1234 (Very weak)
  • 12345 (Very weak)
  • 1234567 (Very weak)
  • 12345678 (Very weak)
  • 123456789 (Very weak)
  • admin1234 (Very weak)
  • admin123456 (Very weak)
  • pass123 (Very weak)
  • root (Very weak)
  • 321321 (Very weak)
  • 123123 (Very weak)
  • 112233 (Very weak)
  • 102030 (Very weak)
  • password (Very weak)
  • pass (Very weak)

The second involved 52 attempts from IP address in China. Along side the username “admin” the following passwords were tried:

  • admin (Very weak)
  • admin000 (Very weak)
  • admin123 (Very weak)
  • admin000 (Very weak)
  • admin888 (Very weak)
  • admin@ (Very weak)
  • 123admin (Very weak)
  • www_whitefirdesign_com (Weak)
  • (Weak)
  • (Very weak)
  • whitefirdesign (Very weak)
  • www-whitefirdesign-com (Weak)
  • wwwwhitefirdesigncom (Weak)
  • adminadmin (Very weak)
  • 123456 (Very weak)
  • adminpassword (Very weak)
  • 12345 (Very weak)
  • 12345678 (Very weak)
  • qwerty (Very weak)
  • 1234567890 (Very weak)
  • 1234 (Very weak)
  • baseball (Very weak)
  • dragon (Very weak)
  • football (Very weak)
  • 1234567 (Very weak)
  • monkey (Very weak)
  • letmein (Very weak)
  • abc123 (Very weak)
  • 111111 (Very weak)
  • mustang (Very weak)
  • access (Very weak)
  • shadow (Very weak)
  • master (Very weak)
  • michael (Very weak)
  • superman (Very weak)
  • 696969 (Very weak)
  • 123123 (Very weak)
  • batman (Very weak)
  • trustno1 (Very weak)

After those they tried logging in with the username “whitefirdesign” and the following passwords:

  • whitefirdesign (Very weak)
  • whitefirdesign000 (Very weak)
  • whitefirdesign123 (Very weak)
  • whitefirdesign000 (Very weak)
  • whitefirdesign888 (Very weak)
  • whitefirdesign@ (Very weak)
  • 123whitefirdesign (Very weak)
  • www_whitefirdesign_com (Weak)
  • (Weak)
  • (Very weak)
  • whitefirdesign (Very weak)
  • www-whitefirdesign-com (Weak)
  • wwwwhitefirdesigncom (Weak)

Of the 73 passwords tried (including those used multiple times), 65 of the them were rated as “Very Weak” by WordPress’ password strength indicator and the other 8 were rated as “Weak” (all of the “Weak” ones used some variation of the domain name in them). So WordPress password strength indicator looks to be doing a good job of helping people to pick strong passwords that would not be guessed in a dictionary attack.