Nicht jeder WordPress-Hack ist laut. Manche Angreifer wollen Ihre Website nicht verunstalten oder gegen Lösegeld kapern. Sie wollen die Suchautorität Ihrer Domain leise kapern und damit ihre eigenen Inhalte bei Google platzieren. Solche Angriffe heißen SEO-Cloaking-Angriffe, und sie zählen zu den schädlichsten Kompromittierungen, die eine Unternehmenswebsite erleiden kann, weil der Betreiber oft gar nicht weiß, dass sie passieren.
Dieser Artikel zeigt genau, wie ein echter SEO-Cloaking-Angriff funktioniert, anhand einer aktuellen Fallstudie einer Agentur in Sydney, bei der jede Datei und jeder Dispatcher in einem forensischen Audit identifiziert wurde. Wenn Sie eine WordPress-Website betreiben, ist das Folgende das Muster, das Sie erkennen können sollten.
Was Cloaking bedeutet
Cloaking ist die Praxis, Suchmaschinen andere Inhalte auszuliefern als menschlichen Besuchern. Eine Seite kann dem Googlebot einen langen Artikel voller Keywords zu themenfremden kommerziellen Themen zeigen, während sie einem normalen Besucher eine generische Landingpage oder eine Weiterleitung anzeigt. Das Ziel ist, Suchmaschinen dazu zu bringen, die getarnten Inhalte unter der Autorität einer etablierten Domain zu platzieren.
Google hat Regeln dagegen. Cloaking verstößt gegen die Richtlinien für Webmaster und kann einer Domain Strafen durch manuelle Maßnahmen oder einen kompletten Ranking-Einbruch einbringen, wenn es entdeckt wird. Dem Angreifer ist das egal, denn die Domain gehört nicht ihm.
Das Muster der fünf Verzeichnisse
Der Fall in Sydney nutzte eine besonders saubere Variante des Angriffs. Der Angreifer hatte fünf neue Verzeichnisse im Stammverzeichnis der Website angelegt, jedes so benannt, dass es eine echte WordPress-Seite nachahmte. Auf der Festplatte erschienen Ordner mit Namen wie about, contact, good-to-know, services und work. Jeder enthielt genau drei Dateien. Einen index.php-Dispatcher. Eine user.php-HTML-Datei. Eine wp-log.php-HTML-Datei.
Der Grund, die Ordner nach echten Seiten zu benennen, war einfach. Kam eine Anfrage für /about/ an die Website, prüfte der Webserver zuerst das Dateisystem. Ein Ordner namens about existierte, mit einer index.php darin. Der Webserver löste diese Datei auf, bevor WordPress‘ eigenes URL-Routing ins Spiel kam. Jede Anfrage an diese URLs traf den Code des Angreifers statt der legitimen WordPress-Seite.
Der Dispatcher
Die index.php-Datei in jedem Ordner war ein winziges Stück PHP, das eine einzige Sache tat. Sie inspizierte den User-Agent-Header der eingehenden Anfrage und leitete entsprechend weiter. Enthielt der User-Agent Googlebot, Googlebot-Mobile oder Googlebot-News, lieferte sie den Inhalt von wp-log.php aus. Andernfalls band sie user.php ein und beendete sich.
Dieselbe Datei war in allen fünf Ordnern ausgerollt, Byte für Byte identisch. Der Angreifer nutzte eine einzige Payload und eine einzige Entscheidungsregel. Alles andere waren Daten.
Die Payload für Googlebot
Die wp-log.php-Dateien enthielten trotz der Endung .php reines HTML. Sie waren riesig und reichten von etwa 1,3 MB bis über 4 MB. Jede war eine vollständige HTML-Seite in einer Fremdsprache, in diesem Fall Indonesisch, mit Spam-Inhalten zu Glücksspiel, E-Commerce und Samsung-Produkt-Tracking. Die Seiten waren vollgestopft mit strukturierten Daten, eingebetteten Tracking-Skripten von Drittanbietern und Links, die das legitime Inhalte bei den anvisierten Keywords überflügeln sollten.
Warum sie wp-log.php nennen? Tarnung. Für einen Betreiber, der die Dateiliste überfliegt, sieht es wie eine WordPress-Logdatei aus, nicht wie eine verdächtige Payload.
Die Payload für Menschen
Die user.php-Dateien waren kleinere HTML-Seiten, die echten menschlichen Besuchern ausgeliefert wurden. Es waren Doorway-Seiten von themenfremden Drittanbieter-Sites, ebenfalls mit einer .php-Endung getarnt, obwohl sie überhaupt keinen PHP-Code enthielten. Wer über ein Suchergebnis auf eine dieser URLs gelangte oder auf der Website zu /about/ navigierte, sah Inhalte, die nichts mit der Agentur zu tun hatten.
Das ist der Cloaking-Teil. Google sieht den Glücksspiel-Spam im Inhalt von wp-log.php, platziert ihn unter der Domain-Autorität der Agentur und schickt echte Nutzer an user.php, das eine völlig andere Doorway-Erfahrung liefert. Die Täuschung funktioniert in beide Richtungen.
Wie der Angreifer hereinkam
Das forensische Audit konnte den genauen Einstiegsvektor anhand der verfügbaren Daten nicht ermitteln, aber der stärkste Verdächtige war ein veraltetes Dateimanager-Plugin, das noch installiert und aktiv war. Die betreffende Plugin-Familie hat eine lange Geschichte von Schwachstellen zur Remotecodeausführung, mit mehreren in vergangenen Jahren veröffentlichten Hinweisen. Mit Schreibzugriff über dieses Plugin kann ein Angreifer beliebige Dateien überall im Dokumenten-Stammverzeichnis ablegen.
Entscheidend: Das Audit bestätigte, dass WordPress-Core, wp-config.php, die Datenbank und das aktive Theme allesamt sauber waren. Keine Hintertür in der Anwendung, kein betrügerischer Admin-Nutzer, kein verschleiertes PHP-eval. Die Kompromittierung lag vollständig in diesen fünf Ordnern. Genau das machte sie so leise. Die meisten Sicherheitsscanner schauen auf WordPress-Dateien, nicht im Dokumenten-Stammverzeichnis nach unerwarteten Verzeichnissen.
Warum diese Art von Angriff so schädlich ist
SEO-Cloaking-Angriffe schaden auf drei Arten. Erstens wird der Spam-Inhalt unter Ihrer Domain indexiert und drängt Ihre echten Seiten in den Suchergebnissen nach unten oder hinaus. Zweitens kann Google bei erkanntem Cloaking Strafen durch manuelle Maßnahmen oder eine algorithmische Herabstufung verhängen, von der man sich oft erst nach Wochen oder Monaten erholt, selbst wenn die schädlichen Dateien weg sind. Drittens können die in den Spam-Seiten eingebetteten Drittanbieter-Skripte und Tracking-Pixel Ihre Besucher dem Risiko von Malware oder Phishing aussetzen.
Der Betreiber einer gecloakten Website bemerkt oft nichts, bis der Traffic einbricht oder ein Kunde erwähnt, beim Klick auf ein Suchergebnis seltsame Inhalte gesehen zu haben. Bis dahin ist bereits wochen- oder monatelanger Schaden entstanden.
Wie Sie das auf Ihrer eigenen Website erkennen
Ein paar schnelle Prüfungen fangen die meisten Varianten dieses Angriffs ab. Rufen Sie Ihre Startseite als normaler Nutzer auf. Senden Sie dann eine curl-Anfrage von einem Server mit einem Googlebot-User-Agent-Header und vergleichen Sie. Sehen Sie unterschiedliche Inhalte, stimmt etwas nicht.
Prüfen Sie die Berichte Abdeckung und Leistung in der Google Search Console auf indexierte URLs, die Sie nicht kennen, besonders solche mit fremdsprachigen Suchanfragen. Sehen Sie sich das Dokumenten-Stammverzeichnis per SFTP auf Ordner oder Dateien an, die Sie nicht erklären können. Führen Sie mit einem seriösen Sicherheits-Plugin einen vollständigen Malware-Scan durch und lesen Sie den Bericht, statt nur Warnungen wegzuklicken.
Wie Sie es verhindern
Die Vorbeugung besteht aus denselben Gewohnheiten, die die meisten WordPress-Kompromittierungen verhindern. Halten Sie Core, Themes, Plugins und PHP aktuell. Entfernen Sie Plugins, die Sie nicht aktiv nutzen, besonders Dateimanager und Shell-Zugriffstools. Blockieren Sie die PHP-Ausführung in Verzeichnissen, die niemals PHP enthalten sollten. Auditieren Sie das Dokumenten-Stammverzeichnis monatlich. Nutzen Sie ein Sicherheits-Plugin, das auf neue Dateien an unerwarteten Stellen überwacht und meldet, sobald eine auftaucht.
Brauchen Sie Unterstützung?
Wenn Sie befürchten, dass Ihre WordPress-Website ohne Ihr Wissen getarnte Inhalte beherbergt, kann Defyn ein forensisches Audit durchführen und Ihnen genau sagen, was auf Ihrem Server liegt. Melden Sie sich, und wir sorgen dafür, dass Ihre Domain nur für das rankt, wofür sie soll.
