Hacker(s) Using File Manager Plugin to Assist in Taking Malicious Actions with Hacked WordPress Websites

Recently we have done cleanups of a number of hacked WordPress websites where part of what the hacker did after they have gained access to the website involved something we think would be useful to share with others in case they have even less information to go in trying to figure out how the website got hacked (attempting to determine how they were hacked is one of three basic steps in a proper hack cleanup).

In looking at the logging and other data, we have seen that the hackers were logging in to WordPress using existing WordPress accounts on the websites. From there they would install the plugin File Manager (WP File Manager). Here are the set of log entries where that occurred on one of the websites: – – [15/Jan/2018:14:41:04 -0700] “GET /wp-login.php HTTP/1.1” 200 1693 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC” – – [15/Jan/2018:14:41:07 -0700] “POST /wp-login.php HTTP/1.1” 302 1258 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC” – – [15/Jan/2018:14:41:09 -0700] “GET /wp-admin/ HTTP/1.1” 200 22557 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC” – – [15/Jan/2018:14:41:24 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 553 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC” – – [15/Jan/2018:14:41:26 -0700] “GET /wp-admin/plugin-install.php?tab=plugin-information&plugin=wp-file-manager& HTTP/1.1” 200 9499 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC” – – [15/Jan/2018:14:41:31 -0700] “GET /wp-admin/update.php?action=install-plugin&plugin=wp-file-manager&_wpnonce=c0ba6299b7 HTTP/1.1” 200 10849 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC” – – [15/Jan/2018:14:41:37 -0700] “GET /wp-admin/plugins.php?action=activate&plugin=wp-file-manager%2Ffile_folder_manager.php&_wpnonce=67fdf3eee0 HTTP/1.1” 302 480 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/ECAC”

As you can guess from the name that plugin is a file manager. The hackers then use the legitimate capabilities of that to modify existing files or add new files with malicious code. Here are the log entries from the same website where the same hacker looks to have logged in from another IP address and accessed the plugins functionality: – – [15/Jan/2018:15:11:14 -0700] “GET /wp-login.php HTTP/1.0” 200 1731 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5” – – [15/Jan/2018:15:11:18 -0700] “POST /wp-login.php HTTP/1.0” 302 1296 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5” – – [15/Jan/2018:15:11:21 -0700] “GET /wp-admin/ HTTP/1.1” 200 22745 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5” – – [15/Jan/2018:15:11:26 -0700] “GET /wp-admin/admin.php?page=wp_file_manager HTTP/1.1” 200 12922 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5” – – [15/Jan/2018:15:11:31 -0700] “GET /wp-admin/admin-ajax.php?action=mk_file_folder_manager&_wpnonce=4028a67f1f&cmd=open&target=&init=1&tree=1 HTTP/1.1” 200 3150 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5” – – [15/Jan/2018:15:11:35 -0700] “POST /wp-admin/admin-ajax.php HTTP/1.1” 200 2068 “-” “Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/62F5”

The most important question in all this is how the hackers got access to the logins for the websites, since without access they couldn’t have installed the plugin or done anything else. Unfortunately the cause is something we haven’t been able to say for sure since the evidence we have is somewhat limited when it comes to determining that part of these hacks.

In at least some of the cases the website were using extremely weak passwords (on one website the password was “admin1234”), so it is possible that a previous dictionary attack had determined the password. A dictionary attack involves try to log in using common passwords. Those types of attacks are fairly common, unlike brute force attacks, which despite inaccurate claims frequently made by security companies, are, based on those companies own evidence, not happening. The logging available so far hasn’t shown that occurring though, but it could have occurred outside the time period that there was logging available (the longer websites store logging the easier it would be to trace the original source of hacks).

In some instances the password being used was also used as the password for other services as well, so it possible that it was compromised somewhere else and the hackers tried it on the websites.

That all leads to the first take away from this, which is to make sure to use strong passwords (something WordPress does a good of making sure you can do) and to use separate password for each login connected to a website.

The second is that if you are dealing with a hacked website where the plugin File Manager was recently installed and it wasn’t installed by someone involved with the website, a compromise of a WordPress account with the Administrator role should be considered a possible source of the hack and further investigated. In one of the websites the plugin was later removed by the hacker, so you if see logging showing it being used, but it isn’t currently installed, that could have occurred on the website you are dealing with as well.

The third is that is that trying limit hackers once they have high level access is not necessarily very useful. In the past we have seen it suggested disabling the plugin and theme editors, since hackers could use those to modify files with malicious code. But as what happened here shows, hackers can easily get around that possible limitation.

SiteLock’s SMART Scan Failed To Deal with Issue Causing Cross-Site Browser Warning

One of the problems we have seen with the web security company SiteLock is that they label all sorts of things as being malware, making it hard for anyone else to determine what they might be referring to and therefore if the claim is valid. Sometimes their claims seem absurd, like the time they claimed a link to a non-existent domain name in a comment on a blog post was “critical” severity malware.

That type of issue could be an indication that their tools are overly sensitive or that they produce poor results. Something we just helped someone deal with reiterates what we have seen in the past,which is that it looks like the issue is the later.

We were contacted by someone for whom their website was being reported by the Chrome web browser as being dangerous and SiteLock’s  SMART (Secure Malware Automatic Removal Tool) Scan had been unable to fix the issue for them. They were looking for  quote from us to clean up the website.

When visiting the website in the Chrome web browser the following warning was being shown:


We have blacked out the domain listed, but the domain was the most important thing in the message because it wasn’t the domain of the website we were contacted about. Instead Google was warning about content from another website that was being served on this website, which is referred to as a cross-site warning.

In looking at the homepage’s content we found that the only content being loaded from that domain name was an image. When that image was removed the warning also went away.

That was easy for us to spot, but it was something that SiteLock’s tool wasn’t able to detect, while at the same time the tool flagged other things it seems like it shouldn’t.

This situation also shows why it is a good idea to come to us if you think you have a hacked website, because the first thing we do is to make sure the website is actually hacked and then we provide a free consultation on how best to deal with the issue. In this case that meant it didn’t cost this person anything more than whatever they had already paid SiteLock, to get this resolved. As once we saw what the issue was, we could tell them they simply needed to remove the image being loaded from that other website to resolve this.

Unlike Wordfence, We Fully Guarantee Our Hack Cleanups of WordPress Websites

One of the things that we often get asked about when it comes to hack cleanups, is how long we guarantee them. The answer is quite simple, if the issue comes back that means that we didn’t do something right and we wouldn’t charge anything additional to get it properly resolved. We would think that would be true of any upstanding company, but clearly most of the web security industry doesn’t feel that way, as we recently noticed with Wordfence.

When we discuss cleaning up hacked websites on our blog we don’t say that you should hire us, but that should hire someone that does things properly. That isn’t the case with Wordfence, which probably tells you a lot about them, as we saw recently with a blog post they wrote:

The most reliable way to recover if your website is hacked is to use our site cleaning service. Our team of experts will clean your site and get it back online as quickly as possible, and the service includes a detailed report and a 90-day guarantee.

What also stood out was there was their 90-day guarantee.

Looking at the page for that service, the backing they offer for their service is even more limited, as they say:

Work guaranteed for 90 days from service only if post-service recommendations are followed.

Who knows what those recommendations are, but that sounds like a way for them to weasel out of making things right if things went wrong.

There is another problem with a guarantee like this, based on what we have seen in often being brought in re-clean up hacked websites after someone else didn’t do it properly. Often times people haven’t realized that the issue hasn’t been properly fixed until after 90 days. When we are contacted about re-cleaning a website we always suggest that people go back to the people that originally did the cleanup and get them to do it right (even though if the previous company does that, it means less money for us), since if it was us, we would want to make things right . But with Wordfence if you noticed the issue outside of 90 days, you would be stuck paying them again if you did that (or needing to hire someone else to do it again).

Something else about how they promote their service really needs to be noted:

As the creators of the most popular WordPress security plugin, we have the most expertise in the industry.

Having the most popular security plugin doesn’t mean that they have the most expertise, it just means they have the most popular plugin. As we have mentioned in the past, the reality is that Wordfence has a scary lack of security knowledge. So how do they have the most popular security plugin? Part of the answer is to just blatantly lie. For example, the second sentence of the description of the plugin on wordpress.org until two weeks ago (and is now in the answer to the FAQ question “How does Wordfence Security protect sites from attackers?”) was this unqualified claim that it will protect your website from being hacked:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

The reality is that a WordPress plugin couldn’t possibly stop websites from being hacked in some ways (which Wordfence is well aware of) and Wordfence actually promotes their paid service as leaving people relying only on their plugin insecure. It seems like a bad idea to trust a company to clean up a hack when they have show that they have no qualms about lying to you and everyone else.

The second most popular plugin indicates that plugin popularity is not necessarily synonymous with a company that you want have anything to do with as that plugin uses a non-existent threat to collect users’ email addresses and had a “One-Click Secure” Button that did nothing except claim the website has been “Secured”.

Another element of Wordfence’s marketing stood out to us as well:

By work with them, they really mean they request a review through the same automated process as you or anyone else can use to do that.

A Better Cleanup

When we do a hack cleanup of a WordPress website not only do we do it properly, which based on some of stuff we have seen from Wordfence seems less likely. But we also include a free lifetime subscription to Plugin Vulnerabilities service, which will warn you if any of the plugins you use have disclosed vulnerabilities (with Wordfence you get widely inaccurate data on plugin vulnerabilities). We will also review all of your installed plugins for serious vulnerabilities using the same technique that we have used to catch numerous serious vulnerabilities in other plugins.

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 Zone-H.org, 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 Zone-H.org. 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 Websitewelcome.com is connected to HostGator and Unified Layer is connected to BlueHost, though the websites might be hosted with other EIG brands.

Page 1

  • endblameshameguilt.com: (Websitewelcome.com)
  • acimfordummies.org: (Websitewelcome.com)
  • wakechild.com: (Websitewelcome.com)
  • tena-frank.com: (Websitewelcome.com)
  • acourseinmiraclesfordummies.com: (Websitewelcome.com)
  • decodingacim.com: (Websitewelcome.com)
  • endblameshameguiltgame.com: (Websitewelcome.com)
  • toddtylermusic.com: (Websitewelcome.com)
  • lachildrensridingcenter.com: (Websitewelcome.com)
  • topsportscamcorders.com: (Websitewelcome.com)

Page 11

  • iphonenstuff.com: (Websitewelcome.com)
  • sneakerpicks.com: (Websitewelcome.com)
  • dalmatianadvice.com: (Websitewelcome.com)
  • subscribesave.com: (Websitewelcome.com)
  • helpmebuilda.com: (Websitewelcome.com)
  • bestboatplans.com: (Websitewelcome.com)
  • spelbonusar.com: (Websitewelcome.com)
  • gamingnshit.com: (Websitewelcome.com)
  • marenart.com.au: (Websitewelcome.com)
  • retailstartupbookinabox.com: (Websitewelcome.com)

Page 21

  • www.blackandwhitesecurityltd.com: (Websitewelcome.com)
  • dallasgayboys.com: (Websitewelcome.com)
  • untieeecs.com: (Websitewelcome.com)
  • jonathanjoyner.com: (Websitewelcome.com)
  • www.smcntx.com: (Websitewelcome.com)
  • www.culinairteamzeeland.nl: (Websitewelcome.com)
  • strandvakantieman.nl: (Websitewelcome.com)
  • napers.nl: (Websitewelcome.com)
  • www.camping-renesse.nl: (Websitewelcome.com)
  • www.campingdebrem.nl: (Websitewelcome.com)

Page 31

  • 81tagorelane.com: (Unified Layer)
  • skies39-newlaunch.com: (Unified Layer)
  • newlaunch-gshplaza.com: (Unified Layer)
  • 3dinvisibilitycloak.net: (Websitewelcome.com)
  • professional-liability-insurance.net: (Websitewelcome.com)
  • lyynx.net: (Websitewelcome.com)
  • aksolution.net: (Websitewelcome.com)
  • krilloils.org: (Websitewelcome.com)
  • 3dinvisibility.org: (Websitewelcome.com)
  • ellipticalmachineshelp.com: (Websitewelcome.com)

Page 41

  • topwebber.com: (Websitewelcome.com)
  • yoholly.info: (Websitewelcome.com)
  • myironsuit.com: (Websitewelcome.com)
  • laptoplifestylecafe.com: (Websitewelcome.com)
  • bellyfatcombat.net: (Websitewelcome.com)
  • herbzombie.com: (Websitewelcome.com)
  • biggerbuttshortcuts.com: (Websitewelcome.com)
  • blowtalk.com: (Websitewelcome.com)
  • waisttraineraustraliaco.com: (A2 Hosting)
  • besthairextensions.co.nz: (Websitewelcome.com)

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 Zone-H.org 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 Zone-H.org 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: https://www.ipage.com/product/sitelock

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 adyenweb.com 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 http://adyenweb.com or http://www.adyenweb.com. 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 adyenweb.com 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.