My Client’s WordPress Site Was Showing a Stranger’s Webpage — While 967 Hidden Casino Posts Were Sent to Google

The Client’s Complaint: “My Site Is Showing Someone Else’s Website”

The client reached out saying they could not find their own website. When they typed their domain into a browser, they did not land on their site — they landed on a polished, unfamiliar landing page that read “Welcome / Hoş Geldin” in Turkish, with a “🚀 System Active” badge and two buttons labeled “Discover” and “Communication.”

This was not a redirect. The URL was correct. The domain was theirs. The site was just gone — replaced entirely by content they had never created.

The client shared their WordPress admin credentials and access to their Strato.nl hosting control panel. I started in the hosting file manager — not in WordPress — because the attack had reached below the WordPress layer.

What I found was not one problem. It was four separate attack layers, each designed to survive the removal of the others.

Finding Layer 1: The Replaced index.php and the Googlebot Cloaking

The first place I check on any hacked site is the root index.php. WordPress’s legitimate root index.php is a single-line file under 30 bytes — it bootstraps the WordPress load sequence and nothing else. Any file significantly larger than that is a red flag.

What I Saw in the Strato.nl File Manager

Inside the Strato.nl webspace file manager, the root index.php was showing as 4.64 KB — over 150 times larger than a clean WordPress index.php — with a modification timestamp of 04-05-2026 at 13:39, a date the client confirmed they had not touched the file.

Opening the file in Strato’s built-in code editor confirmed the compromise.

How the Cloaking Logic Worked

The malicious index.php was a traffic router. On every page request, it read the visitor’s user-agent string and made a decision:

• If the visitor is Googlebot (or any Google crawler): serve the contents of amp.php — a 22.53 KB file packed with Dutch-language casino spam, designed to be indexed by Google under the client’s domain.
• If the visitor is a real human: display the fake Turkish “Welcome” page embedded directly in the HTML of index.php itself — bypassing WordPress entirely.

This explains why the client saw the wrong page when they visited their own site. Everyone did. The only entity seeing casino content was Google — and Google was indexing it.

This is the reverse of the most common cloaking pattern. Usually, malware hides spam from the site owner and shows it to Google. Here, the fake landing page was shown to humans, while Googlebot received a dedicated spam payload via amp.php. The client had no way to notice the Google-side infection without checking Search Console.

Fixing Layer 1

I uploaded a fresh WordPress 6.9.4 zip directly to the Strato.nl file manager and unpacked it over the existing installation to overwrite every infected core file, including index.php and amp.php.

The fake welcome page was gone. The site was loading again. But this was only the surface layer. Something had replaced index.php in the first place — and unless that mechanism was removed, the file would be replaced again.

Finding Layer 2: The Self-Healing Malware System

I navigated to wp-content and immediately found three components that had no business being there.

Component A — sc-loader.php in mu-plugins

Inside wp-content/mu-plugins/ there was one file: sc-loader.php.

The WordPress mu-plugins directory (Must-Use Plugins) auto-executes any PHP file it contains on every single page load — without any dashboard activation, and without appearing in the standard Plugins list. Anything placed here runs silently and invisibly to a normal WordPress admin.

Opening sc-loader.php showed exactly what it did:

The header comment says exactly what it does: “System Control auto-loader and integrity guard.” On every WordPress page load, it checks whether the system-control plugin exists. If it has been deleted, sc-loader.php copies it back from a backup location and activates it again — automatically, silently, instantly.

Component B — The Hidden .sc-backup Folder

In wp-content/, there was a hidden folder named .sc-backup. The leading dot keeps it invisible in most file managers unless “show hidden files” is enabled.

Inside .sc-backup was a complete backup copy of the System Control plugin.

Component C — The system-control Plugin in wp-content/plugins

The System Control plugin itself lived in wp-content/plugins/system-control.

Why the Three Components Keep Each Other Alive

When I deleted mu-plugins/sc-loader.php, it reappeared within seconds. When I deleted .sc-backup, it also regenerated. When I deleted plugins/system-control, it was restored immediately.

Each component protects the other two:

The only working solution is to remove all three simultaneously, faster than any WordPress page request can fire. Via SSH or a file manager that supports multi-select:

rm -rf wp-content/.sc-backup wp-content/mu-plugins wp-content/plugins/system-control

After running this as a single atomic command, none of the three components returned. The self-healing loop was broken.

Important note: In my specific case, the mu-plugins directory contained only malicious files, so I removed the entire folder safely. If your site uses legitimate must-use plugins, do not delete the whole mu-plugins directory. Instead, remove only the malicious loader file:

wp-content/mu-plugins/sc-loader.php

