We have previously talked about malware that essentially “disables” security enhancements that have been put in place either manually by the owner or through the use of a security plugin installed in WordPress. Where attackers may run into a problem is that a security plugin typically monitors files and if it detects any changes, it notifies the owner either via email or through the WordPress dashboard.
Unfortunately, a “PHP malware” solves the above problem for the attacker by disabling the most commonly used security plugins and preventing them from being re-enabled from the WordPress dashboard.
Finding and disabling security plugins
This GIF shows a WordPress installation with a number of plugins enabled,
four of which are popular security plugins and the other two are not. The GIF clearly demonstrates how the non-security plugins are not affected by the PHP malware, but the rest of the security plugins are disabled.
If a user tries to re-enable one of the disabled security plugins, it will momentarily appear to be enabled and then the malware will immediately disable it again. This behavior will continue until the malware is completely removed from the compromised environment, making it more difficult to detect malicious behavior on the site.
How does it work?
The malware was detected in the malicious file ./wp-includes/IXR/class-IXR-cache.php. It starts by assigning the site's root directory to DIZIN to help hide the loading of the core WordPress file wp-load.php:
Using require_once to load wp-load.php allows the attacker to use hooks and WordPress coding variables to disable security plugins. First, the attacker defines the findinSecurity function which is later used to sort the array containing the plugins.
Another function defined by the attacker is secList which contains an array of targeted plugins that will be searched in existing plugins and disabled.
The two functions findinSecurity and secList are then used in the main active_plugins function which uses the WordPress hook get_option('active_plugins') to get a list of all active plugins from the WordPress database . It then uses findinSecurity along with the list of targeted security plugins from SecList to search for active plugins and deactivate them using the WordPress hook deactivate_plugins.
So, how does the malware automatically targeted security plugins in case someone tries to re-enable them? It does this by injecting malware into the bottom of the wp-load.php file.
The injection forces wp-load.php to load the malicious file ./wp-includes/IXR/class-IXR-cache.php through the use of require_once. Since wp-load.php is executed on every page load on a WordPress site, any plugins that were re-enabled will be automatically disabled on the next load – regardless of whether it comes from the same user or a new visitor to the site’s homepage.
