Gehackte WordPress-Seite erkennen: Anzeichen prüfen und erste Schritte

Eine gehackte WordPress-Website fällt selten durch eine verunstaltete Startseite auf. Häufiger sind leise Anzeichen: Besucher werden von Google aus auf fremde Seiten umgeleitet, der Hoster sperrt das Konto wegen Spamversand, oder im Backend taucht ein Administrator auf, den niemand angelegt hat. Diese Anleitung zeigt, woran Sie einen Angriff erkennen, wie Sie den Verdacht mit WP-CLI und Bordmitteln prüfen und welche ersten Schritte Schaden begrenzen, ohne Spuren zu vernichten. Die eigentliche Bereinigung ist ein eigenes Thema; hier geht es um die ersten Stunden.

Voraussetzungen

• WordPress 7.1 (getestet mit 7.1.2) auf PHP 8.x
• SSH-Zugang mit WP-CLI (getestet mit 2.12.0); ohne SSH lassen sich die Prüfungen teilweise per SFTP und im Backend erledigen
• Ein Konto mit der Rolle Administrator oder direkter Zugriff auf Datenbank und Dateien über den Hoster
• Zugang zum Kundenmenü des Hosters und die Kontaktdaten seines Supports
• Speicherplatz außerhalb des Webspace für eine Sicherung des aktuellen Zustands
• Ein älteres Backup aus der Zeit vor dem Angriff, falls vorhanden

Schritt 1: Anzeichen einordnen und dokumentieren

Die WordPress-Dokumentation nennt eine Reihe klarer Anzeichen, im Fachjargon Indicators of Compromise: Die Website steht auf Sperrlisten von Suchmaschinen, der Hoster hat sie deaktiviert, sie wurde als Verteiler von Schadsoftware markiert, Virenscanner der Besucher schlagen an, Dritte melden Angriffe, die von Ihrer Website ausgehen, oder es geschehen Dinge, die niemand veranlasst hat, etwa neue Benutzerkonten.

Typisch für kleinere Unternehmenswebsites sind außerdem:

• Weiterleitungen, die nur bei Besuchern aus Suchmaschinen oder nur auf Mobilgeräten auftreten. Angemeldete Administratoren sehen sie oft nicht.
• Fremde Seiten mit Arzneimittel-, Glücksspiel- oder Shop-Spam in den Suchergebnissen zu Ihrer Domain
• Unbekannte Plugins, Themes oder Dateien mit unauffälligen Namen
• Plötzlich hohe Serverlast oder ausgehende E-Mails, die der Hoster meldet

Bevor Sie irgendetwas ändern, dokumentieren Sie: Was sehen Sie, seit wann, mit Uhrzeit? Welche Änderungen gab es zuletzt, etwa neue Plugins oder Theme-Anpassungen? Machen Sie Bildschirmfotos. Die WordPress-Dokumentation empfiehlt genau diesen Schritt als Grundlage für jeden weiteren Umgang mit dem Vorfall, ob Sie selbst handeln oder einen Dienstleister beauftragen.

Verifizieren: Eine Notiz mit Datum, Uhrzeit, beobachteten Anzeichen und den letzten bekannten Änderungen liegt außerhalb der Website vor.

Schritt 2: Aktuellen Zustand sichern

Sichern Sie Dateien und Datenbank im jetzigen, kompromittierten Zustand. Das klingt paradox, hat aber zwei Gründe: Sie brauchen den Stand für die Ursachenanalyse, und Inhalte, die nach dem letzten sauberen Backup entstanden sind, lassen sich später gezielt übernehmen. Speichern Sie diese Sicherung getrennt und eindeutig beschriftet, damit sie nie versehentlich zurückgespielt wird.

cd /pfad/zu/wordpress
wp db export ~/vorfall-$(date +%F)-db.sql
tar -czf ~/vorfall-$(date +%F)-dateien.tar.gz .

Legen Sie die Archive nicht in den Webspace, sondern ins Home-Verzeichnis oder laden Sie sie herunter. Ein regelmäßiges, automatisches Backup nach diesem Muster beschreibt die Anleitung WordPress-Backup per Cronjob und Shell-Skript.

Verifizieren: Beide Archive liegen außerhalb des Webroots, tar -tzf listet ./wp-config.php, und die SQL-Datei ist nicht leer.

Schritt 3: Kerndateien gegen Prüfsummen vergleichen

WP-CLI vergleicht alle Dateien des WordPress-Kerns mit den offiziellen Prüfsummen von wordpress.org. Im Labor wurden dafür eine Zeile an wp-includes/version.php angehängt und eine fremde Datei in wp-admin abgelegt. Die Ausgabe:

wp core verify-checksums

Warning: File doesn't verify against checksum: wp-includes/version.php
Warning: File should not exist: wp-admin/xyz-helper.php
Error: WordPress installation doesn't verify against checksums.

„doesn't verify against checksum“ heißt: Die Datei wurde verändert. „File should not exist“ heißt: Die Datei gehört nicht zum Lieferumfang. Beides ist in wp-admin und wp-includes ein starkes Warnsignal, denn dort legt weder WordPress noch ein Plugin im Normalbetrieb Dateien ab. Einzelne Treffer im Hauptverzeichnis können harmlos sein, etwa Dateien des Hosters; prüfen Sie diese einzeln.

Plugins aus dem Verzeichnis von wordpress.org prüfen Sie mit wp plugin verify-checksums --all. Themes und kommerzielle Plugins deckt dieser Befehl nicht ab.

Verifizieren: Sie haben eine Liste aller gemeldeten Dateien mit Befund. Bei einer sauberen Installation endet der Befehl mit „Success: WordPress installation verifies against checksums.“

Schritt 4: Nach typischen Hintertüren suchen

Angreifer legen fast immer eine Hintertür an, um nach einer Bereinigung zurückzukehren. Drei Orte lohnen den ersten Blick.

PHP-Dateien im Upload-Ordner: In wp-content/uploads gehören Bilder und Dokumente, keine ausführbaren Skripte.

find wp-content/uploads -type f -name "*.php"

Im Labor fand der Befehl die dort abgelegte Testdatei wp-content/uploads/2026/09/cache.php. Der unauffällige Name ist typisch.

Must-Use-Plugins: Dateien in wp-content/mu-plugins lädt WordPress automatisch, sie lassen sich im Backend nicht deaktivieren. In der Pluginliste erscheinen sie nur unter dem eigenen Reiter „Must-Use“.

wp plugin list --status=must-use,dropin

Die Testdatei wp-sys.php erschien dort mit Status must-use. Fragen Sie bei jedem Eintrag, wer ihn angelegt hat; manche Hoster legen hier eigene Dateien ab.

Kürzlich geänderte PHP-Dateien:

find . -type f -name "*.php" -mtime -7 -not -path "./wp-content/languages/*"

Das Änderungsdatum lässt sich fälschen, der Befehl liefert daher nur Hinweise. Zusammen mit den Prüfsummen aus Schritt 3 ergibt sich aber meist ein klares Bild.

Verifizieren: Jede gefundene Datei ist entweder einem bekannten Plugin oder dem Hoster zugeordnet oder als verdächtig notiert. Löschen Sie in diesem Schritt noch nichts.

Schritt 5: Benutzer, Inhalte und Einstellungen prüfen

Unbekannte Administratoren sind ein häufiges Ergebnis eines Angriffs. Listen Sie alle Konten mit dieser Rolle auf:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Achten Sie auf Namen, die vertrauenswürdig klingen sollen, etwa „wpsupport“, und auf Registrierungsdaten, die zu keinem Mitarbeiterwechsel passen. Im Backend finden Sie dieselbe Liste unter Benutzer → Alle Benutzer, gefiltert nach Rolle.

Eingeschleuster Code steckt oft in Beiträgen oder Optionen der Datenbank. Eine Suche nach Skript-Tags zeigt, wo:

wp db search '<script' --all-tables-with-prefix --stats

Im Labor fand der Befehl den präparierten Beitrag mit einem Skript von fremder Domain in wp_posts:post_content. Nicht jeder Treffer ist schädlich, eingebettete Karten oder Analyse-Codes erzeugen ebenfalls Treffer. Verdächtig sind unbekannte Domains und verschleierter Code.

Prüfen Sie außerdem unter Einstellungen → Allgemein, ob „Jeder kann sich registrieren“ aktiviert und die „Standardrolle eines neuen Benutzers“ auf einen höheren Wert als Abonnent gesetzt wurde. Per WP-CLI: wp option get users_can_register (erwartet 0) und wp option get default_role (erwartet subscriber).

Verifizieren: Alle Administratoren sind bekannten Personen zugeordnet, verdächtige Datenbanktreffer sind notiert, und die Registrierungseinstellungen stehen auf den erwarteten Werten.

Schritt 6: Zugänge sperren und Hoster informieren

Bestätigt sich der Verdacht, nehmen Sie dem Angreifer zuerst den Zugang. Die Reihenfolge ist wichtig: Wer Dateien bereinigt, aber die Passwörter behält, wird in der Regel erneut kompromittiert.

