Chinese spam in je WordPress — detecteren en grondig verwijderen

Een klant belt: zijn klanten klagen dat ze zijn site niet meer kunnen vinden via Google, en als ze 'm wél vinden zien ze Chinese tekens in de zoekresultaten. Hij opent zelf de site — alles ziet er normaal uit. Geen waarschuwing, geen redirect, geen vreemde content. Wat is hier aan de hand?

Dit is de zogenaamde Japanese keyword hack (ondanks de naam vaak Chinees of een mengelmoes), ook bekend als SEO-spam injectie of cloaking-hack. Het is een van de meest gemene WordPress-hacks die er bestaan, juist omdat 'ie zich verstopt voor de site-eigenaar maar wél zichtbaar is voor zoekmachines. Het resultaat: je domein-reputatie wordt langzaam vermoord terwijl jij er niets van merkt.

Hoe ziet de hack eruit?

De typische symptomen, in de volgorde waarin je ze meestal opmerkt:

• In Google-zoekresultaten verschijnen Chinese of Japanse tekens als titel of meta-omschrijving van jouw pagina's
• Nieuwe URL's verschijnen onder jouw domein die je nooit hebt gemaakt — vaak met namen als /buy-cheap-handbags/, /replica-watches-2024/, /casino-online/
• Google Search Console toont plotseling honderden of duizenden geïndexeerde pagina's die niet bestaan in je CMS
• Je organische verkeer keldert
• Soms: een waarschuwing in Search Console over "hacked content"
• Heel soms: bezoekers vanaf Google worden doorgestuurd naar Chinese of casino-sites; bezoekers die direct typen zien je normale site

Waarom kan jij het niet zien?

Dit is wat de hack zo verraderlijk maakt: hij gebruikt cloaking. De geïnjecteerde code detecteert wie de pagina opvraagt:

• Is het een gewone bezoeker (jij, met Chrome of Safari)? → Toon normale content
• Is het Googlebot, Bingbot of een andere crawler? → Toon spam-pagina's met Chinese keywords en links naar twijfelachtige sites
• Komt de bezoeker via een Google-zoekresultaat? → Soms wordt 'ie doorgestuurd naar een externe spam-site

De aanvaller misbruikt jouw domein-autoriteit om links naar zijn eigen netwerk te krijgen. Voor jou onzichtbaar; voor Google ineens een bron van honderden Chinese spam-pagina's.

Hoe weet je zeker dat dit het is?

Drie manieren om de hack te bevestigen:

1. Zoek je site in Google

Type in Google: site:jouwdomein.nl. Scroll door de resultaten. Zie je vreemde URL's, Chinese tekens, of pagina's die niet bestaan? Dat is bewijs.

2. Doe je voor als Googlebot

Open een terminal (op macOS/Linux, of WSL op Windows) en draai:

curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" \
  https://jouwdomein.nl/ | grep -i "<title>\|<meta name=\"description\""

Krijg je Chinese tekens of vreemde keywords te zien? Dat is je smoking gun. Je site serveert andere content aan crawlers dan aan jou.

3. Google Search Console

Ga naar Search Console → Inhoud → Pagina's. Sorteer op "Geïndexeerd". Vergelijk met je werkelijke pagina's. Honderden vreemde URL's? Bevestiging.

Onder "Beveiliging en handmatige acties" in Search Console kan ook een waarschuwing staan ("Hacked: Content injection") — Google laat dat lang niet altijd zien, maar als het er staat is het 100% zeker.

Stap 1: Bewijs verzamelen voor je iets weghaalt

De grote verleiding is: nu meteen alles wegpoetsen. Niet doen. Verzamel eerst:

• Screenshots van de Google-zoekresultaten met Chinese tekst
• De volledige curl-output (zie hierboven) als bewijs
• Een lijst van vreemde URL's uit Search Console
• Server access logs, minimaal de laatste 30 dagen
• Een lijst van recent gewijzigde files: via SSH find . -type f -mtime -30 -name "*.php"
• Database export (volledige mysqldump)

