Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wordpress-seo domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php on line 6114

Warning: Cannot modify header information - headers already sent by (output started at /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php:6114) in /home4/lifeint9/public_html/vandelayweb/wp-includes/rest-api/class-wp-rest-server.php on line 1893

Warning: Cannot modify header information - headers already sent by (output started at /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php:6114) in /home4/lifeint9/public_html/vandelayweb/wp-includes/rest-api/class-wp-rest-server.php on line 1893

Warning: Cannot modify header information - headers already sent by (output started at /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php:6114) in /home4/lifeint9/public_html/vandelayweb/wp-includes/rest-api/class-wp-rest-server.php on line 1893

Warning: Cannot modify header information - headers already sent by (output started at /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php:6114) in /home4/lifeint9/public_html/vandelayweb/wp-includes/rest-api/class-wp-rest-server.php on line 1893

Warning: Cannot modify header information - headers already sent by (output started at /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php:6114) in /home4/lifeint9/public_html/vandelayweb/wp-includes/rest-api/class-wp-rest-server.php on line 1893

Warning: Cannot modify header information - headers already sent by (output started at /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php:6114) in /home4/lifeint9/public_html/vandelayweb/wp-includes/rest-api/class-wp-rest-server.php on line 1893

Warning: Cannot modify header information - headers already sent by (output started at /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php:6114) in /home4/lifeint9/public_html/vandelayweb/wp-includes/rest-api/class-wp-rest-server.php on line 1893

Warning: Cannot modify header information - headers already sent by (output started at /home4/lifeint9/public_html/vandelayweb/wp-includes/functions.php:6114) in /home4/lifeint9/public_html/vandelayweb/wp-includes/rest-api/class-wp-rest-server.php on line 1893
{"id":2251,"date":"2015-07-04T06:22:19","date_gmt":"2015-07-04T06:22:19","guid":{"rendered":"http:\/\/vandelayweb.com\/?p=2251"},"modified":"2019-03-20T04:41:59","modified_gmt":"2019-03-20T04:41:59","slug":"hacker-sets-up-hidden-canadian-pharma-pages-on-website","status":"publish","type":"post","link":"https:\/\/www.vandelayweb.com\/hacker-sets-up-hidden-canadian-pharma-pages-on-website\/","title":{"rendered":"Hacker Sets Up Hidden Canadian Pharma Pages on WordPress"},"content":{"rendered":"

A client contacted me this afternoon saying that Google was showing that their website had been hacked underneath their search result. This was odd to say the least. New clients will occasionally call us to help clean up a website that has already been hacked, but this was the first time we’ve had one on a website we built. Our security measures are pretty tight so I was just as curious as I was concerned.<\/p>\n

I pulled up the client’s website and saw nothing wrong off first glance. I went into their Google Webmaster Tools account and sure enough the “hacking suspected” warning was sitting right on the dashboard waiting for me. The strange thing is that Google listed two pages that weren’t affected as evidence of the hack. I looked at the pages closely, looked at the HTML and ran them through Fetch as Google. No issues what so ever. At this point, I think Google is just screwing with me. This must be some kind of false positive by the big G. I submitted the request for review by their spam team and went about my day. The problem is that nagging feeling that something else was wrong just wouldn’t go away. So I dug further doing a site: search on the domain and sure enough hundreds of pages came up for viagra, cialis, propecia and every cruddy spam term you could think of. Ugh. I clicked through these links, and it was almost like another site was being run on our client’s domain. They were basically doorway pages channeling users on to canadaok-pharmacy.net (No — do not go there. You can see the site in the image below). There was no record of these phantom pharma pages in WordPress.<\/p>\n

\"canadaok\"<\/a>I went into the WordPress admin panel and tried to load the newest version of WordPress thinking that could have presented a weakness our slimy hacker slipped through. It failed saying the version of mySQL wasn’t up to date. I got the support rep at the webhost to deal with this matter, and I brought up the issue of the hack to them. Without a second thought, he said it was most likely an FTP hack. I checked the FTP password and sure enough a dictionary hack could have popped this gem right open. I don’t know if this was setup when the webhosting account was originally created or by the original web developer, but this was a monster security hole just begging to be exploited. I updated the FTP password as well as the weak account password to kill off the access then I went to work on these pages.<\/p>\n

I found this article<\/a> that says the hacker in question is basically running a <base href= hack. I started backing up the client’s website to my local machine until I started to see Viagra image files start to flow across. They had packed them all in the root images folder yet none of them matched the images loaded on the fake pages. In looking at the html code, it appears javascript was pulling these elements across remotely. I deleted the images out of that root folder and suddenly all those spam pages were pulling up 404s. Was it really that easy? Doubtful.<\/p>\n

In my book, an infected site is an infected site. I was betting there was a backdoor he’d placed somewhere that I wasn’t seeing. I had a recent backup of the client’s website files so I loaded everything up to a new directory at the web host then switched the folder names to take it live. I deleted out the old infected folder to purge anything I might have missed.<\/p>\n

Even more curious was when I did a cache on the spam pages saved into Google, they pulled up a different page entirely (see below). With this clearly spun content, the hacker was actually linking back to other sites he’d already hacked as if to give them more link juice to rank as well as other infected pages on our client’s website. Since these pages weren’t linked to from anywhere inside my client’s site, I have to think that ranking these pages was his ultimate motive. If that is the case then, we need to cut off his supply. I filled a webspam report against canadaok to have them removed from Google’s index due to their illegal activities. We’ll see what becomes of that.<\/p>\n

\"canadaok2\"<\/a><\/p>\n

Pulling his site up in Majestic SEO shows he’s infected 267 websites and has 132,845 links pointing back to him. It looks like those backlinks started showing up around the third week in June.<\/p>\n

Anyway I’d love to hear from others who have been hit by this nasty sucker. Hit me up in the comment section below.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

A client contacted me this afternoon saying that Google was showing that their website had been hacked underneath their search result. This was odd to say the least. New clients will occasionally call us to help clean up a website that has already been hacked, but this was the first time we’ve had one on […]<\/p>\n","protected":false},"author":1,"featured_media":2253,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[63,32,47,56],"tags":[],"class_list":["post-2251","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles","category-blog","category-security","category-wordpress"],"_links":{"self":[{"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/posts\/2251","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/comments?post=2251"}],"version-history":[{"count":1,"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/posts\/2251\/revisions"}],"predecessor-version":[{"id":2466,"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/posts\/2251\/revisions\/2466"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vandelayweb.com\/wp-json\/"}],"wp:attachment":[{"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/media?parent=2251"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/categories?post=2251"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vandelayweb.com\/wp-json\/wp\/v2\/tags?post=2251"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}