Note: If the existing case study at regenerating WordPress malware — system control helped you understand the persistence mechanism, this case is the same malware family with two additional attack layers that were not present in that earlier case.

Finding Layer 3: Ghost Administrator Accounts

With the files cleaned and fresh core in place, I ran a full Wordfence scan to catch anything remaining.

After working through the Wordfence results, I opened the Users panel and found multiple administrator accounts the client had never created — all named “web panel”, all marked Inactive, all with zero posts attached.

Ghost admin accounts serve two purposes: they give the attacker a re-entry route if the legitimate admin changes their password, and they act as the post author IDs used by the malware to create spam posts — which feeds directly into Layer 4.

I deleted every unrecognized account and forced a complete password reset on all remaining admin users. See how to find and remove hidden admin users in WordPress for a full walkthrough of this process.

Finding Layer 4: Casino Posts Hidden by an Infected functions.php

This was the layer that confused the client most — and the one I have not seen documented in this exact form anywhere else.

After the file cleanup and account removal, I went to check Posts in wp-admin. The interface showed a contradiction that made no logical sense at first glance:

The “All” counter showed (11). The post list showed “No messages found.”

WordPress Says 11 Posts Exist, But Shows Zero

The post count and the post list disagreed. In a healthy WordPress installation, that cannot happen through normal settings. Something was intercepting the database query that populates the list — but not the query that counts total posts.

The answer was inside the theme’s functions.php.

The Malware Inside functions.php

The theme’s functions.php had been injected with over 800 lines of malicious PHP at the top of the file — but the injection used function names that looked like legitimate WordPress internals: get_sidebar_double(), is_singular_cookie(), get_template_part_compiler(). These names follow WordPress naming conventions closely enough to slip past a casual review.

The injected code used two WordPress hooks to suppress the spam posts:

1. The post list filter: A posts_where hook added a AND post_author NOT IN (...) clause to the database query that builds the admin post list — excluding every post authored by the ghost “web panel” accounts. This made the list show zero results.

2. The count rewriter: A views_edit-post hook intercepted the count numbers displayed in the tab links (“All,” “Published,” “Draft”) and rewrote them using a separate WP_Query — which included the hidden posts in its count, creating the “All(11) but no posts” display inconsistency.

The pre_get_posts hook also limited public-facing queries to posts by the ghost accounts only — meaning the casino spam content was served on the front end while the legitimate 11 client posts were hidden from visitors.

Removing the injected block from functions.php and saving the clean file was all it took. The posts list normalized immediately.

After Cleaning functions.php — The Spam Is Revealed

The connection between all four layers became clear: the ghost admin accounts authored the spam posts → the functions.php malware hid those posts from the admin → the system-control plugin maintained everything and kept it alive → the index.php cloaking sent the spam posts (via amp.php) to Google while showing humans the fake Turkish landing page.

All 967 spam posts were bulk-deleted after confirming the client’s 11 legitimate posts were separate.

The Removal Order That Actually Works

Order matters. If you clean in the wrong sequence, the surviving components re-inject what you just removed.

1. Start at the hosting file manager, not WordPress admin. Going into wp-admin first triggers page loads that allow sc-loader.php to restore deleted components.
2. Replace all WordPress core files with a fresh download matching your installed version. Use Strato’s file manager, cPanel File Manager, or SFTP. This fixes index.php and all other modified core files.
3. Remove all three System Control components simultaneously:

   rm -rf wp-content/.sc-backup wp-content/mu-plugins wp-content/plugins/system-control

   Do this as a single command. Deleting one at a time gives the others time to restore. Important note: In my case, the mu-plugins directory contained only malicious files, so deleting the entire folder was safe. If your site uses legitimate must-use plugins, do not remove the whole mu-plugins directory.

4. Delete amp.php and any unexpected PHP files in the document root that don’t belong to a clean WordPress install.
5. Run a full Wordfence scan and work through every flagged result against official WordPress checksums.
6. Audit Users → delete every unrecognized admin account → force password reset on all remaining accounts.
7. Inspect functions.php in the active theme. Compare the file size and modification date against the original theme version. Remove injected code.
8. Refresh the Posts panel and bulk-delete any spam content that appears after the functions.php is cleaned.
9. Check Google Search Console → Security Issues tab. If the casino pages were indexed, submit a Removal Request and then a reconsideration request after confirming the site is clean.
10. Harden: enable 2FA on all admin accounts, disable PHP execution in wp-content/uploads, lock down wp-config.php, change all hosting/SFTP/database passwords.

How This Attack Got In

Tracing the entry point in this case pointed to a combination of factors common in European hosting environments:

