Case Study: Solving the wp-blog-header.php Regenerate Malware Nightmare
A client recently hired me to fix a badly hacked WordPress website. The client was exhausted. They gave me full FTP and wp-admin access to their shared hosting account and explained their frustration: no matter how many times they cleaned the infected core files, the hack kept coming back within minutes.
The site was using Wordfence, which is normally a solid security plugin, but it was completely blind to the root cause of this issue. The core of the problem was a classic, stubborn case of the wp-blog-header.php regenerate malware.
In this detailed case study, I will walk you through my exact process. I will break down how the malicious code worked, explain why standard automated scanners missed it, share the custom PHP script I wrote to hunt down the hidden backdoor, and show you how to break the reinfection loop for good.
Understanding the Target: Why wp-blog-header.php?
Before we look at the malware, it helps to understand why the hackers targeted this specific file.
In a standard WordPress installation, wp-blog-header.php is a core file located in the root directory. Its job is simple but critical: it loads the WordPress environment and the template. Because this file is executed every single time a visitor (or a search engine bot) loads any page on the website, it is a prime target for hackers.
If an attacker can inject their code into wp-blog-header.php, they guarantee that their malicious payload will run on every page load. However, simply cleaning this file isn’t enough when dealing with the wp-blog-header.php regenerate malware. The attackers know you will try to delete their code, so they hide a secondary file—a “dropper” or backdoor—somewhere else on your server to constantly rewrite the infection.
Breaking Down the Malicious Payload
To defeat the enemy, you have to understand how they operate. When I opened the infected wp-blog-header.php file, I didn’t just find a few lines of spam. I found a massive, highly sophisticated block of custom PHP injected right at the top of the file before the legitimate WordPress code even had a chance to run.
Here is an analysis of the exact malicious code we found, and how the wp-blog-header.php regenerate malware functioned to hijack the site’s SEO.
1. Highly Targeted Page Hijacking
Unlike spray-and-pray hacks that ruin the whole site, this malware was surgical. It checked the current URL being requested ($current_url). The attackers specifically targeted high-value inner pages of the client’s site, such as /our-unicorn-bags/ and /bulk-mushroom-substrate/. If the visitor was on any other page, the malware stayed quiet.
2. IP and Fingerprint Tracking
The script contained a robust, custom get_client_ip() function. It looked through headers like HTTP_X_FORWARDED_FOR and HTTP_CLIENT_IP to bypass proxies and find the real IP address of the visitor.
It then created a unique “fingerprint” using the visitor’s User-Agent, IP address, accept language, and encoding. If the script recognized this fingerprint as a security scanner, a known bot, or a server admin, it used a 302 redirect (header("Location: " . $reff_url);) to send the request away. This is an evasion tactic to make the malware invisible to the site owner.
3. SEO Spam Cloaking (The Bot Check)
This was the primary goal of the attack. The code used a regular expression to check if the visitor was a search engine:
$botchar = "/(googlebot|slurp|adsense|inspection|verifycation|jenifer)/i";
If a Googlebot visited one of the targeted pages, the malware used curl or file_get_contents to silently pull spam content from external servers hosted on Cloudflare Pages (e.g., official-console-p2.pages.dev/MAHJONG222/source.txt). It then served this spam text to Google. This tricks the search engine into indexing the client’s legitimate URLs for Indonesian gambling, slots, and betting keywords like MAHJONG222, TOTO90, and GOPAY303.
4. Hijacking Real Human Search Traffic
If a real person clicked on the client’s website from a Google, Yahoo, or Bing search result, the malware intercepted the visit. It checked the HTTP_REFERER. Because the person came from a search engine, the malware immediately redirected them to an external betting link (like s.id/C8dty).
If a user typed the URL directly into their browser, the HTTP_REFERER would be empty, and the site would load normally. This cloaking is exactly why the client had a hard time replicating the issue themselves.
Why Standard Scanners Missed the wp-blog-header.php Regenerate Malware
The client was frustrated because they were using shared hosting and relying on Wordfence. They kept cleaning the file, and Wordfence kept saying the site was clean, but the wp-blog-header.php regenerate malware kept returning.
Why did the scanners fail? Automated security plugins are built to look for known virus signatures, base64 encoded payloads, or common exploit strings like eval().
However, the file responsible for putting the malware back—the “dropper”—did not look like a virus. It was a tiny PHP script that simply used native PHP file-writing functions. Because it looked like completely normal PHP code, standard scanners glossed right over it, assuming it was a harmless part of a plugin or theme.
The Custom Solution: Hunting the Backdoor
Since commercial tools were blind to the threat, I had to write a custom scanner. To stop the wp-blog-header.php regenerate malware, I needed to find the hidden dropper file.
I knew two specific things about this hidden file:
- It had to know the name of its target. Somewhere in its code, it had to contain the string
wp-blog-header.php. - It had to use a native PHP function to rewrite the file, most likely
file_put_contents.
Writing the hunter.php Script
I wrote a custom script called hunter.php and uploaded it to the root public_html directory via FTP. Instead of looking for virus signatures, this script scanned every single PHP file on the server looking for the specific behavior of the dropper.
Here is the exact code I used to find the malware:
<?php
// We are scanning the entire public_html directory this time
$dir = __DIR__;
echo "<h3>Hunting for backdoors targeting wp-blog-header.php...</h3><hr>";
// Set up directory iterators to scan all nested folders
$iterator = new RecursiveDirectoryIterator($dir, RecursiveDirectoryIterator::SKIP_DOTS);
$files = new RecursiveIteratorIterator($iterator);
$found = false;
foreach ($files as $file) {
// Skip the actual wp-blog-header.php file so we don't flag the victim file
// Also skip the hunter script itself
if ($file->getFilename() === 'wp-blog-header.php' || $file->getFilename() === 'hunter.php') {
continue;
}
// Only look inside PHP files
if ($file->isFile() && pathinfo($file, PATHINFO_EXTENSION) === 'php') {
$contents = @file_get_contents($file->getPathname());
// Look for scripts that mention the target file AND contain file-writing functions
if ($contents !== false &&
strpos($contents, 'wp-blog-header.php') !== false &&
strpos($contents, 'file_put_contents') !== false) {
// Output the exact path to the malicious dropper
echo "🚨 <strong>Malware Dropper Found:</strong> " . $file->getPathname() . "<br>";
$found = true;
}
}
}
if (!$found) {
echo "<p>✅ <strong>Scan finished.</strong> No exact behavioral match found. The payload might be differently encoded.</p>";
}
echo "<hr><p><em>Delete hunter.php after running.</em></p>";
?>The Discovery and Cleanup
I ran the hunter.php script from my browser. Because it was scanning behavior rather than signatures, it took only a few seconds to pinpoint the exact file that Wordfence had missed.
The output on my screen looked like this:
🚨 Malware Dropper Found: /home/.../public_html/wp-content/themes/Divi/includes/builder/frontend-builder/assets/vendors/tinymce-skin/fonts/ext.php
The attackers had hidden their dropper deep inside the active Divi theme folder. They disguised it by placing it in a fonts directory and naming it ext.php. Whenever the site was loaded, a cron job or a hidden include would trigger this fake font file, which would then rewrite the malware back into the root directory.
I connected via FTP, navigated to that specific path, and deleted ext.php. Then, I cleaned the root file one last time. The reinfection loop was finally broken. The wp-blog-header.php regenerate malware was gone for good.
Key Takeaways:
- Behavior Beats Signatures: Standard scanners fail when backdoors use native PHP functions. To stop a repeating infection, you must scan for behaviors (like using
file_put_contentscombined with the target filename) rather than just known virus definitions. - Malware Cloaking is Deceptive: Modern SEO spam serves completely different content to search engine bots, human searchers, and direct visitors. You must test hacked sites by spoofing your browser’s User-Agent and Google search referrers to see what the hackers are truly hiding.
- Hackers Hide in Deep Folders: Attackers love to bury their dropper scripts in trusted, deeply nested directories (like theme vendor assets or font folders) to avoid manual detection.
- Custom Scripts Work: When commercial security plugins fail on shared hosting, writing a targeted, recursive PHP script to search your entire directory tree is often the most effective way to isolate a backdoor.
Frequently Asked Questions (FAQ)
What is the wp-blog-header.php regenerate malware?
This is a specific type of WordPress hack where malicious code is injected into the core wp-blog-header.php file. When you delete the bad code, a hidden secondary script (a backdoor or dropper) detects the cleanup and automatically rewrites the malicious code back into the file, creating a frustrating loop.
Why does my WordPress site keep getting hacked after I clean it?
If your site gets reinfected minutes or hours after you clean it, you haven’t found the root cause. Hackers leave behind backdoor files. Until you find and remove the script that is generating the malware, your site will continue to be compromised.
Can Wordfence or other plugins fix the wp-blog-header.php regenerate malware?
Sometimes, but not always. Security plugins are excellent, but they rely heavily on pattern matching and signatures. If a hacker writes a custom PHP script that uses basic file-writing commands (which look like normal website code), automated scanners will often ignore it. This is why manual investigation and custom scripts are often required.
How do I prevent this from happening again?
After removing the malware, you must secure the site. Update all themes and plugins, change all FTP, database, and wp-admin passwords, and consider adding server-level protection. You can use .htaccess rules to block the execution of PHP files in directories where they don’t belong (like the wp-content/uploads folder or theme asset folders).
