WordPress gehackt: Wie man eine kompromittierte Website wiederherstellt

Webentwickler, Webbetreuer und eigentlich alle, die Websites betreuen, kennen solche Momente: Es ist ein völlig unscheinbarer Morgen und plötzlich klingelt das Telefon.

Der Kunde ist dran:

„Ich komme nicht mehr in die Website rein.“

Ein Problem mit dem Login.

„Wird wahrscheinlich nur ein kurzer Serverausfall sein“, dachte ich mir.

Geantwortet habe ich: „Ich schaue es mir sofort an.“

Es war kein Serverausfall.

Es war ein Hack.

Ich öffne also die Website und versuche zuerst selbst, mich im WordPress-Backend einzuloggen.

Keine Chance.

Statt des normalen WordPress-Logins bekomme ich etwas zu sehen, das dort definitiv nicht hingehört.

Eine Webshell.

Eine Webshell ist eine eingeschleußte Oberfläche, über die Dateien und Verzeichnisse auf dem Server verwaltet werden können. Und zwar nicht von WordPress, sondern von jemandem, der dort nichts verloren hat.

Ich habe mir daraufhin den Webspace genauer angesehen. Und je länger ich gesucht habe, desto unschöner wurde es.

In verschiedenen Verzeichnissen lagen fremde PHP-Dateien. Auch .htaccess-Dateien waren verändert oder neu angelegt worden.

Im Plugin-Ordner fand ich außerdem ein Verzeichnis mit dem Namen: RUg4Kkm2H4j5IjMRXNs0TN

Nein, das war kein Plugin.

Zumindest keines, das dort hätte sein sollen.

Auch die .htaccess-Dateien sahen nicht mehr so aus, wie sie aussehen sollten.

Eine davon enthielt Regeln, die in einer normalen WordPress-Installation so nichts verloren hatten. Unter anderem wurden verschiedene PHP-Dateiendungen blockiert.

Gleichzeitig hatten mehrere Dateien und Verzeichnisse fast identische Änderungszeitpunkte.

Das war für mich ein weiterer Hinweis darauf, dass die Veränderungen automatisiert vorgenommen worden waren.

Auch die index.php im Hauptverzeichnis ließ sich während meiner Untersuchung nicht normal bearbeiten oder ersetzen.

Spätestens da war klar:

Ich konnte dieser Installation nicht mehr vertrauen.

Und genau das war das eigentliche Problem.

Nicht die Frage, ob ich noch irgendwo eine verdächtige Datei finde.

Sondern die Frage:

Kann ich am Ende wirklich sicher sagen, dass alles sauber ist?

Nachdem ich wusste, wie die Installation aussah, wollte ich wissen, was davor passiert war.

Also habe ich mir die Server-Logs angesehen.

Und dort wurde es interessant.

Bereits am 21. Juli, also zwei Tage bevor der Vorfall überhaupt aufgefallen war, tauchten auffällige Zugriffe auf.

Zuerst mit dem User-Agent:
wp2shell-check/1.0

Direkt danach folgten zwei POST-Anfragen an:
/?rest_route=/batch/v1

Bei einer davon lautete der User-Agent schlicht:
wp2shell

Noch interessanter war aber: Eine der Anfragen wurde vom Server tatsächlich verarbeitet und erzeugte eine Antwort von rund 1,23 MB.

WP2Shell ist ein Angriffswerkzeug, mit dem versucht wird, über eine Schwachstelle oder einen missbrauchbaren WordPress-Endpunkt Zugriff auf eine Website zu bekommen und dort Schadcode auszuführen oder Dateien abzulegen.

Der Name in den Logs allein wäre noch kein vollständiger Beweis gewesen.

Aber zusammen mit dem, was ich auf dem Server gefunden hatte — fremde PHP-Dateien, Backdoors und manipulierte .htaccess-Dateien — ergab sich ein ziemlich klares Bild.

Die Spuren passten technisch zu einem WP2Shell-Angriff.

Und damit war die nächste Entscheidung eigentlich schon gefallen.

Einzelne Schadsoftware-Dateien zu löschen wäre hier zu wenig gewesen.

Denn selbst wenn ich zehn verdächtige Dateien gefunden und entfernt hätte, hätte irgendwo noch eine elfte liegen können.

Und genau eine reicht.

Bei dieser Installation waren die Veränderungen über mehrere Verzeichnisse verteilt. WordPress-, Theme- und Systemdateien konnten deshalb nicht mehr als vertrauenswürdig eingestuft werden.

Also habe ich mich gegen eine Reparatur der alten Installation entschieden.

Die Website musste neu aufgebaut werden.

Die Entscheidung war also gefallen: Ich würde die alte WordPress-Installation nicht weiterverwenden.

Jetzt ging es darum, möglichst viel zu retten, ohne den Schadcode gleich wieder mitzunehmen.

Meine erste Maßnahme war, den PHP-Handler auf dem betroffenen Webspace zu deaktivieren.

Damit konnte innerhalb der kompromittierten Installation zunächst kein weiterer PHP-Code ausgeführt werden. Danach habe ich den aktuellen Zustand gesichert.

Das war wichtig, bevor ich überhaupt mit der eigentlichen Wiederherstellung anfangen konnte.

Ich habe direkt in der Datenbank nach auffälligen Einträgen und möglichen Hinweisen auf SQL-Injections gesucht.
Ich wollte ausschließen, dass der Angriff nicht nur Dateien auf dem Webspace verändert hatte, sondern auch Manipulationen in der Datenbank hinterlassen hatte.
Die Suche blieb erfolgslos – zu meinem Glück. Also konnte ich weitermachen.

