<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-5HLVVHN" height="0" width="0" style="display:none;visibility:hidden">

An Analysis of WordPress Malware

Dec 6, 2019 6:42:24 PM / by Imunify’s Malware Intelligence Team

wordpress-malware (1)
When it comes to building and managing professional-quality web sites, content management systems have become the default way to do that. WordPress is by far the most popular CMS: it’s used to build and manage around six out of every 10 sites.

The popularity of WordPress makes it a prime target for hackers. In one of our regular investigations, we recently encountered a particular strain of malware that targeted it. Here’s an analysis of that malware that we’d like to pass on to sysadmins.


  1. It’s disguised.
        The malware file is peppered with Base64 encoded strings, as well as long variable names. This complicates the code, making it more difficult to analyze.
pasted image 0 (3)

     2. It has a self-destruct module.

     The file is designed to self-destruct and delete itself if any of the _REQUEST variables has the  name delete.

        pasted image 0 (4)


      3. It fetches a remote file.
      It makes a request via the $_REQUEST parameter for an additional file. As you can see from  the code below, it also targets the Joomla CMS.

          unnamed (5)          

              Even if prudent sysadmins disable allow_url_fopen in php.ini, it still tries to fetch the file using curl.

    4. It searches for infectable directories.

    Sometimes, webmasters use the domain name of a site as the directory name of the webroot. For example, the domain xyz.com could have the webroot /var/www/html/example.com.

    If this is the case, the webroot is used by this malware to try and identify directories that can be infected. 

        unnamed (6)

        This is just one of the means by which this malware tries to identify infectable directories. For example, this function gets the user information of the process owner and uses that to check files under var/named, which it then cross-references with files in /etc/valiases.


    5. It inserts the remote file.

    Once it has identified infectable directories, it uses the process function to deliver the file it fetched remotely.


      First, the process function checks to see if the directory is writable, and if it’s part of a WordPress or Joomla CMS.

      If it is, then inject_wordpress_main_php is called.


This, in turn, places the contents of the remotely-fetched file into a crucial WordPress file, such as:


Finally, the process function checks to see if a keyword supplied with the request (in the form of $_REQUEST[‘keyword’] or the default keyword (ttmaintt) is part of the response when the infected URLs are accessed.

unnamed (7)


unnamed (8)



All the files that we encountered during our investigations were associated with the filename 




This malware employed SHA256 hashes:




It defined a total of 35 functions:

- check_config

- is_dir_empty

- in_array_partial

- bool_to_string

- process

- is_cms

- get_search_keyword

- assert_main_php

- get_wordpress_main_content

- get_joomla_main_content

- get_main_content(

- inject_wordpress_main_php

- inject_joomla_main_php

- inject_main_php

- get_current_user_name

- get_user_domains

- remove_tld

- is_wordpress

- is_joomla

- get_dirs_recursive

- get_domains_dir

- get_valid_dirs

- could_be_domain

- get_dirs

- have_tld

- is_domain

- is_domain_partial

- get_common_dirs(

- get_tlds

- clean_domain

- not_www

- get_domain

- remove_www

- estimate_current_path

- url_get_contents



You’ll have to go beyond commonly-used defense strategies, as this WordPress malware takes them into account.

For example, disabling allow_url_fopen in php.ini provides no protection against it. If you do that, the malware just uses the curl module instead. You could disable both of these modules, but it’s likely that you’d disable WordPress as well.

You could use a firewall to block all traffic that the web server is generating independently, to make sure that this malware can’t fetch the remote file. However, this would also block all legitimate traffic that WordPress uses for its normal operations, such as updates.

The best way to protect against this malware is to:

  • Check the integrity of your WordPress files using tools like wp-cli.
  • Scan your web site regularly with antivirus software.
  • Avoid downloading software from unofficial sources.
  • Log and check your web site traffic using logs from mod_forensics or mod_security.

Of course, if you’re an Imunify360 customer, your servers are already protected against this sort of malware. Regardless of your server setup, we hope you found this analysis informative and useful.


Topics: malware, security, Antivirus, Advice

    Subscribe to Email Updates

    Ready to try Imunify?

    30-DAY TRIAL

    Recent Posts