--- title: "Gehackte WordPress-Seite erkennen: Anzeichen prüfen und erste Schritte" date: 2026-09-30T21:17:09+02:00 modified: 2026-11-08T22:09:11+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-gehackt-erkennen-anzeichen-erste-schritte keywords: - WordPress - Sicherheit - Malware - WP-CLI - DSGVO reading_time: 8 --- # 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. **Kurzfassung:** Notieren Sie zuerst, was Sie beobachten und seit wann. Sichern Sie dann den aktuellen Zustand von Dateien und Datenbank, bevor Sie etwas ändern. Prüfen Sie mit `wp core verify-checksums` veränderte Kerndateien, suchen Sie PHP-Dateien in `wp-content/uploads`, unbekannte Administratoren und Must-Use-Plugins. Bestätigt sich der Verdacht, ändern Sie alle Zugangsdaten, erneuern die Sicherheitsschlüssel mit `wp config shuffle-salts` und informieren den Hoster. Sind personenbezogene Daten betroffen, prüfen Sie die Meldepflicht nach Art. 33 DSGVO innerhalb von 72 Stunden. ## Voraussetzungen - [ ] WordPress 7.1 auf PHP 8.x - [ ] SSH-Zugang mit WP-CLI; 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. > **Prüfen:** 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. ```bash $ 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](https://s-edv.com/anleitungen/wordpress-backup-server-cronjob-shell-skript). > **Prüfen:** 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 Beispiel wurden dafür eine Zeile an `wp-includes/version.php` angehängt und eine fremde Datei in `wp-admin` abgelegt. Die Ausgabe: ```bash $ wp core verify-checksums ``` ```plaintext 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. > **Prüfen:** 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. ```bash $ find wp-content/uploads -type f -name "*.php" ``` Im Beispiel 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“. ```bash $ 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:** ```bash $ 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. > **Prüfen:** 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: ```bash $ 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: ```bash $ wp db search ' **Prüfen:** 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: ```bash $ wp config shuffle-salts $ wp user reset-password $(wp user list --role=administrator --field=user_login) ``` Im Beispiel 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](https://s-edv.com/anleitungen/wordpress-login-zwei-faktor-authentifizierung-einrichten) 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. > **Prüfen:** 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 | Fehler | Folge | Besser | | --- | --- | --- | | Sofort ein altes Backup zurückspielen | Lücke und Beweise weg, Angriff wiederholt sich | Erst Zustand sichern und Ursache eingrenzen | | Nur die sichtbare Schaddatei löschen | Hintertür bleibt, Befall kehrt zurück | Kern, Uploads, Must-Use-Plugins und Benutzer prüfen | | Passwörter nicht ändern | Angreifer meldet sich erneut an | Alle Zugänge ändern, Salts erneuern | | „usage: wp user session destroy [] [--all]“ | Befehl ohne Benutzernamen aufgerufen | Benutzer angeben oder `wp config shuffle-salts` nutzen | | Prüfung nur als angemeldeter Administrator | Weiterleitungen für Besucher bleiben unentdeckt | Im privaten Fenster und über eine Suchmaschine aufrufen | | Vorfallssicherung im Webspace ablegen | Archiv mit Zugangsdaten öffentlich abrufbar | Außerhalb des Webroots oder lokal speichern | ## 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](https://s-edv.com/anleitungen/wordpress-wartungsmodus-maintenance-datei-beheben-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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=34) übernimmt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden, wöchentliche Backups auf externen Speicher sowie Einrichtung und Wartung einer Firewall. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=34). ## Weiterführende Anleitungen und Quellen - [WordPress-Login mit Zwei-Faktor-Authentifizierung absichern](https://s-edv.com/anleitungen/wordpress-login-zwei-faktor-authentifizierung-einrichten) - [WordPress-Backup per Cronjob und Shell-Skript](https://s-edv.com/anleitungen/wordpress-backup-server-cronjob-shell-skript) - [XML-RPC in WordPress deaktivieren oder einschränken](https://s-edv.com/anleitungen/wordpress-xml-rpc-deaktivieren-einschraenken) - [WordPress-Dokumentation: FAQ My site was hacked](https://wordpress.org/documentation/article/faq-my-site-was-hacked/) - [WP-CLI-Handbuch: wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/) - [WordPress Advanced Administration: Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) - [DSGVO (Verordnung (EU) 2016/679), Art. 33](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679)