Cloaking Malware: The Storefront Only Google Ever Sees

You check again. You still see your real site. So does everyone you ask to check for you. This isn't a glitch on your end, and it isn't the customer misremembering a URL. It's a specific category of WordPress malware called cloaking, built entirely around one idea: show a clean site to the person looking, and a different one to the crawler indexing it.

This post breaks down a cloaking kit researchers have nicknamed parasiteCode, why a normal file scan and a normal visit both come back clean against it, and what you can actually check yourself, no PHP reading required.

How the attack works

Most WordPress malware doesn't care who's looking. A defacement shows the same message to everyone. A drive-by redirect sends every visitor to the same scam page. Cloaking malware is different: it inspects who's asking before deciding what to serve.

When the request looks like it's coming from Googlebot, it serves a fake storefront, complete with product pages, prices, and the metadata search engines expect: a page-type tag identifying it as a product, a canonical link pointing back at the site's own domain. When the request looks like an ordinary browser, it quietly steps aside and lets the real site load. The two versions never meet, because the two audiences never see the same version.

That split is what makes it effective. Google indexes the fake catalog under the domain's own authority. Anyone who searches the business name can be served one of those indexed product pages instead of the real homepage, landing on a lookalike store. Meanwhile every human who checks the site directly sees exactly what should be there, which is why site owners, and sometimes the people cleaning the site for them, walk away convinced nothing is wrong.

Anatomy of the kit

This particular family combines three separate evasions, and each one defeats a different kind of check.

1. The kit lives outside the website entirely

The templates for the fake store, the fabricated product catalog, and the logic deciding who gets what, none of it sits inside the WordPress installation. It lives in the server's own temporary storage area, in a folder named after an internal site ID (something like a numbered folder holding a handful of .gz files alongside an index.php and a set of JSON files that get regenerated with fresh fake products daily). No malware scan that only looks inside the website's own folder will ever reach it, because it isn't a website file. It's loaded at runtime through a PHP feature that treats a path as compressed data on the fly, so nothing ever gets extracted where a scanner could see it.

2. The loader doesn't look like code

Exactly one file inside the actual WordPress installation ties into that outside folder, and it's placed inside a legitimate plugin's own subfolder, typically one meant for a specific theme integration the site may not even use. That file doesn't end in .php, .js, or any recognizable extension. A scanner, or a person, searching for suspicious code by file type walks right past it, because by every filename convention it isn't one.

3. The activation is spread across hundreds of lines

The code that actually wires the loader in isn't one suspicious block. It's three unremarkable-looking lines, planted hundreds of lines apart inside a genuine, otherwise-unmodified plugin file: one line builds a folder path, a second line prefixes that path with the compressed-data marker, and a third line, much further down the file, is the one that actually includes it. Read any single line in isolation and it looks like unremarkable plugin code. Reviewing a diff or a single suspicious line never surfaces it. Only reading the full execution path does.

How this actually gets confirmed

Catching this reliably takes one specific test: send a request that identifies itself as a search engine crawler, and compare everything the server loads to what it loads for an ordinary visit. The two runs should include the exact same files. When they don't, the file that appears in the crawler's list right before the fake content starts rendering is almost always the loader. This is a mechanical, repeatable test, not a guess, and it's the only method that has reliably caught this family after signature scans, file-modification-time checks, and database searches all came back clean.

Indicators to check

The following details describe the malware's own infrastructure, not any affected site. They're offered for identification, not as an accusation against any service.

Deployments of this kit have been observed phoning home to a remote control server, with requests structured around a per-site identifier and a matching API key sent as a custom header. The kit also exposes a hidden maintenance endpoint that, when called with the right key, forces the server to reload its cached code, which is how the operators push updated fake product listings without re-infecting the site. If your hosting or security provider mentions outbound connections to an unfamiliar code-server subdomain, a URL path containing the literal string parasiteCode, or a header carrying something like CODE-API-KEY, that lines up with this family specifically.

The catch: a clean look isn't a clean site

Here's the part that's easy to miss even for people who clean sites for a living. Cloaking malware's core promise, that it looks fine to the person checking, means every manual check that relies on looking is exactly the wrong test. It's entirely possible to load the homepage, click through a few pages, run a quick scan, and reasonably conclude the site is fine, while the crawler-facing side keeps generating and indexing fake product pages the whole time.

What to check yourself

You don't need to read PHP to catch signs of this. A few checks are within reach with nothing more than a hosting file manager and Google Search Console:

1. Search Console shows pages you never made. If the indexed page count includes URLs like /products/something-you-dont-sell, and clicking through from search actually resolves instead of 404ing, that's the clearest signal something outside your control is generating pages under your domain.
2. The sitemap looks different depending on how it's viewed. Most WordPress sites generate a sitemap index, a short file that just lists other sitemap files. If the version Google has crawled contains a long list of individual URLs instead of that short index, something is replacing it before Google sees it, even if the sitemap looks normal when opened directly.
3. A plugin folder has a file with no file extension. Browsing a plugin's own integration or config subfolders in a file manager and finding a file with a name but no .php, .js, or .css after it is worth asking a host or security provider to look at directly.
4. "I checked and it looks fine" isn't evidence here. If a customer or Search Console is reporting something a browser isn't, believe the outside signal. That mismatch is the entire mechanism of this malware, not a contradiction to explain away.

Kornet scans WordPress sites the way Google actually sees them, not just the way a human visitor does, specifically to catch cloaking and other audience-aware malware that hides from ordinary checks. The scan is free; you only pay if we actually find malware.

Kornet Labs publishes field notes from real WordPress malware cleanups.