1

My shared hosting with GoDaddy was hacked by injecting a PHP file (deade6.php) that is recreated every time I delete it. I also tried to modify the .htaccess but it gets recreated as follows: 

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} google [OR]

RewriteCond %{HTTP_REFERER} google

RewriteCond %{REQUEST_URI} !

(\.js|\.css|\.png|\.jpg|\.jpeg|\.gif|\.svg|\.ttf|\.woff|\.eot)

RewriteRule ^.*$ deade6.php [L]

</IfModule>

I also found some suspicious PHP file with base64_decode and I deleted them.
But nothing works. Any idea how to remove it?

Anders
  • 65,052
  • 24
  • 180
  • 218
Peter1122
  • 11
  • 1
  • 3
    We have a [canonical question about de-obfuscating malicious PHP code](http://security.stackexchange.com/questions/115461/i-found-unknown-php-code-on-my-server-how-do-i-de-obfuscate-the-code). It might be useful to you. – S.L. Barth Jan 05 '17 at 12:34
  • 2
    Don't bother with that htaccess, but try to figure out how attacker hacked you. – Mirsad Jan 05 '17 at 12:55

2 Answers2

0

The htaccess files possibly get regenerated by the webserver when the request is made to a specific entry point. This should be a commonly used file, such as index.php.

Find and remove the relevant code from the webapp files. If you have shell access,

grep -rnw '/var/www/whatever/path-to-your-webroot' -e "deade6"

It worths having a look at /var/log/apache2/error.log and /var/log/apache2/access.log (or find an equivalent log menu at your hosting provider) as well.

Also, if nothing works, in the very final case, you can still install nginx, which ignores .htaccess, so the pages dont get the malicious php rendered while you can work on fixing the issue.

Rápli András
  • 2,144
  • 1
  • 11
  • 24
  • 2
    "you can still install nginx" Not if you are on shared hosting, then your probably can't install anything. – Anders Jan 05 '17 at 13:42
  • 1
    While it wouldn't hurt to try, I wouldn't expect to find any results for 'deade6' showing up in a grep. Most likely the URI used to download the file is obfuscated wherever it exists in the code. You might have better luck grepping for "eval(" statements. – Ivan Jan 05 '17 at 16:53
0

Finding the virus and remove them is useless until you find the way the virus was coming and block them!

Ok, you've been found any special file, but how was this file appearing?

You may have to upgrade your interactive website before anything. Check changelog for information about security flaws. Be sure you find the way the attacker was coming in!!

The best way to ensure everything are clean is to rebuild the whole installation with clean sources and up-to-date engines.

  1. Save your data (database and personal files)
  2. Ensure finding the way was comming
    1. check server logs (use timestamp, the modify time of the file but of his directory too)
    2. use tcpdump to trace every network dialog, in particular just before suspect file are installed. (For this, I've used: tcpdump -i eth0 -s 0 -C 100 -w tcpdump..)
  3. Check your data for suspect entries or changed files
  4. Re-build your server from scratch (I don't know how GoDaddy works, but you must by able to rebuild or empty your space)
  5. Re-install your data
F. Hauri - Give Up GitHub
  • 4,616
  • 2
  • 20
  • 32
  • Who downvote this... And why? – F. Hauri - Give Up GitHub Jan 05 '17 at 14:23
  • i didn't downvote, but poor grammar aside ("datas" makes me cringe), godaddy's shared plans don't really let you "rebuild from scratch"; you can basically just turn things on or off. – dandavis Jan 05 '17 at 15:32
  • @dandavis, I didn't understand OP if he is running shared hosting or he is on shared hosting, it can be dedicated server or VPS. – Mirsad Jan 05 '17 at 15:40
  • 2
    You forgot an important point between emptying and rebuilding: Find the vulnerability which allowed the exploit to come onto the server in the first place and plug it. Otherwise you will soon have to redo this. – Philipp Jan 05 '17 at 15:43
  • @Philipp This was my meaning, speking about security flaws in changelog. – F. Hauri - Give Up GitHub Jan 05 '17 at 15:53
  • @F.Hauri that assumes the problem is a vulnerability in the vendor code and not in the config or errors in how it was set up, or the large list of other things it could be. – schroeder Jan 05 '17 at 16:07
  • @schroeder I agree, this is not exhaustive, but it's a good start point... I most case, attackers use known exploits and won't be able to use them on very last version of majority of maintened *CMS*. Ok this is not perfect, but for more, *user* have to become an *expert*. – F. Hauri - Give Up GitHub Jan 05 '17 at 22:29