WordPress gehackt – was du jetzt in welcher Reihenfolge tust

Woran du erkennst, dass WordPress gehackt wurde

Nicht jede kaputte Website ist gehackt. Ein weißer Bildschirm nach einem Plugin-Update, ein abgelaufenes SSL-Zertifikat oder eine überlastete Datenbank fühlen sich ähnlich bedrohlich an, haben aber harmlose Ursachen. Ein Hack ist es dann, wenn jemand ohne deine Erlaubnis etwas verändert hat.

Eindeutige Anzeichen:

• Dein Hoster meldet Schadcode, hat Dateien gesperrt oder das ganze Paket deaktiviert.
• Google zeigt in den Suchergebnissen „Diese Website wurde möglicherweise gehackt“, oder Browser warnen vor dem Aufruf.
• In Benutzer steht ein Administrator, den niemand angelegt hat.
• Besucher landen auf Glücksspiel-, Pharma- oder Fake-Shop-Seiten.
• Deine E-Mails kommen plötzlich nicht mehr an, weil die Server-IP auf einer Spam-Blacklist steht.

Zwei Varianten übersiehst du als Betreiber leicht, weil sie sich gezielt vor dir verstecken. Bei bedingten Weiterleitungen werden nur Besucher umgeleitet, die über Google kommen oder ein Smartphone nutzen. Wer die Adresse direkt eintippt und eingeloggt ist, sieht die normale Website. Beim sogenannten Keyword-Hack bekommt nur der Googlebot Spam-Seiten ausgeliefert, oft mit japanischen Schriftzeichen oder Markennamen. Gib bei Google site:deinedomain.de ein: Tauchen dort Seiten auf, die du nie angelegt hast, ist das ein starkes Indiz. In der Google Search Console zeigt die URL-Prüfung, was Google tatsächlich abruft.

Die erste Stunde: Schaden begrenzen

Der Reflex ist, sofort zu löschen und aufzuräumen. Das zerstört aber genau die Spuren, die du später brauchst, um die Lücke zu finden. Geh deshalb in dieser Reihenfolge vor:

Nach der Bereinigung änderst du die Passwörter ein zweites Mal. Solange noch eine Hintertür offen ist, kann der Angreifer die neuen Zugangsdaten mitlesen.

Backup einspielen: nur mit dem richtigen Stand

Ein Backup ist der schnellste Weg zurück, aber nur, wenn es aus der Zeit vor dem Einbruch stammt. Viele Hacks bleiben wochenlang unbemerkt, weil die Angreifer die Website zunächst nur als Spam-Schleuder nutzen. Hoster-Backups bei Shared Hosting reichen dagegen oft nur wenige Wochen zurück. Frag deinen Anbieter nach dem genauen Zeitraum.

Selbst ein sauberes Backup löst nur die Hälfte des Problems. Es stellt die Website wieder her, lässt aber das veraltete Plugin oder das gestohlene Passwort, über das der Angreifer hereinkam, unverändert. Wer nur zurückspielt, wird häufig nach wenigen Tagen erneut gehackt.

Wo sich Schadcode in WordPress versteckt

Angreifer legen selten nur eine Datei ab. Meist gibt es eine sichtbare Wirkung, etwa die Weiterleitung, und daneben eine oder mehrere Hintertüren, um nach einer Bereinigung wiederzukommen.

Typisch für eingeschleusten PHP-Code ist eine Kombination aus eval, base64_decode und gzinflate, oft in einer einzigen sehr langen Zeile. Das Änderungsdatum der Dateien hilft nur begrenzt, weil Angreifer es gern auf ein altes Datum zurücksetzen.

Bietet dein Hoster SSH-Zugang und WP-CLI, prüfen diese Befehle die Dateien gegen die Originale von WordPress.org:

$ wp core verify-checksums            # Core-Dateien geändert oder hinzugefügt?
$ wp plugin verify-checksums --all    # Plugins aus dem offiziellen Verzeichnis
$ wp user list --role=administrator   # Wer hat Admin-Rechte?
$ wp cron event list                  # Welche geplanten Aufgaben laufen?
$ find wp-content/uploads -name "*.php"   # PHP-Dateien, wo nur Medien liegen sollten

Premium-Plugins und gekaufte Themes kann verify-checksums nicht prüfen, weil WordPress.org dafür keine Prüfsummen hat. Die vergleichst du mit einem frischen Download beim Hersteller.

Sauber neu aufsetzen statt einzelne Dateien flicken

Gefundenen Schadcode Datei für Datei zu entfernen, ist verlockend. In der Praxis bleibt dabei fast immer eine Hintertür übrig, die man nicht kannte. Zuverlässiger ist es, alles Austauschbare aus sauberen Quellen neu einzuspielen und nur die eigenen Inhalte zu übernehmen:

