WordPress gehackt: die ersten Stunden

Meistens merkst du es nicht selbst. Ein Kunde ruft an, weil seine Virenwarnung anschlägt. Google zeigt vor deiner Seite eine rote Warnseite. Oder deine Mails kommen plötzlich nirgends mehr an, weil dein Server auf einer Sperrliste steht. Der Befall selbst ist da schon Tage oder Wochen alt.

Was jetzt zählt, ist die Reihenfolge. Der häufigste Fehler ist nicht, zu wenig zu tun, sondern zu früh aufzuräumen.

Wer als Erstes die verdächtigen Dateien löscht, hat die Spur vernichtet und den Weg offen gelassen, über den der Angreifer reingekommen ist. Zwei Tage später ist alles wieder da.

Daniel Weihmann

Die ersten dreißig Minuten

1. Seite vom Netz nehmen

Nicht löschen, nur abschalten. Eine Wartungsseite oder ein Passwortschutz über die Serverkonfiguration reicht. Damit hörst du auf, deine Besucher zu gefährden, und du verhinderst, dass Google weitere befallene Seiten einliest.

Wenn deine Seite Spam versendet, sperr zusätzlich den Mailversand beim Hoster. Sonst läuft die Blockade deiner Domain weiter, während du reparierst.

2. Alles sichern, bevor du etwas anfasst

Ein vollständiges Abbild: sämtliche Dateien und die Datenbank. Das ist kein Backup zum Wiederherstellen, es ist die Beweissicherung. Ohne sie findest du später nicht heraus, wie der Angreifer hereinkam, und du reparierst dieselbe Lücke nicht.

Diese Sicherung kommt an einen Ort, der nicht auf demselben Server liegt. Wer sie im selben Verzeichnis ablegt, hat sie beim nächsten Mal auch verloren.

3. Passwörter ändern, aber alle

Und zwar in dieser Reihenfolge: Hoster-Konto, FTP- und SSH-Zugänge, Datenbankbenutzer, WordPress-Administratoren, alle E-Mail-Postfächer, die auf der Domain laufen. Wer nur das WordPress-Passwort ändert, hat den Türsteher ausgetauscht und die Hintertür offen gelassen.

Prüf dabei die Benutzerliste in WordPress. Ein zusätzlicher Administrator mit unauffälligem Namen ist einer der häufigsten Funde.

4. Die Zeitmarken lesen

Sieh dir an, welche Dateien zuletzt geändert wurden, sortiert nach Datum. Das grenzt den Zeitpunkt ein. Mit diesem Datum gehst du in die Zugriffsprotokolle des Servers und suchst, was in den Stunden davor passiert ist. Meist findest du dort eine Reihe von Aufrufen auf dieselbe Plugin-Datei.

Wie sie hereingekommen sind

In der überwiegenden Zahl der Fälle, die ich bekomme, ist es einer von vier Wegen.

Ein veraltetes Plugin. Nach meiner Erfahrung der häufigste. Nicht das Plugin, das du täglich nutzt, sondern das, was vor sechs Jahren für eine Bildergalerie installiert wurde und seit vier Jahren deaktiviert im Verzeichnis liegt. Deaktiviert heißt nicht entfernt, und die Dateien sind weiter aufrufbar.

Ein gekauftes oder kostenlos heruntergeladenes Theme aus zweifelhafter Quelle. Besonders beliebt sind Kopien kostenpflichtiger Themes, die jemand irgendwo gefunden hat. Der Einbau ist bereits enthalten.

Ein schwaches Administratorpasswort. WordPress-Anmeldeseiten werden rund um die Uhr durchprobiert. Ein Passwort aus dem Firmennamen plus Jahreszahl hält nicht lange.

Ein Nachbar auf demselben Webspace. Wenn auf einem Paket fünf Seiten liegen und eine davon befallen ist, greift der Schadcode oft auf die anderen über. Deshalb muss man bei einem Befall alle Installationen auf diesem Paket prüfen, nicht nur die auffällige.

Aufräumen: warum Zurückspielen selten reicht

Der naheliegende Gedanke ist, das letzte Backup einzuspielen. Das hat zwei Haken. Erstens weißt du nicht, ob der Befall zu diesem Zeitpunkt schon da war, und meistens war er es. Zweitens ist die Lücke, über die er kam, in diesem Backup ebenfalls enthalten.

Der Weg, der trägt, ist der Neuaufbau aus sauberen Teilen:

• WordPress-Kern vollständig ersetzen, nicht aktualisieren, sondern die Dateien austauschen.
• Jedes Plugin und jedes Theme frisch aus der offiziellen Quelle neu installieren, statt die vorhandenen Ordner zu behalten.
• Alles entfernen, was nicht gebraucht wird. Deaktivierte Plugins, alte Themes, vergessene Testinstallationen in Unterverzeichnissen.
• Nur den Inhalt übernehmen: die Datenbank, geprüft, und das Uploads-Verzeichnis, geprüft.

Das Uploads-Verzeichnis ist dabei der Punkt, an dem viele Reinigungen scheitern. Dort haben nur Bilder und Dokumente etwas verloren. Findet sich dort eine PHP-Datei, ist sie mit hoher Wahrscheinlichkeit nicht von dir. Der Server sollte so eingestellt sein, dass in diesem Verzeichnis überhaupt kein PHP ausgeführt wird.

In der Datenbank suchst du in den Beitrags- und Optionstabellen nach eingefügten Skripten und nach umgeleiteten Adressen für Seite und Startseite. Wer das auf der Kommandozeile macht, ist schneller; wie das geht, steht in WP-CLI: WordPress auf der Kommandozeile.

Danach: sich bei Google wieder abmelden

Wenn Google die Seite als schädlich markiert hat, verschwindet die Warnung nicht von allein, wenn du sauber bist. In der Search Console gibt es dafür den Punkt Sicherheitsprobleme. Dort forderst du nach der Bereinigung eine erneute Prüfung an. Das dauert je nach Fall Stunden bis Tage.

Dasselbe gilt für Bing, und das wird regelmäßig vergessen, obwohl einige KI-Suchen ihre Antworten teilweise von dort beziehen. Wie du dort überhaupt hineinkommst, steht in Webseite bei Bing anmelden.

Prüf danach in der Search Console den Bereich zur Indexierung. Ein häufiger Nebenschaden sind hunderte eingeschleuster Unterseiten, die Google inzwischen kennt. Die müssen zuverlässig einen Fehlercode liefern, sonst tauchen sie monatelang in den Ergebnissen auf.

Der Schaden am Ruf ist meistens größer als der technische. Eine rote Warnseite vor dem Firmennamen sieht ein Kunde einmal und erinnert sich zwei Jahre daran.

Daniel Weihmann

Meldepflicht: kurz nachdenken, nicht ignorieren

Wenn Daten von Kunden abgeflossen sein könnten, etwa aus einem Shop, einem Kundenbereich oder gespeicherten Formularnachrichten, kann eine Meldepflicht nach Artikel 33 DSGVO bestehen, und zwar innerhalb von 72 Stunden gegenüber der Aufsichtsbehörde. In Sachsen-Anhalt ist das der Landesbeauftragte für den Datenschutz in Magdeburg. Ob im Einzelfall gemeldet werden muss, ist eine rechtliche Frage. Sie zu prüfen dauert kürzer als sie zu ignorieren.

Damit es nicht wieder passiert

Der Aufwand danach ist gering, wenn man ihn einmal einrichtet. Automatische Updates für Kern und Plugins. Ein Ausmisten aller Erweiterungen, die niemand braucht. Zwei-Faktor-Anmeldung für Administratoren. Ein Backup, das nicht auf demselben Server liegt und das man einmal testweise zurückgespielt hat, denn ein ungetestetes Backup ist eine Vermutung. Und getrennte Webspace-Pakete, wenn mehrere Seiten laufen.

Und die unbequeme Frage: Braucht die Seite überhaupt WordPress? Wer dreimal im Jahr etwas ändert, zahlt jeden Monat Wartung für ein System, das er kaum nutzt, und trägt dauerhaft dessen Angriffsfläche. Für einen Teil meiner Kunden war der Umzug auf eine Seite ohne Datenbank die Lösung, nach der wir gesucht haben.

Kurz gefasst

Abschalten, sichern, alle Passwörter tauschen, dann erst suchen. Neu aufbauen statt reinigen, nur Inhalte übernehmen, das Uploads-Verzeichnis genau ansehen. Danach bei Google und Bing die erneute Prüfung anfordern. Und die Lücke schließen, sonst wiederholt sich das Ganze.

Wenn du gerade mitten drin steckst, ruf an, statt weiterzulesen: unverbindlich anfragen. Ich übernehme bestehende WordPress-Seiten auch dann, wenn ich sie nicht gebaut habe, siehe WordPress: Wartung und Rettung. Und wenn ohnehin ein Umbau ansteht, gehört die Systemfrage dazu: Website-Relaunch: wann er sich lohnt.