Manipulating WordPress Plugin Functions to Inject Malware
Most authors of website malware usually rely on the same tricks, making it easy for malware researchers to spot obfuscated code, random files that don’t belong, and malicious lines injected at the top of a file. However, it can become difficult when the malware is buried deep within the lines of code on normal files.
Why is some malware harder to spot than others?
An attacker’s primary goal is to retain access to an infected site, so they go to great lengths to hide their access methods. There may be hundreds of malicious files that are easy to find. As long as the attacker can regain access, ultimately reinfecting your website, it doesn’t really matter how clever they are in hiding the payload. It’s why it is so important to place extra emphasis in identifying the access vector, most often known as a backdoor.
Hijacking legitimate functions inside plugin files
Recently, we came across strange malware deep within a file, and hidden in an unusual way. The malicious code was hijacking a legitimate function inside the CForms plugin.
At first glance, this plugin file seemed benign because the flagged piece of code was not obviously malicious. On closer inspection, the original plugin function had, in fact, been commented out and replaced by a function with the same name that contained the malicious code.
The original function code was preserved, and the malware added to the existing function. This helps increases the malware lifespan by not breaking the plugin. If it stopped working, then the webmaster would notice, and take action to correct it. It’s unclear why the code was commented out in this way, but it could indicate that the malware author was testing whether his additional code would break this particular function.
The code is a cookie-based backdoor, making it difficult to detect in normal access logs since (mainly because cookie information is not logged by default because of the noise it creates). When present inside the CForms plugin file, this piece of code allows the attacker to gain access to the site files.
Malicious code injections are becoming more sophisticated
It’s unusual to find malware hidden like this, but we’ve seen it before.
It’s well-written code that is hard to spot, and isn’t obfuscated at all. The question remains as to whether this was a manual infection, or if the attacker knew the plugin code well enough to automate an attack to hide the malicious code. Searching for part of the code on gitHub, our team found two other sites infected with similar code, both of them in MailPoet files.
It’s possible that we may see similar function-hijacking infections becoming more popular as a method to keep backdoors open for business. If ever in doubt, it’s always good to perform some form of integrity checking against known goods.