2

After recently having my shared-host linux server hacked (~25 WordPress installs, malicious code spidered throughout), I've started looking through my access log files to see where my traffic is coming from (was hoping to narrow down the point of entry, having minimal luck).

I keep seeing entries where I can verify the Referrer does not exist. For example:

103.47.135.111 - - [19/Apr/2016:01:14:53 -0600] "GET /wp-content/themes/wallstreet/style.css?ver=4.5 HTTP/1.1" 200 12562 "http://my_domain.com/yqmmfkv/Cara-pdkt-sama-cewek-lewat-hp.htm" "Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53"

The referrer (http://my_domain.com/yqmmfkv/Cara-pdkt-sama-cewek-lewat-hp.htm) doesn't exist from what I can tell. It returns a 404, there's no mention of it using grep -r "yqmmfkv", and doesn't seem to exist in my WP database. The style.css file does exist so I see why it's returning 200, but how can a page that doesn't exist be requesting it?

Further, what's the gain by spoofing the referrer?

DACrosby
  • 121
  • I've come across this too. I'm still debugging, but to me it looks like the virus installed a cron job. Try checking your apache cron jobs for each user, and also any wordpress cron jobs (theres a plugin called wp-crontrol that's useful) – contool May 16 '16 at 15:45

1 Answers1

0

We seem to have been hit by the same type of virus. If you used an anti-malware removal plugin it would have deleted the /yqmmfkv directory where the virus installed a bunch of content (porn, links, images, videos, audio files etc) it also created a bunch of html files with code that probably logged your domain to an external site, as well as some other malicious base64 encoded php and in my case a horrible little support.php file.

Scanning the originator IP at http://whatismyipaddress.com/ip/103.47.135.111 will tell you that the request is coming from somewhere in Indonesia - if this is not you (I suspect not) it just means they are spoofing the http_referer in the http header.

Originally when the virus was present on your server it probably stored some information, including the path to your style.css remotely - hence the 200 and is either using it to 'ping' test your site or it may have installed some malicious code within those files previously.

What I did was simply detect the file pattern in the request and forbid access to it via my .htaccess file:

RewriteCond %{HTTP_REFERER} .*yqmmfkv [NC] #checks for requests containing that path
RewriteRule .* - [F]

That will stop the 200 entries in your logs and properly block the requests with a 403 forbidden. Hopefully the attacker will eventually not waste his bandwidth on blocked requests - for me it took a day before the requests stopped. It will also help you being downgraded by google SEO - although they may be clever enough to recognise these sorts of attacks already.

Worth looking at are deflecting the traffic back to the originator - not as applicable as they are spoofing your own domain. And blocking requests from specific blacklisted IPs - here's a great article: https://raventools.com/blog/stop-referrer-spam/

Neither of the latter are foolproof as IPs can so easily be changed.

Why spoof the referrer? Probably to get around folder permission issues. When the virus was installed it probably changed access to your site files and folders to 775 which allows traffic from your apache web group (e.g. www-data).

You shouldn't be under any immediate risk but it looks like you've been added to a list somewhere that's just going to keep firing requests at you until they either get bored or shut down.

contool
  • 101