Bewaar alles offline op je eigen computer. Pas dan ga je verder.

Stap 2: Site offline halen tijdens cleanup

Voorkom dat Google nog meer spam-pagina's indexeert tijdens je opschoning. Plaats in .htaccess:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123\.45\.67\.89$
RewriteRule .* /maintenance.html [R=503,L]

Vervang 123.45.67.89 met jouw eigen IP-adres. Zo zie alleen jij de site nog, en geeft de server 503 Service Unavailable aan crawlers en bezoekers — Google ziet dat als tijdelijk en blijft je site niet de-indexeren.

Stap 3: De usual suspects controleren

Deze hack heeft favoriete plekken om zich te verstoppen. Loop ze één voor één na.

3.1 — .htaccess (root van je site)

Open .htaccess in je webroot. Zoek naar:

• RewriteCond regels op User-Agent (vooral als ze "Googlebot", "Bingbot", "Yandex" of "Baidu" matchen)
• Verwijzingen naar onbekende PHP-files
• Base64-strings of URL-encoded patterns
• Regels die specifiek doorsturen of content injecteren

Een typisch malicious blok ziet er zo uit:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (googlebot|bingbot|yandex) [NC]
RewriteRule ^(.*)$ /wp-includes/class-cloak.php [L]
</IfModule>

Verwijder zulke blokken. Houd alleen de WordPress-standaard .htaccess over (zie wordpress.org/documentation voor de canonieke versie).

3.2 — wp-config.php

Open wp-config.php. Zoek naar:

• include- of require-statements naar bestanden die niet van WordPress zijn
• eval(base64_decode(...)) patronen
• Vreemde array-definities of constants
• Code vóór de <?php-opening (geen mens schrijft dat zo)

3.3 — Webroot scannen op vreemde PHP-files

Via SSH:

# Recent gewijzigde PHP-files (laatste 30 dagen)
find . -type f -name "*.php" -mtime -30 -ls

# Files met verdachte namen op willekeurige plekken
find . -type f \( -name "wp-class*.php" -o -name "wp-info.php" \
  -o -name "class-wp-*.php" -o -name "wp-load*.php" \) -ls

Veelgebruikte verstopplekken voor de cloaking-payload:

• /wp-content/uploads/ (mag normaal géén PHP bevatten — alle PHP hier is verdacht)
• /wp-includes/ met files die niet in een clean WordPress staan
• Random nieuwe plugin-mappen onder /wp-content/plugins/
• Files in webroot met namen als wp-cron-init.php, about.php, style.php

3.4 — Theme files (vooral functions.php)

Het actieve thema is een geliefde plek voor backdoors. Open wp-content/themes/jouw-theme/functions.php. Zoek naar:

• eval() — meestal verdacht
• base64_decode() in combinatie met eval of create_function
• file_get_contents naar externe URL's
• preg_replace met de /e modifier (klassieke obfuscation)
• Lange strings van willekeurige karakters die later gedecodeerd worden

Vergelijk je functions.php met de originele theme-file. Verschillen die jij niet hebt gemaakt = verdacht.

3.5 — Database scannen

De cloaking-payload zit soms ook in de database. Check via phpMyAdmin of SSH:

# Zoek base64-patronen in wp_options
SELECT option_name, option_value FROM wp_options
WHERE option_value LIKE '%base64%' OR option_value LIKE '%eval%';

# Zoek Chinese tekens in posts
SELECT ID, post_title, post_status FROM wp_posts
WHERE post_title REGEXP '[一-龥]' OR post_content REGEXP '[一-龥]';

# Onbekende admin-users
SELECT ID, user_login, user_email, user_registered FROM wp_users;
SELECT * FROM wp_usermeta WHERE meta_key = 'wp_capabilities'
  AND meta_value LIKE '%administrator%';

Controleer ook de tabel wp_options regels met namen als class_generic_support, widget_generic_support, of andere nep-WordPress-namen — die zijn vaak vehikels voor de geserialiseerde payload.

3.6 — Geplande taken (cron)

Aanvallers plaatsen vaak een cron job die de payload herinjecteert na cleanup. Check:

wp cron event list

(WP-CLI vereist). Zoek naar onbekende hooks. Verwijder met wp cron event delete <hook-name>.

Ook server-cron checken:

crontab -l

Stap 4: Grondig opschonen

Cleanup gaat het snelst en veiligst via clean replacements:

1. WordPress core: download de huidige versie van wordpress.org. Vervang alle bestanden in webroot, behalve wp-content/ en wp-config.php. Voor dat laatste: maak een nieuwe op basis van de inhoud van je oude (database-credentials behouden, alle vreemde toevoegingen weglaten).
2. Plugins: deactiveer alles. Verwijder de hele plugins-map. Installeer alleen de plugins die je echt gebruikt opnieuw, vanuit officiële bronnen (WordPress.org of de officiële developer-website voor premium plugins).
3. Themes: zelfde aanpak. Verwijder alle thema's behalve één clean kopie van je actieve. Installeer dat opnieuw vanuit een vertrouwde bron.
4. Uploads: scan de hele /wp-content/uploads/-tree op PHP-files: find wp-content/uploads -name "*.php". Alle hits zijn verdacht — verwijder ze.
5. Database: verwijder de verdachte wp_options-regels die je in stap 3.5 vond. Reset alle WordPress salts in wp-config.php via api.wordpress.org/secret-key/1.1/salt/ — dat invalideert alle bestaande sessies.
6. Admin-users: verwijder onbekende administrators. Reset wachtwoorden voor alle bestaande admins.

Stap 5: Hardening na de cleanup

De aanvaller kwam ergens binnen. Voorkom herhaling:

• Update WordPress core, alle plugins, alle thema's naar de laatste versie
• Wijzig alle wachtwoorden: hosting, FTP/SSH, WordPress admin, database-user, mailaccounts
• Activeer 2FA voor alle WordPress admin-accounts
• Plaats .htaccess in /wp-content/uploads/ die PHP-uitvoering blokkeert (zie het WordPress hardening artikel of laat het door mij regelen)
• Installeer een security plugin (Wordfence, Sucuri, Solid Security)
• Schakel DISALLOW_FILE_EDIT in via wp-config.php
• Beperk inlogpogingen
• Activeer file integrity monitoring

Stap 6: Herstel bij Google

Cleanup is technisch klaar — nu nog de schade in zoekresultaten.

1. Submit voor reconsideration: in Search Console → Beveiliging & handmatige acties. Beschrijf kort wat er gebeurde en wat je hebt gedaan om het op te lossen. Reactie binnen 1-2 weken.
2. Verwijder spam-pagina's uit Google's index: in Search Console kun je via "Verwijderingen" verzoeken indienen om specifieke URL's tijdelijk uit de index te halen. Doe dit voor de duidelijkste spam-URL's.
3. Force re-crawl van schone pagina's: gebruik de URL-inspectietool en klik "Indexering aanvragen" voor je homepage en belangrijkste pagina's.
4. Monitor 30 dagen: check elke week Search Console + draai elke week de curl-test om te checken of de hack écht weg is en niet stilletjes terugkomt via een gemiste backdoor.

Wanneer schakel je hulp in?

Onderstaande situaties zijn vaak te complex voor zelfdoen:

• Je vindt geen verdachte code, maar de Googlebot-test toont nog steeds Chinese content
• Na cleanup duikt de hack binnen een week weer op — je hebt een backdoor gemist
• Je hebt geen SSH-toegang en alle scans moeten via FTP/filemanager (veel langzamer)
• Search Console toont meer dan 1.000 vreemde geïndexeerde URL's — handmatig verwijderen is niet realistisch
• De site heeft een live webshop draaien en je kunt 'm niet 24 uur uit de lucht halen voor cleanup
• Je vermoedt dat ook andere sites op dezelfde hosting geraakt zijn

De cloaking-hack is technisch erg goed verstopt. Dit is geen "vinden en weghalen" — het is detective-werk. Een halve cleanup is geen cleanup: één gemiste backdoor en je staat over twee weken weer op start.