Bei der Kontrolle der WordPress-Benutzerkonten sind mir außerdem zwei Konten aufgefallen, die ich so nicht erwartet hatte.

Das hat die Situation noch einmal verschärft.

Denn wenn bei einer bereits kompromittierten Website plötzlich zusätzliche Benutzer auftauchen, muss man zumindest prüfen, ob sich hier jemand einen dauerhaften Zugang geschaffen hat.

Die beiden Benutzerkonten habe ich deshalb sofort gelöscht.

Die Website enthielt natürlich weiterhin Inhalte und Daten, die gebraucht wurden.

Einfach alles auf einen neuen Server oder in eine frische WordPress-Installation zu kopieren wäre aber keine gute Idee gewesen.

Also habe ich die kompromittierte Website lokal in einer abgeschotteten virtuellen Maschine eingerichtet.

Dort konnte ich mir die vorhandenen Inhalte und technischen Bestandteile in Ruhe ansehen und gezielt nur das übernehmen, was wirklich benötigt wurde. WordPress-, Theme- und Plugin-Dateien aus der kompromittierten Installation wurden nicht einfach weiterverwendet.

Auf dem Server habe ich anschließend eine neue WordPress-Installation eingerichtet.

Die benötigten Plugins wurden neu aus den jeweiligen Hersteller- und Lizenzkonten heruntergeladen und installiert. Ein benötigtes Plugin wurde nach vorheriger Prüfung aus einem vorhandenen Backup übernommen.

So konnte ich vermeiden, manipulierte Dateien aus der alten Installation wieder zurück auf den Server zu holen.

Das bisherige Theme habe ich ebenfalls nicht weiterverwendet.

Stattdessen habe ich ein neues individuelles Custom Theme entwickelt und nur geprüfte Inhalte und notwendige Daten in die neue Installation übernommen.

Das war deutlich mehr Aufwand als einfach ein Backup einzuspielen.

Aber genau darum ging es:

Nicht den alten Zustand möglichst schnell wiederherzustellen.

Sondern eine Grundlage zu schaffen, der ich wieder vertrauen konnte. Und mit der ich künftig keine Probleme mehr haben würde.

Mit der Wiederherstellung war die Arbeit noch nicht vorbei.

Die neue Installation sollte nicht einfach wieder genauso online gehen wie vorher.

Deshalb habe ich zusätzliche Sicherheitsmaßnahmen eingerichtet.

Dazu gehörten unter anderem Wordfence, Zwei-Faktor-Authentifizierung, zusätzliche Schutzregeln in der .htaccess und mein eigenes Must-Use-Plugin für WordPress-Hardening.

Über mein Hardening werden unter anderem der Theme- und Plugin-Dateieditor deaktiviert, XML-RPC abgeschaltet und öffentliche Benutzerabfragen eingeschränkt.

Außerdem habe ich die administrativen Benutzerkonten geprüft und sicherheitsrelevante Zugangsdaten geändert.

Keine dieser Maßnahmen macht eine WordPress-Website unangreifbar.

Aber sie reduziert unnötige Angriffsflächen deutlich.

Am Ende wurde die kompromittierte Installation vollständig außer Betrieb genommen.

Nur geprüfte Inhalte und notwendige Daten wurden übernommen. WordPress und die benötigten Plugins kamen frisch auf den Server, das alte Theme wurde ersetzt und die neue Installation zusätzlich abgesichert.

Für Untersuchung, Wiederherstellung und Absicherung waren insgesamt rund 20 Arbeitsstunden nötig.

Und genau das ist der Punkt, den man bei einem Hack schnell unterschätzt:

Eine Website wieder irgendwie online zu bekommen ist das eine.

Sie wieder auf eine saubere und vertrauenswürdige Grundlage zu stellen, ist etwas ganz anderes.

Auf der Website lief noch WordPress 6.9.4.

Ein Update auf eine aktuelle WordPress-Version war allerdings nicht einfach möglich, weil das eingesetzte Theme technisch nicht mehr sauber mitgezogen werden konnte.

Ein Relaunch war zu diesem Zeitpunkt ebenfalls noch nicht geplant.

Die Website lief also grundsätzlich weiter, befand sich technisch aber in einer Situation, in der größere Updates nicht ohne Weiteres möglich waren.

Das ist ein Zustand, den man bei älteren WordPress-Websites gar nicht so selten sieht:

Solange alles funktioniert, wird ein Relaunch gerne noch etwas aufgeschoben.

Problematisch wird es dann, wenn sicherheitsrelevante Updates irgendwann an Theme- oder Plugin-Kompatibilitäten scheitern.

In diesem Fall wurde genau das nach dem Hack zu einem entscheidenden Punkt.

Denn statt die alte Installation wieder in denselben Zustand zurückzubringen, war klar:

Wenn ich die Website ohnehin komplett neu aufsetzen muss, dann nicht wieder auf einer technisch überholten Grundlage.

Eine gehackte Website wieder online zu bekommen, ist nicht unbedingt das Schwierigste.

Die eigentliche Herausforderung ist, danach wieder sagen zu können:

Dieser Installation kann ich vertrauen.

In diesem Fall bedeutete das mehr Arbeit als ein paar Schadsoftware-Dateien zu löschen. Aber genau deshalb habe ich mich für die komplette Neuinstallation entschieden.

Und wenn eine WordPress-Website technisch an dem Punkt angekommen ist, an dem wichtige Updates nicht mehr problemlos möglich sind, sollte man das nicht ewig vor sich herschieben.