Weak or reused admin credentials. The system-control plugin required admin-level access to install and activate. Either the credentials were brute-forced, phished, or reused from a breached service. The ghost “web panel” accounts confirm the attacker had full admin access at some point.

WP File Manager plugin vulnerability. Older versions of WP File Manager (visible in this site’s plugin list) have had critical unauthenticated file upload vulnerabilities — most notably CVE-2020-25213. An attacker with no credentials could upload arbitrary PHP files and achieve remote code execution. See the comprehensive list of known malicious WordPress plugins for context on which plugins introduce this kind of risk.

Outdated core and plugins. Every outdated plugin is a potential entry point. The risks of using outdated or nulled plugins apply equally to legitimate plugins left unpatched.

What Would Have Prevented This

Two-factor authentication on every admin account. Even with credentials stolen, 2FA blocks login. This is the single highest-impact change you can make. The WordPress login security guide covers the exact setup.

File integrity monitoring. A daily comparison of your root index.php file size against a known baseline would have triggered an alert within 24 hours of the injection — not weeks later when the client noticed the fake page by accident. The best WordPress security plugins guide covers which tools handle this well.

Audit mu-plugins regularly. A healthy WordPress site has zero unexpected files in mu-plugins. If you find anything in that directory you did not place there intentionally, treat it as malware until confirmed otherwise.

Check Google Search Console for Security Issues. The cloaking attack in this case had been running long enough to index casino content under the client’s domain. GSC would have flagged this under Security Issues → Manual Actions before the client noticed the fake homepage — if they had been monitoring it.

Regular offsite backups. The UpdraftPlus backup guide covers how to store clean backups in a location the malware cannot reach. A pre-infection backup makes recovery dramatically faster.

If you need a professional to handle this, my WordPress malware removal service covers this exact type of multi-layer infection with a clean-site guarantee. You can also hire me directly for a full forensic cleanup.

Frequently Asked Questions

Why is my WordPress site showing a completely different website to visitors?

Your root index.php file has most likely been replaced by a malware-modified version. The legitimate WordPress root index.php is under 30 bytes. A replaced file that is several kilobytes larger is delivering an attacker-controlled page to visitors while potentially serving different content (spam or casino pages) to search engines. Check the file size and modification date of your root index.php in your hosting file manager immediately.

Why does my WordPress admin show “All (11)” posts but the list shows “No posts found”?

This specific discrepancy is caused by malware injected into your theme’s functions.php. The injected code uses a posts_where filter to exclude spam posts (authored by ghost admin accounts) from the visible list, while separately running a second query to keep those posts included in the count. The count and the list are powered by different database queries — and the malware only targets the list. Checking your active theme’s functions.php for unusual code at the top of the file (especially large blocks of PHP with WordPress-sounding function names) will identify the injection.

What is the system-control plugin in WordPress?

There is no legitimate WordPress plugin called “system-control.” If you find a wp-content/plugins/system-control folder, a wp-content/mu-plugins/sc-loader.php file, or a hidden wp-content/.sc-backup folder on your WordPress site, these are components of a malware package. The sc-loader.php file describes itself as a “System Control auto-loader and integrity guard” — it monitors for the presence of the system-control plugin and restores it from the .sc-backup folder if deleted. All three must be removed simultaneously.

My deleted WordPress files keep coming back — how do I stop them?

If files you delete reappear immediately, you have a persistence mechanism with multiple mutually-protecting components. In the System Control malware family, sc-loader.php, .sc-backup, and the system-control plugin each restore the others when any one is deleted. Remove all three simultaneously: rm -rf wp-content/.sc-backup wp-content/mu-plugins wp-content/plugins/system-control. If you don’t have SSH access, use your hosting file manager’s multi-select delete feature to remove all three in a single action. See also: why WordPress malware keeps coming back.

What is amp.php doing in my WordPress root directory?

A file named amp.php in your WordPress root directory is not part of a standard WordPress installation. If found alongside a modified index.php that routes Googlebot traffic to it, amp.php is the spam payload — the content (often casino, pharmaceutical, or Japanese keyword spam) being served exclusively to search engine crawlers while human visitors see something else. Delete it immediately and replace all core files with a fresh WordPress download.

Can malware target Dutch or European websites specifically?

Yes. The casino spam in this case was specifically in Dutch and targeted the Netherlands and Belgium gambling market. Attackers often localize their spam payloads to match the target audience of the compromised domain — a Dutch-language website on Strato.nl hosting will have better SEO authority for Dutch-language gambling queries than a generic domain. This is why European hosting environments, including Strato.nl, TransIP, and SiteGround NL, are increasingly targeted for casino SEO spam injections.