Der Scanner lügt Sie nicht an, er wird belogen
Am 29. Juli 2026 veröffentlichte Joe Youngblood eine Warnung, dass der japanische Keyword-Hack sich in hohem Tempo durch WordPress-Installationen zieht und dabei, in seinen Worten, “easily defeating WordFence, Securi, and Malcare along with other security methods / plugins”.
Genau dieser letzte Teil ist der interessante, und es ist kein Versagen dieser Produkte in dem Sinne, wie es zunächst aussieht. Der Scan kommt sauber zurück, weil die Payload in dem Moment, in dem der Scanner fragt, schlicht nicht da ist.
Die eingeschleusten Inhalte werden bedingt ausgeliefert. Auf der Website sitzt eine Web-Shell, die bei jeder Anfrage entscheidet, ob sie injiziert. Sieht die Anfrage nach einem Browser aus, bekommen Sie Ihre gewohnte Seite. Sieht sie nach dem Googlebot aus, kommt eine Seite voller japanischer Shop-Keywords zurück, die auf Produktfälschungen verlinkt. Ihr Security-Plugin ruft die Seite als es selbst ab, erhält die gewöhnliche Version und hat nichts zu melden.
Deshalb liegt das erste Symptom fast nie auf der Website. Es liegt in der Search Console, in einem Google-Ergebnis zur eigenen Marke oder in einem Traffic-Einbruch, den niemand erklären kann.
Beweisen Sie es mit einem Befehl, bevor Sie irgendetwas anfassen
Bevor Sie anfangen, Dateien zu löschen, klären Sie, womit Sie es tatsächlich zu tun haben. Rufen Sie dieselbe URL zweimal aus der Shell ab:
curl -s https://example.com/some-page/ > browser.html
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
https://example.com/some-page/ > crawler.html
diff browser.html crawler.htmlUnterscheiden sich beide, und trägt die Crawler-Version Links oder Keywords, die die Browser-Version nicht hat, liegt Cloaking vor und die Diagnose ist abgeschlossen. Kein Plugin-Scan, kein Raten.
Machen Sie dasselbe mit Ihrer Sitemap. Ein häufiges Begleitsymptom ist eine Meldung der Search Console, die Sitemap sei “offenbar eine HTML-Seite”, während dieselbe Sitemap im Browser korrekt lädt. Dahinter steckt derselbe Mechanismus: etwas fängt die Sitemap-Route ab und liefert dem Crawler etwas anderes aus.
Zwei weitere Stellen, an denen Sie nachsehen sollten, beide außerhalb der Website:
- Search Console, Sicherheitsprobleme. Hat Google die Website eingestuft, benennt der Bericht das Muster und enthält den Antrag auf Überprüfung, den Sie später brauchen.
- Search Console, Leistung, gefiltert auf Suchanfragen, die Sie nicht kennen. Japanische Shop-Begriffe auf einer deutschen oder polnischen Website sind kein Grenzfall.
Was die einzelnen Werkzeuge sehen und was nicht
Es lohnt sich, genau zu benennen, warum die Scanner sauber zurückkommen, denn “das Plugin hat versagt” führt dazu, dass Leute ein anderes Plugin kaufen, statt die Methode zu ändern.
| Methode | Sieht eine veränderte Core-Datei | Sieht eine Shell in uploads | Sieht Inhalte, die nur an Crawler gehen | Sieht eine Saatdatei von vor Monaten |
|---|---|---|---|---|
| Malware-Scan per Plugin (signaturbasiert) | meistens | oft | nein | nur wenn die Datei zu einer Signatur passt |
wp core verify-checksums | ja, deterministisch | nein, uploads haben keine Prüfsummen | nein | ja, wenn die Datei im Core liegt |
| Grep nach base64 und eval | ja, mit Fehlalarmen | ja | nein | ja, wenn die Payload unverschleiert ist |
| Cloaking-Test mit zwei Abrufen | nein | nein | ja | ja, indirekt, er belegt, dass weiterhin ausgeliefert wird |
| Search Console, Sicherheitsprobleme | nein | nein | ja, nachdem Google eingestuft hat | nein |
Das Muster in dieser Tabelle ist der ganze Punkt. Jede Methode, die Dateien untersucht, beantwortet die Frage “liegt etwas im Dateisystem”, und jede Methode, die Verhalten untersucht, beantwortet die Frage “belügt diese Website gerade Crawler”. Sie brauchen beides, und nur eines davon wird Ihnen als Produkt angeboten.
Früh erkennen und einen Rückfall bemerken
Die Lücke zwischen Infektion und Entdeckung ist die Zeit, in der der SEO-Schaden entsteht. Drei Signale treffen ein, bevor der Traffic einbricht.
Impressionen für Suchanfragen, die für Ihr Geschäft keinen Sinn ergeben. Search Console, Leistung, nach Impressionen sortieren, nach allem suchen, was in einer Schrift steht, in der Sie nicht publizieren. Das ist in der Regel das früheste Signal, das Ihnen zur Verfügung steht, und es kostet eine Minute pro Woche.
Eine Seite, die aus dem Nichts ausschlägt. In der aktuellen Welle zeigt die zuerst injizierte Seite oft einen plötzlichen Impressionssprung, bevor der Rest nachzieht. Eine Seite, die Sie seit einem Jahr nicht angefasst haben und die auf einmal performt, ist dreißig Sekunden Neugier wert.
Ein verändertes Favicon in den Ergebnissen. Youngblood weist darauf hin, dass diese Welle ein charakteristisches Favicon mitbringt, sichtbar in der Search Console. Ein Favicon, das Sie nicht gesetzt haben, ist eine Datei, die Sie nicht geschrieben haben.
Nach der Bereinigung taugt derselbe Test mit zwei Abrufen als brauchbare Rückfallüberwachung. Er läuft von jedem Rechner mit curl, nicht von der Website selbst, und das ist wichtig, weil eine kompromittierte Website ein schlechter Gutachter ihres eigenen Zustands ist:
#!/usr/bin/env bash
# cloaking-watch.sh - meldet, wenn die Crawler-Ansicht von der Browser-Ansicht abweicht
URL="https://example.com/"
UA_BOT="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
a=$(curl -s --max-time 20 "$URL" | md5sum | cut -d' ' -f1)
b=$(curl -s --max-time 20 -A "$UA_BOT" "$URL" | md5sum | cut -d' ' -f1)
if [ "$a" != "$b" ]; then
echo "DIVERGENCE on $URL at $(date -u +%FT%TZ)"
exit 1
fiZwei Einschränkungen, bevor Sie das in einen Cronjob legen. Seiten mit rotierenden Inhalten, A/B-Tests oder personalisierten Blöcken unterscheiden sich legitim, richten Sie den Test also auf eine stabile Seite wie einen zeitlosen Beitrag oder die Sitemap. Und eine gut gebaute Shell kann mehr als den User Agent auswerten, etwa den IP-Bereich der Anfrage, ein sauberes Ergebnis ist hier also ein Indiz und kein Beweis. Den Regelfall fängt der Test trotzdem ab, und zwar innerhalb eines Tages statt eines Quartals.
Vom übrigen SEO-Spam unterscheiden
Drei Infektionen laufen unter dem Etikett “SEO-Spam”, und sie verlangen jeweils einen anderen ersten Schritt. Eine Minute für die Frage, welche davon Sie vor sich haben, ist deshalb gut investiert.
Pharma-Spam schreibt Medikamenten-Keywords in Beitragstitel, Auszüge und Inhalte. Er lebt in der Datenbank, gewöhnliche Besucher bekommen ihn zu sehen, und Sie finden ihn, indem Sie wp_posts und wp_options nach den Begriffen durchsuchen, die Google anzeigt. Findet ein SELECT die Wörter, haben Sie diesen Fall vor sich und nicht den japanischen.
Casino- und Wett-Spam liegt zwischen beiden. Er tarnt sich häufig wie die japanische Variante, kommt aber meist mit injizierten hreflang-Blöcken und erfundenen Sprachversionen Ihrer Seiten, weil die Betreiber mehrere Märkte auf einmal bedienen wollen. Zeigt die Crawler-Ansicht Verweise auf Sprachversionen, die Sie nie angelegt haben, suchen Sie dort.
Der japanische Keyword-Hack lässt die Datenbank in Ruhe. Die Payload steckt in Dateien, wird zur Laufzeit erzeugt und nur für Crawler, und genau diese Kombination hebelt die Datenbanksuche und den Plugin-Scan gleichzeitig aus.
Dazu kommt eine Variante mit Weiterleitung nur für Mobilgeräte, die genauso am User Agent ansetzt, nur prüft sie auf Telefone statt auf den Googlebot. Melden Ihre Besucher, dass sie auf einer fremden Website landen, während Ihre eigenen Tests am Desktop sauber bleiben, wiederholen Sie den Test mit zwei Abrufen und einem mobilen User-Agent-String statt dem des Googlebots. Der Mechanismus ist identisch, nur die Bedingung ändert sich.
Dateien deterministisch prüfen, dann auf die Zeitstempel schauen
Youngbloods Beitrag schlägt vor, das Dateisystem nach base64 zu durchsuchen und die Liste von einem KI-Modell begutachten zu lassen. Das funktioniert, ist aber der zweite Schritt und nicht der erste, weil es ein Modell raten lässt, welche Dateien zu WordPress gehören. WordPress weiß das bereits:
wp core verify-checksums
wp plugin verify-checksums --allDamit wird jede Core- und Plugin-Datei gegen die offiziellen Prüfsummen von WordPress.org abgeglichen, und alles Veränderte oder Hinzugefügte wird benannt. Das ist deterministisch, dauert Sekunden und liefert eine deutlich kürzere Liste zum Nachdenken als ein base64-Grep über den gesamten Baum.
Was Prüfsummen nicht abdecken: Ihr Theme, alles Kommerzielle, wp-content/uploads und mu-plugins. Dort setzt der manuelle Durchgang an:
grep -rl --include="*.php" -E "base64_decode|eval\(|gzinflate|str_rot13" wp-content/ | head -50
find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins/Eine PHP-Datei innerhalb von uploads hat keinen legitimen Grund zu existieren. Genauso wenig eine Datei in mu-plugins, die Sie nicht geschrieben haben, und dieses Verzeichnis verdient besondere Aufmerksamkeit, weil es automatisch geladen wird und nie in der Plugin-Liste auftaucht.
Sortieren Sie anschließend, was Sie gefunden haben, nach Änderungsdatum. Der Großteil der injizierten Dateien teilt sich üblicherweise einen Zeitstempel, und das ist der Moment des sichtbaren Angriffs. Die Ausnahme ist das, was Youngblood die Saat nennt: eine einzelne Datei, die Wochen, Monate oder gelegentlich Jahre früher abgelegt wurde, mit einem Zeitstempel, der zu nichts anderem passt. Räumen Sie alles außer der Saat ab, kommt die Infektion zurück, und sie kommt leise zurück.
Der praktische Test, ob Sie sie erwischt haben: eine saubere index.php zurückspielen, zwei Minuten warten und die Datei erneut lesen. Ist sie wieder verändert, läuft noch etwas, das sie überschrieben hat, und Sie sind nicht fertig.
Die Reihenfolge, auf die es ankommt
An der Reihenfolge der Bereinigung scheitern Wiederherstellungen, und die Abfolge ist nicht intuitiv.
Kopieren, bevor Sie bereinigen. Zuerst eine vollständige Dateikopie und ein Datenbank-Export im infizierten Zustand. Ein Backup einfach darüberzuspielen zerstört die einzige Spur, wie der Einstieg zustande kam, und wenn das Backup selbst bereits infiziert ist, haben Sie nichts mehr zum Vergleichen. Da eine Saatdatei dem sichtbaren Angriff um Monate vorausgehen kann, ist “spielen wir das Backup vom letzten Monat zurück” eine Annahme und keine Lösung. Prüfen Sie deshalb früh, wie weit die Aufbewahrung Ihres Hosters tatsächlich zurückreicht: bei deutschen Shared-Hosting-Tarifen liegen die täglichen Sicherungen häufig im Bereich weniger Tage bis zu etwa zwei Wochen, bei Managed-WordPress-Anbietern wie Raidboxes oder Mittwald hängt die Tiefe vom gebuchten Tarif ab. Reicht die Aufbewahrung vierzehn Tage zurück und ist die Saat drei Monate alt, liegt jedes verfügbare Backup bereits nach der Infektion.
Erst bereinigen, dann Zugangsdaten wechseln, dann die Suche. In dieser Reihenfolge. Zugangsdaten zu wechseln, solange die Shell noch läuft, übergibt einfach die neuen.
Wechseln Sie mehr als nur Passwörter. Das ist der Schritt, vor dem fast jede Anleitung stehen bleibt:
- Anwendungspasswörter in den einzelnen Benutzerprofilen unter Benutzer überleben eine Passwortänderung und behalten den vollen Zugriff auf die REST-API. Sie hängen am jeweiligen Benutzer, sie lassen sich programmatisch leicht anlegen, sobald ein Angreifer Administrator ist, und die meisten Leute wissen nicht, dass es die Funktion gibt. Auflisten und löschen.
- Delegierte Inhaber in der Search Console, unter Einstellungen, Nutzer und Berechtigungen, liegen vollständig außerhalb Ihrer Website. Nichts, was Sie in WordPress tun, entfernt sie. Prüfen Sie auch die Inhaberschaftsbestätigung auf verwaiste HTML-Dateien oder DNS-TXT-Einträge.
- Datenbank- sowie FTP- oder SSH-Zugangsdaten, denn wenn der Einstieg Credential Stuffing gegen
wp-adminwar, ist alles andere, das sich dieses Passwort geteilt hat, ebenfalls offen.
Und dann die Suche. Sitemap neu erzeugen, mit einer Live-Prüfung über die URL-Prüfung in der Search Console bestätigen, dass der Googlebot jetzt die echte Seite bekommt, und im Bericht zu den Sicherheitsproblemen eine Überprüfung beantragen. Eine erneut eingereichte Sitemap hebt keine manuelle Maßnahme auf, der Antrag auf Überprüfung schon.
Zwei Standardempfehlungen, denen zu widersprechen sich lohnt
Die Warnung, die diesen Artikel ausgelöst hat, ist gute Feldarbeit, und zwei ihrer Empfehlungen verdienen Widerspruch.
“Beantragen Sie sofort die Entfernung Ihrer gesamten Website über die Search Console.” Das ist ein schwereres Instrument, als die Lage üblicherweise verlangt. Das Entfernen-Werkzeug blendet URLs für etwa ein halbes Jahr aus den Ergebnissen aus, es ändert nichts an der Infektion und nichts daran, wie Google die Website später neu bewertet. Die injizierten URL-Muster über eine Präfix-Entfernung auszublenden ist verhältnismäßig. Die gesamte Website zu entfernen blendet auch die Seiten aus, die weiterhin Anfragen bringen, und jede einzelne muss danach über einen zurückgezogenen Antrag und ein erneutes Crawling zurückkommen, auf das Sie keinen Einfluss haben. Zur Variante für die ganze Website greifen Sie, wenn die injizierten Seiten die echten tatsächlich zahlenmäßig übertreffen, nicht als Schritt eins.
“Finden Sie irgendeinen Vorwand für eine Pressemitteilung, um frisches Interesse des Googlebots zu wecken.” Erneutes Crawling wird von Dingen angetrieben, die Sie wirklich beeinflussen können: korrekte lastmod-Werte in der Sitemap, interne Links von Seiten, die häufig gecrawlt werden, und Anfragen über die URL-Prüfung für die Seiten, auf die es ankommt. Eine Pressemitteilung ist ein teurer Weg, ein paar Crawler-Besuche zu kaufen.
Der Rest dieses Beitrags, insbesondere die Beobachtung zum eigenwilligen Zeitstempel der Saatdatei und die Warnung, index.php nach dem Zurückspielen erneut zu prüfen, deckt sich damit, wie solche Bereinigungen in der Praxis aussehen.
Die Tür schließen, die der Angriff tatsächlich benutzt hat
Die gemeldete Einstiegskette dieser Welle ist konkret: Credential Stuffing gegen wp-admin mit geleakten E-Mail- und Passwortlisten, danach die Installation eines Plugins, um Zugriff auf das Dateisystem zu bekommen, danach der Upload einer einzelnen Payload-Datei. Für jeden dieser Schritte gibt es eine Maßnahme, die ihn stoppt.
Zwei-Faktor-Authentifizierung für jeden Administrator. Credential Stuffing funktioniert, weil das Passwort bereits bekannt ist. Zwei-Faktor macht ein korrektes Passwort unzureichend, und genau darauf beruht der Angriff.
DISALLOW_FILE_MODS. In der wp-config.php:
define( 'DISALLOW_FILE_MODS', true );Das blockiert die Installation von Plugins und Themes über das Dashboard vollständig. In der gemeldeten Kette ist das Schritt zwei. Ein Angreifer mit gültiger Admin-Sitzung kann das Dateimanager-Plugin nicht installieren, das ihm das Dateisystem öffnet. Der Kompromiss ist real und Sie sollten ihn kennen: automatische Updates entfallen ebenfalls, Aktualisierungen laufen dann über WP-CLI oder eine Deployment-Pipeline. Auf einer Website, die aus einem Repository ausgerollt wird, sollte es ohnehin so laufen.
Keine PHP-Ausführung in uploads. Auf Ebene des Webservers, nicht in einem Plugin. Das entwertet den häufigsten Weg von “der Angreifer hat eine Datei hochgeladen” zu “der Angreifer führt Code aus”.
Weniger Administratoren. Agenturmitarbeiter, ein Entwickler, der einmal ausgeholfen hat, ein Support-Dienstleister von vor zwei Jahren. Jeder davon ist ein Zugang, der sich durchprobieren lässt. Stufen Sie herab, was die Rolle nicht braucht.
Beobachten Sie die Search Console statt des Dashboards. Im Dashboard ist dieser Angriff konstruktionsbedingt unsichtbar. Ein wöchentlicher Blick in den Leistungsbericht auf Suchanfragen, die Sie nicht kennen, erkennt ihn früher als jeder Scan.
Was Sie dem Kunden oder Ihrer Geschäftsführung sagen
Wenn Sie das für jemand anderen bereinigen, ist der schwierige Teil des Gesprächs nicht technisch, sondern zeitlich. Die Bereinigung läuft in Stunden, die Erholung in Wochen, und beides fällt im Kopf schnell zu einer einzigen Erwartung zusammen: heute Abend reparieren, morgen ist der Traffic zurück. Er ist es nicht, denn Google muss Seiten erneut besuchen, die es zuvor als Spam eingestuft hatte, und wie schnell das geschieht, hängt davon ab, wie oft die Website vorher gecrawlt wurde.
Das Zweite, das man klar aussprechen sollte: Sie können nicht ehrlich beantworten, ob Kundendaten abgeflossen sind, wenn die Server-Logs sieben Tage zurückreichen und die Saatdatei vom Februar stammt. Die Antwort lautet “wir wissen es nicht und werden es nicht mehr herausfinden”, und das ist eine Information und keine Ausflucht. Bei einem Shop mit personenbezogenen Daten entscheidet genau diese Lücke darüber, ob eine Meldepflicht greift: Artikel 33 DSGVO verlangt die Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden ab Kenntnis, und “ein Zugriff ließ sich nicht ausschließen” ist dabei der Normalfall und nicht die Ausnahme. Das gehört zu Beginn auf den Tisch und nicht eine Woche später.
Das Dritte: Die Kosten dieser Infektion sind selten die Bereinigung. Es ist der Traffic, der in diesen Wochen nicht kam, und diese Zahl rechnet man besser gemeinsam aus den Daten vor der Infektion aus, statt sie als vages Gefühl stehen zu lassen, dass es irgendwie bergab ging.
Wenn Sie gerade mittendrin stecken
Die kurze Fassung: Weisen Sie das Cloaking mit dem Test aus zwei Abrufen nach, prüfen Sie Core und Plugins mit Prüfsummen, jagen Sie die Saat über das Änderungsdatum, kopieren Sie alles, bevor Sie irgendetwas zurückspielen, und denken Sie daran, dass Anwendungspasswörter und delegierte Inhaber in der Search Console die Passwortänderung überleben, die Sie gleich vornehmen werden.
Wir fahren diese Abfolge als Teil eines WordPress-Sicherheitsaudits, und der weitere Bereinigungsprozess samt Datenbankarbeit und Log-Auswertung steht in unserem Leitfaden zum Säubern einer gehackten WordPress-Website.
Zuletzt aktualisiert: 30. Juli 2026, nach der Meldung der aktuellen Welle.
