WordPress gehackt: Bereinigung mehrerer Websites nach einer Webshell-Infektion

WordPress gehackt: Ausgangslage und erste Bereinigung

Auf mehreren Websites waren Links aufgetaucht, die dort nicht hingehörten. Hinzu kamen unbekannte Dateien. Eine der auffälligen Dateien hieß monit.php; die Untersuchung betraf eine Webshell-Infektion.

Eine Webshell ist ein eingeschleustes Skript, über das Angreifer Aktionen auf einem Webserver ausführen können. Welche Möglichkeiten es bietet, hängt von seinem Code und den verfügbaren Berechtigungen ab. Eine solche Datei kann beispielsweise dazu dienen, weitere Dateien anzulegen oder vorhandene zu verändern. Ihr Fund belegt für sich genommen allerdings keinen Zugriff auf den gesamten Server mit Administratorrechten.

Zu Beginn entfernte ich die erkannten Schad-Dateien und prüfte die Seiten, auf denen zuvor fremde Links zu sehen gewesen waren. Die Links waren verschwunden. Auch ein anschließender Malware-Scan meldete keine weiteren Funde.

Nach ungefähr 30 Minuten traten die Auffälligkeiten erneut auf. Die erste Bereinigung hatte also nicht ausgereicht. Offenbar bestand weiterhin eine Möglichkeit, die Websites zu verändern. Ob dafür eine verbliebene Hintertür, ein kompromittierter Zugang oder eine andere Schwachstelle verantwortlich war, musste die weitere Untersuchung klären.

Rückblickend war der unauffällige Scan zu wenig, um die Bereinigung als abgeschlossen zu betrachten. Er lieferte ein Prüfergebnis für diesen Durchlauf. Die kurz darauf erneut auftauchenden Veränderungen waren ein konkreter Gegenbefund.

Weitere Untersuchung nach dem erneuten Auftreten

Ich weitete die Prüfung auf die anderen Installationen im Hosting-Konto aus. Mehrere betroffene Websites in einer gemeinsamen Umgebung lassen sich bei einer solchen Untersuchung schwer isoliert betrachten. Neben den sichtbaren Seiten waren deshalb auch Benutzerkonten, vorhandene Anwendungen und gesicherte Dateien relevant.

Dabei wurden nicht autorisierte Administratorkonten festgestellt und entfernt. Solche Konten verdienen eine eigene Prüfung: Eine erneuerte WordPress-Installation hilft wenig, wenn ein fremder Benutzer weiterhin berechtigten Zugriff auf ihre Verwaltung hat.

Bei der Dateiprüfung musste ich außerdem zwischen einem Hinweis und einem bestätigten Fund unterscheiden. Ungewöhnliche Namen und Zeitstempel können eine Suche eingrenzen. Sie erklären aber weder allein den Zweck einer Datei noch den Zeitpunkt des Einbruchs. Auch eine vom Hosting-Scanner umbenannte Datei musste in ihrem Zusammenhang bewertet werden.

Gerade bei monit.php wäre es zu kurz gegriffen gewesen, nur nach diesem einen Namen zu suchen. Eine Webshell kann anders heißen; weitere Hintertüren können in Dateien stecken, die zum üblichen Bestand einer Website gehören. Die spätere Prüfung der angepassten Themes bestätigte, wie wichtig dieser zweite Blick war.

Den genauen ersten Zugriff konnte ich anhand der vorhandenen Unterlagen nicht lückenlos rekonstruieren. Deshalb benenne ich hier weder ein bestimmtes Plugin als Ursache noch eine vermeintlich gesicherte Angriffskette. Die gefundenen Veränderungen reichten aus, um die Bereinigung fortzusetzen; für eine eindeutige Zuordnung des Einbruchswegs reichten sie nicht.

Neuinstallation und Prüfung individueller Anpassungen

Für die Wiederherstellung teilte ich den Bestand danach auf, wie er sich verlässlich erneuern ließ. WordPress selbst und unveränderte Erweiterungen konnten durch Dateien aus den jeweiligen Originalquellen ersetzt werden. Bei individuellen Anpassungen war eine manuelle Prüfung erforderlich. Inhalte und Medien sollten erhalten bleiben, mussten aber ebenfalls in die Prüfung einbezogen werden.

Standardsoftware aus Originalquellen ersetzen

Ich installierte die WordPress-Kerndateien neu und beschaffte die benötigte Standardsoftware aus den offiziellen beziehungsweise ursprünglichen Bezugsquellen. Damit entfiel bei diesen Bestandteilen die Notwendigkeit, jede einzelne vorhandene Programmdatei als vertrauenswürdig einzustufen.

Sicherungen waren dennoch hilfreich. Aus ihnen ließ sich nachvollziehen, welche Erweiterungen zuvor vorhanden waren und welche Anpassungen zur Website gehörten. Ihr Nutzen als Arbeitsgrundlage bedeutete aber nicht, dass sie einen nachweislich sauberen Zustand enthielten. Eine Sicherung kann auch Schadcode konservieren, der zum Zeitpunkt ihrer Erstellung noch unentdeckt war.

Angepasste Themes einzeln durchsehen