1. Informieren Sie den Hoster. Er sieht Zugriffsprotokolle, die Ihnen fehlen, und kann den Webspace vorübergehend sperren.
2. Ändern Sie Passwörter für Hosting-Kundenmenü, SFTP/SSH und Datenbank. Tragen Sie das neue Datenbankpasswort in wp-config.php ein.
3. Erneuern Sie die Sicherheitsschlüssel. Das meldet alle Benutzer ab, auch den Angreifer:

wp config shuffle-salts
wp user reset-password $(wp user list --role=administrator --field=user_login)

Im Labor bestätigte WP-CLI mit „Success: Shuffled the salt keys.“ und „Success: Passwords reset for 2 users.“ Ohne --skip-email verschickt WordPress an jeden Benutzer eine E-Mail mit Hinweis auf das neue Passwort. Einzelne Benutzer melden Sie mit wp user session destroy BENUTZER --all ab; der Befehl verlangt immer einen Benutzernamen.

Unbekannte Administratoren entfernen Sie mit wp user delete ID --reassign=1, damit deren Inhalte einem bekannten Konto zugeordnet werden. Aktivieren Sie anschließend die Zwei-Faktor-Anmeldung, wie in WordPress-Login mit Zwei-Faktor-Authentifizierung absichern beschrieben.

Sind personenbezogene Daten betroffen, etwa Kundenkonten, Bestellungen oder Formulareingaben, prüfen Sie die Meldepflicht: Nach Art. 33 DSGVO ist eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde zu melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Ihre Dokumentation aus Schritt 1 ist dafür die Grundlage.

Verifizieren: Alle Sitzungen sind beendet, Sie melden sich mit neuem Passwort an, die Liste der Administratoren enthält nur bekannte Konten, und der Hoster hat den Vorfall bestätigt.

Typische Fehler

Häufige Fragen

Reicht ein Sicherheits-Plugin zur Erkennung?

Plugins wie Wordfence oder Sucuri prüfen von innen, externe Scanner von außen. Die WordPress-Dokumentation empfiehlt, beide Ansätze zu kombinieren, weil keiner alles findet. Ein Plugin, das auf einer bereits kompromittierten Installation läuft, kann zudem getäuscht werden. Die Prüfsummen von WP-CLI sind davon unabhängig.

Soll ich die Website während der Prüfung offline nehmen?

Verteilt die Website Schadcode an Besucher oder versendet Spam, ja. Das gelingt über den Hoster oder mit dem Wartungsmodus, siehe WordPress-Wartungsmodus beheben und gezielt nutzen. Beachten Sie, dass der eingebaute Modus nach zehn Minuten endet.

Wie verhindere ich, dass es wieder passiert?

Häufige Einfallstore sind bekannte Lücken in veralteten Plugins und Themes sowie schwache oder mehrfach verwendete Passwörter. Zeitnahe Updates, Zwei-Faktor-Anmeldung, wenige gepflegte Plugins und ein getestetes Backup schließen die häufigsten Wege. Das ist laufende Arbeit und kein einmaliges Projekt. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung einer Firewall.

Testumfang

Wir haben alles in einer lokalen Testinstanz mit WordPress 7.1.2 durchgespielt, in der wir typische Befunde gezielt präpariert hatten. Geprüft haben wir das Aufspüren, etwa einer veränderten Kerndatei mit wp core verify-checksums, und das Aufräumen bis zum Löschen eines zusätzlichen Administrators.

Echte Schadsoftware und Sicherheits-Plugins waren nicht Teil des Tests. Probieren Sie die Schritte deshalb zuerst an einer Kopie Ihrer Website aus, bevor Sie am Live-System arbeiten.

Fazit

Bei einem Verdacht zählt die Reihenfolge: dokumentieren, Zustand sichern, prüfen, dann Zugänge sperren. Mit Prüfsummen, einer Suche nach PHP-Dateien in den Uploads und einem Blick auf Administratoren und Must-Use-Plugins bestätigen oder entkräften Sie den Verdacht meist in einer Stunde. Wenn Sie Updates, Backups und Firewall künftig nicht selbst betreuen möchten, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Login mit Zwei-Faktor-Authentifizierung absichern
• WordPress-Backup per Cronjob und Shell-Skript
• XML-RPC in WordPress deaktivieren oder einschränken
• WordPress-Dokumentation: FAQ My site was hacked
• WP-CLI-Handbuch: wp core verify-checksums
• WordPress Advanced Administration: Hardening WordPress
• DSGVO (Verordnung (EU) 2016/679), Art. 33