WordPress nach einem Angriff bereinigen und wiederherstellen

Alles zu finden, was ein Angreifer hinzugefügt oder geändert hat, ist schwierig. Den Core zu ersetzen senkt das Risiko, garantiert aber keine vollständige Bereinigung: Auch wp-content, wp-config.php, Benutzer, geplante Aufgaben und die Datenbank müssen geprüft werden.

1. Beweise sichern und ein aktuelles Backup erstellen

Versetzen Sie die Website in den Wartungsmodus und vermeiden Sie neue Schreibvorgänge. Sichern Sie vor der Bereinigung eine vollständige Kopie des kompromittierten Zustands, einschließlich Dateien, Datenbank und Logs, auf einem isolierten Speicher. Berechnen und bewahren Sie ihre Prüfsummen auf; diese Kopie dient der Untersuchung und darf nicht wiederhergestellt werden, als wäre sie sauber.

Erstellen Sie zusätzlich einen aktuellen Wiederherstellungspunkt und prüfen Sie, ob er sich an einem temporären Ort wiederherstellen lässt. Notieren Sie die Versionen von WordPress, Plugins und Themes sowie Benutzer und geplante Aufgaben.

2. Vergleichen, bevor Sie ersetzen

Führen Sie im exakten Stammverzeichnis von WordPress aus:

wp core version
wp core verify-checksums --include-root

Prüfen Sie jede Abweichung. --include-root kann legitime eigene Dateien im Stammverzeichnis melden; löschen Sie sie nicht, ohne sie zu identifizieren. Prüfen und sichern Sie wp-config.php, .htaccess, Verifizierungsdateien von Suchmaschinen und alle eigenen Dateien separat. Prüfen Sie das gesamte wp-content, einschließlich Plugins, Themes, uploads, mu-plugins und Caches.

3. Den Core wiederherstellbar ersetzen

Laden Sie von WordPress.org dieselbe saubere Version herunter, die Sie ermittelt haben, und prüfen Sie ihre Herkunft. Statt zu löschen, legen Sie wp-admin und wp-includes in einer datierten Quarantäne außerhalb aller öffentlichen Verzeichnisse und ohne Möglichkeit zur Ausführung über das Web ab. Setzen Sie die sauberen Kopien ein und ersetzen Sie nur die per Prüfsumme bestätigten Core-Dateien. Sie innerhalb der Website umzubenennen, isoliert sie nicht.

Ersetzen Sie wp-content oder wp-config.php nicht und betrachten Sie sie nicht automatisch als in Ordnung: Sie enthalten Anpassungen und können auch die Persistenz des Angriffs enthalten. Installieren Sie Plugins und Themes aus offiziellen Quellen oder bekannten Kopien neu und prüfen Sie eigene Dateien, bevor Sie sie zurückholen.

Führen Sie erneut aus:

wp core verify-checksums --include-root

Prüfen Sie Frontend, wp-admin, PHP-Logs, Administratoren, Cron-Aufgaben, aktive Optionen und den Inhalt der Datenbank, bevor Sie wieder öffnen.

4. Zugänge widerrufen

Ändern Sie die Passwörter der WordPress-Administratoren, erneuern Sie die Salts, um deren Sitzungen zu beenden, und widerrufen Sie offengelegte Schlüssel oder Tokens. Ändern Sie immer das Passwort der von WordPress genutzten Datenbank und aktualisieren Sie wp-config.php, denn ein Eindringen mit Lesezugriff auf Dateien kann es offengelegt haben. Ändern Sie auch die Zugangsdaten für cPanel, SFTP/SSH und E-Mail, wenn sie am Einfallsweg beteiligt waren, mehrfach verwendet wurden oder der Angreifer sie lesen konnte. Aktualisieren Sie Core, Plugins und Themes auf unterstützte Versionen und schließen Sie den Einfallsweg, bevor Sie den Wartungsmodus beenden.

Rückgängig machen

Funktioniert die Website nach dem Ersetzen nicht mehr, halten Sie den Zugang geschlossen, holen Sie die Verzeichnisse aus der Quarantäne zurück und stellen Sie Datenbank oder Dateien aus dem geprüften Wiederherstellungspunkt wieder her. Veröffentlichen Sie den kompromittierten Zustand nicht erneut: Das Zurücksetzen dient dazu, die Wiederherstellung in einer geschlossenen Umgebung fortzusetzen, während Sie eine neue, kontrollierte Bereinigung vorbereiten.

Grenzen von Prüfsummen und WP-CLI

Ein Vergleich des Core prüft nicht die gesamte Datenbank und garantiert nicht, dass Plugins, Themes oder Dateien außerhalb des Core sicher sind. Gleichen Sie exakte Version und Sprache ab, um legitime Abweichungen richtig zu deuten. Sichern Sie auch versteckte Dateien, mu-plugins und Konfigurationen, die Code vor der Anwendung laden können.

Führen Sie keine Befehle aus, die die kompromittierte Installation laden, solange Sie nicht in einer abgeschotteten Umgebung arbeiten. Gehen Sie nicht davon aus, dass das Überspringen normaler Plugins das Laden jeder Persistenz verhindert. Notieren Sie jede Ersetzung und bewahren Sie eine Kopie der Beweise außerhalb der öffentlichen Website auf.

Wenn Sie das lieber uns überlassen

Liegt Ihr WordPress bei einem anderen Anbieter, holen wir es mit jedem bestellten Tarif zu uns und wenden dieses Verfahren kostenlos an, bevor wir es hier veröffentlichen. Was das umfasst, lesen Sie unter Rettung gehackter Websites.