The Strange Case of the Malicious Favicon

The Strange case of the Malicious Favicons

During the past year, our Remediation department has seen a large increase in the number of fully spammed sites.

The common factors are strangely named and unusually located favicon.ico files, along with the creation of “bak.bak” index files peppered around the website.

In the majority of the cases, the pattern is similar regardless of the size of the website or the CMS being used. We have found WordPress, Magento, Joomla, and even HTML-only sites impacted by this campaign.

The Pattern

The infected sites present the following symptoms:

  • Randomly named folders with spam files clearly inside the directories, along with big spam sitemap files. Sometimes these spam files are spread randomly throughout the server.
  • Most of the time, the site has been flagged as “May be hacked” by Google (or has been directly blacklisted by other authorities) along with subsequent SEO penalization.
  • Strange “favicon.ico” files with a randomized string of characters and numbers at the end of the name. These are found spread around the site in random folders, especially in ./plugins, ./extensions, ./components, ./modules, ./uploads, ./media, ./themes, ./templates, or ./skin folders.

For example, this file was found on an infected Joomla website:


The Code

The content of these supposed .ico files are not actually icon image codes at all. Instead, they follow this pattern using PHP as the programming language:

  1. Check for a defined semaphore with the starting string “ALREADY_RUN_”, followed by a random hexadecimal string that most likely represents a hacking kit identifier.
  2. A Random-named function with two parameters: a translation key and a dirty-base64 code. Using the translation rules from the first parameter into the second, this function returns the base64 de-codification of the dirty-base64 code.
  3. Declaration of the dirty-base64 code variable with a random name.
  4. Declaration of the associative array with the translation key characters and their corresponding values, also randomly named.
  5. Eval function to start the script.
  6. Commented 32 MD5 char sequence + encrypted code.

Here’s an example of what the code generally looks like:

PHP code example for the supposed .ico files ALREADY_RUN_
PHP code example for the supposed .ico files
Second example of the code structure ALREADY_RUN_
Another example of the code structure

Unraveling the Skein

The process to understand what’s really going on behind the scenes requires several steps.

Basically, the base64 code generated by this fake favicon is made up of a group of functions. These functions decrypt the commented code into the final block,which is the real backdoor code.

This backdoor (usually overlooked during analysis as a comment) is made of an initial block of 32 characters corresponding to a MD5 hash, followed by the base64 code of the backdoor.

After some iterations, where you can observe how this backdoor can be configured depending on the case, the final code reveals a CURL object.

By using a POST connection, the attacker can en-route what is going to be downloaded from the site. This sometimes only includes content and files, but we occasionally see code injected into files just before the </head> or the </body> tag, depending on how the attacker has remotely configured the fake favicon.

HTTP_REFERER HTTP_USER_AGENT Details of the config matrix, where the target remote process (engine.php) returns directions to the site.
Details of the config matrix, where the target remote process (engine.php) returns directions to the site.

The Trigger: Cloned .bak.bak Index Files

So, how does the attacker trigger this complex process if the file is not a PHP file, which can be interpreted and is not located in the root folder, but instead in a random location on the server?

The magic occurs by cloning the index file of the site, appending “.bak.bak” to the file name, and creating a new index file with the following content:

  • An include of the favicon file with a relative path.
  • An ”@” before the include ensures that any error coming from the included file will not be displayed on the website, hiding it from visitors.

The original code is then loaded from the “.bak.bak” file.

Here is an example of the fake index.php file in an HTML-only environment:

Fake index.php file

And here is an index.php file found on an infected WordPress installation:

WP_USE_THEMES and include

Example of an affected WordPress index.php file before and after the include has been decoded

What this means for site visitors is that the process is fully transparent — they will receive the legit code immediately after the favicon malicious code is executed on the server.

Every time one of these index.php files loads (which for CMS’ such as Joomla or WordPress, is executed on almost every visited page), the backdoor is executed. This ensures that site reinfections occur very quickly, allowing bad actors to maintain access and continue spamming on the compromised website.

Environment Details

The infection is similar to the hacking kits sold on the darknet to cybercriminals, giving them the ability to create and manage a network of zombie (infected controllable) sites.

This kind of kit crawls the Internet, searching for sites with specific vulnerabilities and listing them in a dashboard where they can be used by the attacker. These kits allow bad actors to configure the sites in groups, or on an individual basis.

The presence of identification tags (unique combinations of numbers and letters that appear in the code and the process) suggests that this campaign helps the attackers organize them internally.


If you believe that you’ve been impacted by this malware, check out our post on how to find and removal malware in favicon (.ico) files for step-by-step instructions on how to locate it on your website.

It’s believed that the following vulnerabilities are being leveraged to inject these fake favicons:

  • Old software versions that have not been patched with the latest versions or security releases. This includes CMS software, server software, plugins/modules/extensions/components, themes/skins/templates, etc.
  • Backups or demo/test sites, which are very weak infection vectors because they are not usually well maintained.
  • Upload forms that have not been properly sanitized or hardened, especially on handmade websites.

Due to the nature of the backdoor trigger of this campaign, reinfection and cross-site contamination can be very quick. Our Spanish-speaking audience can check out this recent presentation at WordCamp Madrid, where I discuss backdoors in further detail.

If you observe any suspicious behavior on your site or detect the presence of these “.bak.bak” files (or other unusual favicons), we’d be happy to help clean up the infection.

In the meantime, you can check your site for known malware, blacklisting status, and out-of-date software by using our free scanner Sitecheck:

You May Also Like