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.
David Dede
Stephen Johnston
Tony Perez
Antony Garand
Peter Kankowski
Juliana Lewis
3 comments
I think you may have just uncovered a big issue with how wordpress plugins are not being monitored for these injections. A developer of the plugin may not even know what they are spreading.
I think this is only happening on sites using the plugins, not from the developer. However, you do raise a valid point that the developer may have been hacked and the plugin functions changed. That being said, I would expect the developer to spot it as the function would not operate correctly. But then again, with so much code, it could be almost impossible to detect, especially if the hijacked function is not a major function. In the case of the CForms plugin, it looked to only be a cache function, so it would not have been easy to spot if it had happened on the developers copy.
With CForms, I doubt this came from the developer as that could have been confirmed by sucuri and an update would fix it.
Very interesting post, which makes it hard to scan for injections as it is not obfuscated or encrypted.
Woow a real eye opener thank you for sharing this. I had my site hack several times so this is no stranger to me 🙁
Comments are closed.