Aufwendiger war die Prüfung der individuell angepassten Themes und Child-Themes. Diese enthielten Funktionen und Darstellungsänderungen, die nicht einfach durch einen frischen Download wiederhergestellt werden konnten. Ich musste klären, welcher Code zur jeweiligen Website gehörte und welche Teile auffällig waren.

Bei dieser manuellen Prüfung fand ich eine weitere Hintertür. Eine ungeprüfte Übernahme des betroffenen Codes hätte sie wieder in die bereinigte Installation gebracht. Das war ein konkreter Grund, die Anpassungen vor ihrer Wiederverwendung einzeln durchzugehen.

Hinzu kam eine Eigenheit des Bestands: Gleich benannte Child-Themes waren nicht auf allen Websites inhaltlich identisch. Eine geprüfte Variante ließ sich deshalb nicht ohne Weiteres für jede Installation verwenden. Auch kleine, gewachsene Unterschiede konnten für die Funktionen der jeweiligen Website wichtig sein.

Die Arbeit bestand somit auch darin, benötigte Anpassungen zu erhalten. Nach dem Entfernen verdächtiger Bestandteile musste die Website weiterhin das leisten, wofür sie entwickelt worden war. Diese Verbindung aus Codeprüfung und Kenntnis der individuellen WordPress-Entwicklung war bei der Wiederherstellung besonders relevant.

Zugänge und Hosting-Umgebung

Zum Bestand gehörten neben den aktiven Websites auch ältere Anwendungen und Testinstallationen. Ich prüfte, welche davon noch gebraucht wurden. Nicht mehr benötigte Installationen wurden entfernt. Bei Datenbanken musste vorher eindeutig geklärt werden, welche Anwendung sie verwendete, damit keine noch benötigten Inhalte verloren gingen.

Die Bereinigung umfasste außerdem die Prüfung von Zugängen und Berechtigungen sowie Änderungen an Datenbankpasswörtern. Solche Änderungen müssen mit der Konfiguration der zugehörigen Anwendung abgestimmt werden; andernfalls ist zwar das Passwort erneuert, die Website erreicht aber ihre Datenbank nicht mehr.

Weitere Maßnahmen betrafen den Schutz sensibler Konfigurationsdateien, die Einschränkung direkter PHP-Ausführung im Upload-Bereich und das Abschalten des eingebauten Datei-Editors. Sie ergänzen eine Bereinigung, ersetzen aber nicht das Entfernen bereits eingeschleusten Codes.

Bei den Schutzregeln war auch die normale Nutzung zu prüfen. In der dokumentierten Nacharbeit wurde eine legitime Speicheranfrage des Editors durch eine zu pauschale Sicherheitsregel blockiert. Eine Regel musste also nicht nur unerwünschte Anfragen abweisen, sondern zugleich die benötigten Arbeitsabläufe zulassen.

Welche Rolle das Hosting spielte

Die betroffenen Websites liefen in einer Shared-Hosting-Umgebung. Das begrenzte die Möglichkeiten, selbst serverweite Einstellungen zu ändern oder die gesamte Umgebung zu untersuchen. Für Maßnahmen außerhalb des eigenen Hosting-Kontos ist in diesem Modell die Unterstützung des Anbieters entscheidend.

Ein eigener VPS mit Root-Zugriff bietet mehr Eingriffsmöglichkeiten. Damit übernimmt man jedoch auch mehr Verantwortung für Updates, Konfiguration, Überwachung und Wiederherstellung. Ob dieser zusätzliche Zugriff sinnvoll ist, hängt davon ab, wer den Server betreut und wie zuverlässig diese Betreuung im Alltag organisiert ist.

Für mehrere Websites lohnt sich unabhängig vom Hosting-Modell die Frage, wie sie voneinander getrennt sind. Gemeinsame Zugänge und weitreichende Schreibrechte können den Umfang eines Vorfalls vergrößern. Wie diese Trennung konkret umgesetzt wird, gehört in die Planung des laufenden Betriebs.

Ergebnis und weitere Betreuung

Nach mehreren Bereinigungsrunden gelang es, die betroffenen Websites wiederherzustellen und die gefundenen Schadbestandteile zu entfernen. Dafür mussten Standardsoftware erneuert, individuelle Anpassungen geprüft und nicht mehr benötigte Anwendungen aus dem Bestand entfernt werden.

Am meisten Aufwand verursachten die Teile, für die es keinen unveränderten Ersatz gab. Die manuelle Prüfung der angepassten Themes war notwendig, um vorhandene Funktionen zu bewahren und die dort gefundene Hintertür nicht erneut zu übernehmen.

Aus der erfolgreichen Wiederherstellung lässt sich kein Versprechen ableiten, dass eine Website dauerhaft unangreifbar ist. Für die anschließende Betreuung sind gepflegte Softwarestände, nachvollziehbare Zugriffsrechte und überprüfbare Sicherungen entscheidend. Ebenso wichtig ist, dass jemand Veränderungen bemerkt und bei neuen Auffälligkeiten reagieren kann.

Bei älteren Installationen kann die Bereinigung auch Anlass sein, den weiteren Betrieb zu überdenken. Manchmal genügt es, überflüssige Bestandteile zu entfernen und die Wartung zu verbessern. In anderen Fällen ist eine Migration oder Modernisierung sinnvoll. Das sollte sich aus dem tatsächlichen Zustand und den benötigten Funktionen ergeben.