Keeping WordPress websites secure requires constant attention. In a recent case we came across a particularly sneaky type of attack that had been running unnoticed on a client's website for years. This story shows how sophisticated modern hacking techniques are, and why proactive website maintenance is essential.<\/p>\n\n\n\n
The website we examined showed a strange pattern: Google Search Console was warning about spam content, while visitors noticed nothing unusual. For the owner everything worked fine, the admin area looked flawless and the pages loaded.<\/p>\n\n\n\n
This type of attack is called cloaking<\/strong>, and it is one of the most dangerous WordPress security threats. The essence of the method is that the malicious code can tell different types of visitors apart:<\/p>\n\n\n\n This kind of attack is especially dangerous because it can run for months, even years, without anyone noticing. The client sees nothing suspicious, visitors don't complain, while in the background the site's search engine optimisation and reputation are being damaged all the time.<\/p>\n\n\n\n The infection was first flagged by Google Search Console warnings. Two critical messages came in:<\/p>\n\n\n\n These signals called for an immediate professional investigation. Experience shows that when Google sends warnings like these, the problem is already serious and long-standing.<\/p>\n\n\n\n During a detailed review of the website's file system, we identified several suspicious and clearly infected files. The most shocking discovery was that the infected files were hiding in WordPress's Together these files formed a complex system whose job was to load spam content dynamically, segment users, and bypass WordPress's basic security mechanisms.<\/p>\n\n\n\n The investigation revealed that the infected files weren't only in the uploads folder. The biggest problem was caused by a modification to the The injected code did exactly the following:<\/p>\n\n\n\n This last point explained the previously inexplicable fact that the site's layout was sometimes “broken”. The infection periodically switched off the performance optimisation plugins the site needed to work properly.<\/p>\n\n\n\n The effectiveness of cloaking malware comes from its invisibility. Several factors help these attacks stay hidden for years:<\/p>\n\n\n\n According to expert estimates, a well-hidden cloaking infection can go unnoticed for as long as 3 to 5 years, constantly damaging the site's search rankings and reputation.<\/p>\n\n\n\n The investigation revealed that the site was running an old appointment booking system that the owner had previously insisted on keeping. This was the source of the problem:<\/p>\n\n\n\n Abandoned plugins like this are hackers' favourite targets. Automated bots constantly scan websites looking for components with known vulnerabilities. When they find one, running the exploit is child's play:<\/p>\n\n\n\n This scenario fits the pattern we saw perfectly.<\/p>\n\n\n\n Removing the infection completely took careful, multi-step work:<\/p>\n\n\n\n Throughout the process, the most important thing was completeness. A single infected file or line of code is enough for the attack to come back.<\/p>\n\n\n\n The long-term consequences of cloaking infections can be disastrous:<\/p>\n\n\n\n These problems can sometimes last for weeks or months, even after the infection has been completely removed, until Google re-indexes and re-evaluates the site.<\/p>\n\n\n\n This case teaches several important lessons about WordPress security:<\/p>\n\n\n\n Don't use outdated plugins!<\/strong> If a plugin hasn't been updated for more than 6 to 12 months and the developer doesn't respond, remove it from the site. No feature is worth the security risk.<\/p>\n\n\n\n The uploads folder is not for storing executable code.<\/strong> Any .php or other script file in this folder is an immediate red flag.<\/p>\n\n\n\n Theme files are off limits.<\/strong> functions.php and other critical files should never be modified by hand or by automation unless you know exactly what you are doing.<\/p>\n\n\n\n Cloaking can only be detected by an expert investigation.<\/strong> An everyday user won't notice anything, which is why regular professional website audits are necessary.<\/p>\n\n\n\n A WordPress kiv\u00e1l\u00f3 tartalomkezel\u0151 rendszer, de biztons\u00e1goss\u00e1ga teljes m\u00e9rt\u00e9kben a karbantart\u00e1s<\/a> min\u0151s\u00e9g\u00e9t\u0151l f\u00fcgg. Egy professzion\u00e1lisan karbantartott weboldal:<\/p>\n\n\n\n A single abandoned, unupdated plugin is enough to infect a website for years without the owner ever noticing the problem, until it's too late.<\/p>\n\n\n\n This case study shows how sophisticated and invisible modern hacking techniques can be. With cloaking malware, the attack succeeds precisely because normal use shows no sign of the infection.<\/p>\n\n\n\n We successfully removed the infection from the website, and the system is now clean and secure. But the case is a reminder: website security is not a one-off task but an ongoing activity that requires expertise, attention and proactive thinking.<\/p>\n\n\n\n\n
Discovering the problem: Google Search Console warnings<\/h3>\n\n\n\n
\n
Results of the in-depth investigation<\/h3>\n\n\n\n
uploads<\/code> folder, a place that normally only holds uploaded images, videos and documents.<\/p>\n\n\n\nThe infected files we found:<\/h4>\n\n\n\n
\n
eere.htm<\/code> : an HTML file used to store spam content<\/li>\n\n\n\nroot.htm<\/code> : more malicious HTML content<\/li>\n\n\n\nhuc.php<\/code> : a PHP script that ran the cloaking logic<\/li>\n\n\n\nhuv.php<\/code> : an additional infected PHP file<\/li>\n\n\n\nlicense.txt<\/code> : a fake licence file that actually contained the cloaker's configuration<\/li>\n<\/ul>\n\n\n\nThe most dangerous discovery: a modified functions.php<\/h3>\n\n\n\n
functions.php<\/code> file in the site's active theme. This file is the most critical component of a WordPress theme and fundamentally affects how the site works.<\/p>\n\n\n\n\n
deactivate_plugins()<\/code> function<\/li>\n<\/ol>\n\n\n\nWhy are cloaking attacks so hard to spot?<\/h3>\n\n\n\n
\n
The likely origin of the infection: a vulnerability in an outdated plugin<\/h3>\n\n\n\n
\n
\n
Steps of the clean-up process<\/h3>\n\n\n\n
\n
What would have happened if we hadn't noticed in time?<\/h3>\n\n\n\n
\n
Key lessons<\/h3>\n\n\n\n
Why is ongoing maintenance essential?<\/h3>\n\n\n\n
\n
Summary<\/h3>\n\n\n\n