Japanese keyword hack: how I cleaned an infected site

What the owner sees and what Google sees

The defining feature of this infection is that there is nothing to show the site owner. Pages open, the design is intact, forms work. The infection reveals itself only to the search engine crawler.

The culprit was a replaced index.php — the single file every request to the site passes through. Normally it weighs about one and a half kilobytes. Here it weighed 16,622 bytes, and the extra fifteen kilobytes were encrypted code doing exactly one thing: checking who had arrived. If the request came from Googlebot, Bing, Baidu or Yandex — or if the visitor arrived from the Japanese Google — the site served a Japanese page about handbags and sneakers with links to someone else's shops instead of its own content.

The technique is called cloaking: a different answer for different visitors. The owner sees their site, the search engine sees spam, and hundreds of pages that never existed on the site gradually appear in the search results.

How it shows up

• a site:yoursite.pl query in Google returns foreign pages with Japanese characters;
• Search Console reports a hack or lists URLs in its report that you never created;
• search traffic drops for no visible reason;
• meanwhile the site works normally — which is exactly why the problem is noticed late.

What was sitting on the server

In total I deleted 777 files. This was not a single backdoor but a settled infrastructure built up over years:

• 191 doorway pages in .shtml format. The format was not chosen by accident: the server executes a system command inside such a file, so every hit on a doorway recreated a backdoor on the site. Deleting one malicious file was not enough — the neighbouring page restored it immediately.
• 576 test uploaders in the temporary folder — one file for every conceivable extension. That is how the attacker worked out which file type the hosting would let through.
• 22 site control panels in the form folder/random_number/index.php, scattered across directories.
• Four large backdoors in the root, including an 86-kilobyte file manager and one separate small file whose purpose I explain below — it turned out to be the most interesting find.
• 8 doorway directories, among them a wp-includes folder — on a site that does not run on WordPress. The attack was mass-produced and indiscriminate: throw everything at it, something will stick.
• Files disguised as the system core: they sit among service folders, carry plausible names and even the vendor's copyright notice in the header. You will never find those by eye, scanning a file listing.

The attacker was protecting his loot

The .htaccess — the server settings file — made a separate impression on me. The attacker had rewritten it so that executing any PHP file on the site was forbidden, except for a short allowlist. The allowlist contained his own backdoors.

The purpose is twofold: first, other attackers cannot use the same entry point; second, a fair number of security scanners run into that ban and never reach the malicious code at all.

Why restoring a backup did not help

While I was working through it, the owner of savuk.eu did what most people do: at 9:27 in the morning he restored the site from a two-week-old hosting backup. The December 2022 backdoors came back with it.

It could not have gone any other way. The infection is older than any backup a hosting provider keeps: backups live for weeks, while the backdoor had been sitting on the site for almost four years. Inside the archive it is as much a part of the site as the logo and the texts.

The rule is simple: a backup restores content, not security. Restoring makes sense only after the entry point has been found and closed — and only with the archive itself checked.

The least obvious part: a deleted file keeps running

This is the point where it is easy to draw the wrong conclusion and lose half a day.

I replaced the infected index.php with a clean one at 14:13:53. Seventeen seconds later, at 14:14:10, the malicious code ran again and created its service file. For another minute after that, Google's crawler was still receiving a page with nineteen kilobytes of Japanese spam — while ordinary visitors saw a “site under maintenance” notice.

The reason is neither magic nor a second backdoor. PHP does not read the file on every request: it keeps an already-compiled copy in memory (this is called OPcache) and refreshes it with a delay. While that copy is alive, the server keeps executing the code of a file that is no longer on disk.

That same small file in the root I mentioned above did exactly one thing: reset this cache. The attacker knew about the mechanism and used it so that his own changes took effect instantly.

The practical takeaway: after a cleanup the cache must be flushed by force, otherwise it is easy to decide the infection is still there and start hunting a second backdoor that does not exist.

The result is verified in the logs, not in the file listing

An empty folder proves nothing. Server logs prove it — they show exactly what the site answered to every single request.

On savuk.eu there were 62 successful responses to spam URLs before the cache flush and not a single one after it. That is the proof — not the fact that the files were deleted.

The second mandatory step is to request the page as a search crawler. Cloaking is by definition invisible from a normal browser, and the check “I opened the site, everything looks fine” simply does not work here:

curl -A Googlebot https://yoursite.pl/

On Windows the command has to be typed as curl.exe: the short curl in PowerShell means something entirely different and will not understand the -A switch.

If the response contains Japanese characters or foreign links while the page is clean in your browser, you are looking at exactly the problem this article is about.

What I did, step by step

1. Took a full snapshot of every suspicious file before deleting anything — so there would be something to compare against if any of it came back.
2. Put the site into maintenance mode so that during the cleanup it served nothing to either people or robots.
3. Deleted 777 infected files.
4. Replaced index.php with the reference file from the system distribution.
5. Rewrote .htaccess: restored the standard rules, disabled the execution of system commands inside pages, and blocked code execution in the folders for images, uploads and temporary files. It is never needed there — and that is exactly where it gets uploaded.
6. Force-flushed the PHP cache.
7. Verified the result in the server logs and with a request as Googlebot.

Cleaning up is half the job

Deleting the files is not enough, because the entry point stays open. What follows is the mandatory part — the same for any infected site, and without it everything comes back:

• change every password — file access, hosting panel, database, site administrators. The file-access password is compromised by default: if the attacker had it, any cleanup is pointless;
• check the database: look for extra administrators and foreign extensions;
• update the content management system to the current version;
• remove extensions nobody has updated in years — that is the most likely entry point;
• deal with the logs. On this server, for instance, there was a 21-gigabyte error file that nobody had ever opened.

You can see the attack is still running straight from the logs: on the same day, one address was methodically cycling through file extensions trying to upload something, while dozens of others kept hitting the spam URLs hoping they would work again.

How to check your own site in five minutes

If you find it — four rules

• Do not restore a backup blindly. The infection will most likely arrive along with it.
• Passwords first, files second. Otherwise you are cleaning a site a stranger still holds the keys to.
• Look for the entry point, not just the traces. A deleted backdoor with the hole left open is back within a day.
• Verify the result in the logs and with a crawler request, not by the fact that the site opens.

And one last, less technical point. savuk.eu was infected for almost four years and looked perfectly healthy the whole time. The only thing that stopped anyone noticing earlier was the absence of a habit: looking into Search Console and the server logs at least once a quarter. It is free and takes ten minutes.

If you see something similar on your own site and would rather not dig into it yourself — write to me and we will sort it out. Answers to common questions about website maintenance are collected in the FAQ section.

Victor Parhimchik, founder of the IT Deweloper web studio