1. Die Ordner wp-admin und wp-includes vollständig löschen und aus einem frischen Download der gleichen WordPress-Version neu hochladen. Die WordPress-FAQ rät dabei zu FTP statt zur Neuinstallation im Backend, weil diese nur vorhandene Dateien überschreibt und zusätzliche Dateien liegen lässt.
2. Jedes Plugin und Theme löschen und neu aus dem offiziellen Verzeichnis oder vom Hersteller installieren. Was deaktiviert ist oder nicht mehr gebraucht wird, kommt nicht zurück. „Kostenlose“ Versionen von Premium-Themes aus inoffiziellen Quellen enthalten häufig selbst schon Hintertüren.
3. In wp-content/uploads/ alle PHP-Dateien entfernen und den Rest stichprobenartig prüfen.
4. In wp-config.php die Sicherheitsschlüssel neu erzeugen, über den offiziellen Generator. Damit werden alle angemeldeten Sitzungen beendet, auch die des Angreifers.
5. Unbekannte Benutzer löschen, das Datenbankpasswort ändern und in wp-config.php eintragen.
6. Danach WordPress, Plugins, Themes und die PHP-Version auf den aktuellen Stand bringen.

Das Einfallstor finden, sonst kommt der Angreifer wieder

Die Bereinigung ist erst abgeschlossen, wenn du weißt oder zumindest stark eingrenzen kannst, wie der Angreifer hereingekommen ist. Die häufigsten Wege bei kleinen Websites:

• ein Plugin oder Theme mit bekannter, aber nicht eingespielter Sicherheitslücke,
• ein erratenes oder anderswo gestohlenes Admin-Passwort ohne zweiten Faktor,
• abgegriffene FTP-Zugangsdaten von einem befallenen Rechner,
• eine vergessene zweite Installation im selben Webspace.

Hilfreich ist der Abgleich mit den Access-Logs: Such dir den Zeitpunkt der ersten verdächtigen Dateiänderung und schau, welche Anfragen kurz davor kamen. Mehrere POST-Anfragen an eine Plugin-Datei, die normalerweise niemand direkt aufruft, sind ein deutlicher Hinweis. Wie du Core- und PHP-Updates dauerhaft im Blick behältst, steht im Beitrag zu WordPress- und PHP-Sicherheitsupdates.

Google, Besucher und Datenschutz

Hat Google deine Website markiert, findest du die Details in der Search Console im Bericht Sicherheitsprobleme. Erst wenn alles behoben ist, wählst du dort Überprüfung anfordern. Google erwartet laut Hilfeseite zum Bericht eine Beschreibung des Problems, der Gegenmaßnahmen und einen Nachweis, dass sie gewirkt haben. Die Prüfung kann einige Tage bis mehrere Wochen dauern. Wer zu früh einreicht und abgelehnt wird, verlängert die Zeit mit Warnhinweis nur.

Hat der Angreifer Zugriff auf personenbezogene Daten gehabt, etwa gespeicherte Formulareinträge, Kundenkonten oder Kommentare mit E-Mail-Adressen, kommt die Datenschutzseite dazu. Nach Art. 33 DSGVO ist eine solche Verletzung grundsätzlich innerhalb von 72 Stunden der Aufsichtsbehörde zu melden, außer sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Ob das bei dir zutrifft, klärst du mit deinem Datenschutzbeauftragten oder einer Anwältin. Dieser Artikel ist keine Rechtsberatung.

Selbst bereinigen oder machen lassen?

• Kleine Info-Website, Backup vor dem Einbruch vorhandenSelbst machen ist realistisch – Mit SSH-Zugang, sauberem Backup und den Schritten oben gut machbar. Rechne mit einem halben bis ganzen Arbeitstag.
• Kein sauberes Backup, Spam nur für Google sichtbarHilfe holen – Versteckte Hintertüren sind ohne Erfahrung schwer vollständig zu finden. Wer nur einen Teil erwischt, ist oft nach kurzer Zeit wieder befallen.
• Shop, Mitgliederbereich oder KundendatenProfessionell bereinigen lassen – Hier geht es auch um Datenschutzpflichten und Zahlungsdaten. Dokumentation und Ursachenanalyse sollten belastbar sein.

Wenn du einen Dienstleister beauftragst, frag vorher, ob er nur Schadcode entfernt oder auch das Einfallstor sucht und schriftlich dokumentiert. Nur das zweite verhindert den nächsten Vorfall.

Danach: weniger Angriffsfläche

Nach einem Hack lohnt der ehrliche Blick darauf, wie viel WordPress deine Website wirklich braucht. Jedes Plugin, das nur für eine Kleinigkeit installiert wurde, ist ein Kandidat zum Entfernen. Regelmäßige Updates müssen fest jemandem zugeordnet sein. Was das kostet, rechnet der Artikel zu WordPress-Wartung und Kosten durch.

Bei reinen Informationsseiten, die sich selten ändern, gibt es eine weitergehende Möglichkeit: Die öffentliche Website wird als statisches HTML ausgeliefert, und WordPress läuft, wenn überhaupt, nur noch geschützt im Hintergrund. Dann gibt es am öffentlichen Frontend keinen Login, kein PHP und keine Datenbank mehr, die angegriffen werden können.

Wie das funktioniert und wo die Grenzen liegen, steht unter WordPress als Static Site.

Ob deine Website für eine statische Auslieferung infrage kommt, zeigt der Eignungscheck in zwei Minuten.