Befindet sich plötzlich eine robots.txt im WordPress-Verzeichnis? Ist die index.php auf mehr als 19k angewachsen? Steigerte sich die Anzahl von Zugriffen auf die Website im extremen Ausmaß?

Dann würde ich mal zu Google gehen, und site:meine-adresse.beispiel eingeben. Es werden mehr Treffer gefunden, als es Seiten geben kann? – Und zu allem Überfluss siehst Du nur noch japanisch? – Dann ist Deine Website Opfer eines Japanischen Keyword Hacks geworden.

Grund für einen solchen Hack sind Sicherheitslücken wie diese, die sich in einem lange nicht upgedaten Foren-Plugin befand. Eine ausführliche Beschreibung ist in diesem Artikel zu lesen. Der Sonderfall an diesem Plugin war noch dazu: wer noch mit Version 5.x ausgestattet war, konnte von der gefixten Version 6+ im Dashboard nichts erfahren, da der Versionssprung nicht angezeigt wurde (von 5.x auf 6.x konnte wegen Umbenennung des Pluginverzeichnisses nur manuell upgegraded werden). – Selbst wer also regelmäßig Updates machte, hätte betroffen sein können, es sei denn, es wäre ihm aufgefallen, dass ein Foren-Update längst überfällig war, hätte dann die Anleitung gefunden und die Anleitung befolgt.

Äußere Merkmale des Japanischen Keyword Hacks

Extrem viele Seitenaufrufe, die mithin sogar zum Ausfall des Webservers führen können, bei denen zu allem Überfluss als Quelladressen nur lokale 10er-Adressen von einem Webproxy oder Loadbalancer ankamen, die in Firewalls üblicherweise gewhitelistet sind. Würde man diese IP-Adressen sperren, wäre die Website unzugänglich.

https://example.com/202010852198/ vor 1 Sekunde 10.42.138.206   
https://example.com/202010333160/ vor 1 Sekunde 10.42.217.165       
https://example.com/20200945377/  vor 1 Sekunde 10.42.217.165   
https://example.com/202009682019/ vor 1 Sekunde 10.42.138.206
https://example.com/20200990413/  vor 1 Sekunde 10.42.128.1
https://example.com/20201024789/  vor 1 Sekunde 10.42.128.1
https://example.com/akarinohiroba/16971xuyzers5891wa.htm vor 1 Sekunde 10.42.128.1
https://example.com/20200958170/  vor 1 Sekunde 10.42.128.1 
https://example.com/20200959187/  vor 1 Sekunde 10.42.217.165
https://example.com/takahaship/97xauzgq-1637we-t.htm vor 1 Sekunde 10.42.138.206 

Andernfalls hätte man es mit extrem vielen Aufrufen von Fake URLs über IP-Adressen aus Japan zu tun.

Gibt man in Google seite:example.com ein (beliebige Sprachen), erhält man ein Ergebnis wie in diesem Google Beitrag beschrieben.

In der Google Search Console könnte man zudem einen fremden Inhaber vorfinden. Wer eine betroffene Site nicht in der Google Search Console angemeldet hat, sollte das tun und kontrollieren, ob er der einzige Inhaber ist, und fremde ggf. löschen.

Je nachdem, ob Google schon was bemerkt hat, wird einem bereits ein Sicherheitsproblem für die Website angezeigt. In den Statistiken ist die Anzahl indexierter Seiten massiv gewachsen. In diesem Fall waren es bereits 4,6 Mio angeblich gültiger indexierter Seiten!

Innere Merkmale des Japanischen Keyword Hacks

Es waren mehrere fremde mit dem Skript versehene Dateien versteckt, über die eine robots.txt und Sitemaps mit Fake-URLs angelegt wurden. So lange noch eine robots.txt entsteht, nachdem man die vorherige gelöscht hat, ist der Hack weiterhin aktiv. Im Zuge dessen werden auch index.php und htaccess erneut umgeschrieben. Man kann sich beim Aufspüren der Dateien am Datum orientieren. Betroffene Dateien kann nicht jeder Scanner finden, da sie nicht zum WordPress-Kern gehören. Um die Dateien manuell aufzuspüren muss man auf’s Datum achten, da die Fremddateien mithin plausible Namen haben, und sich an allen möglichen Orten verstecken können.

Als hilfreich erwies sich hier übrigens Security Ninja, das bösartige Fremddateien aufspürte. Manche Sicherheitsplugins mit Datei-Scanner erkannten nur die Veränderungen in WordPress-Core-Dateien. Allerdings müssten bei Security Ninja die 10er-IP-Adressen gewhitelistet werden, da sonst niemand mehr Zutritt ins Dasbboard bekommt.

So in etwa sieht eine befallene robots.txt aus (die Nummern der Sitemap-Links können variieren, auch die Anzahl).

User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap_1.xml
Sitemap: https://example.com/sitemap_2.xml
Sitemap: https://example.com/sitemap_4.xml

Wird ein solcher Link im Browser geöffnet, bekommt man eine XML-Sitemap mit vielen japanischen Fakelinks drin.

Die index.php war deutlich größer (19 KB statt 405 Byte), weil dort das Skript generiert worden war, das die Sitemap anlegt (was ebenfalls wieder passiert, so lange nicht alle Malware-Dateien aufgespürt und entfernt sind).

Auch die .htaccess wird überschreiben, und sieht dann zum Beispiel so aus:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^[a-zA-Z0-9_-]+/([0-9]{1,7})([a-zA-Z0-9]{4})[a-zA-Z0-9_-]+\.htm$ index.php?smsite=$2&smid=$1 [L]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>	

Sind alle Hacks entfernt, gibt es keien robots.txt und sitemap-Aufrufe mehr, und vormals in der Sitemap gelistete Links die zuvor noch mit positiver Response abgerufen werden konnten, enden nun (Achtung, mit dem URL-Prüfungstool – früher „Abruf wie durch Google“ – in der Google Search Console testen!) mit einer 404-Antwort.

Das Ende der Aufrufe nicht existenter Fakelinks wird auch nach dem Cleaning nicht so schnell aufhören, da die falschen Seiten dann ja noch im Google-Index verblieben.

Im ungünstigen Fall muss die Entfernung von Blacklists und eine Prüfung der gesäuberten Website durch Google beantragt werden.