WordPress gehackt — was tun? Neun Schritte in Reihenfolge

Wenn WordPress gehackt wurde, kommt zuerst die Seite vom Netz und eine Kopie des befallenen Zustands auf die Seite, dann werden alle Zugänge gewechselt, und erst danach wird aufgeräumt. Wer in umgekehrter Reihenfolge vorgeht, putzt mit offener Tür: Der Angreifer hat seine Zugangsdaten noch und ist in ein paar Tagen wieder drin.

Der häufigste Fehler ist Eile an der falschen Stelle. Die verdächtige Datei sofort löschen, die Sicherung von gestern zurückspielen, das eigene Passwort ändern und weitermachen — das fühlt sich nach Handeln an und lässt fast immer etwas zurück. Ein eingeschleustes Administratorkonto, eine Hintertür in einem Ordner, in den niemand schaut, eine Sicherung, die schon befallen war.

Die neun Schritte unten folgen der Anleitung von WordPress.org für gehackte Seiten und den Leitfäden von Google für gehackte Websites. Die Befehle sind WP-CLI und laufen im Verzeichnis der Installation auf dem Server. Wer keinen Shell-Zugang hat, findet die meisten Prüfungen auch im Kundenmenü des Hosters oder im Backend; dann dauert es länger.

WordPress.org nennt in seiner Hilfe eindeutige Anzeichen: Google oder Bing warnt vor der Seite, der Hoster hat sie gesperrt, Besucher melden Warnungen ihres Virenscanners, jemand beschwert sich, dass von der Seite Angriffe ausgehen, oder es passiert etwas, das niemand veranlasst hat — etwa neue Benutzer. Dazu kommen die leiseren Fälle: fremdsprachige Seiten in der site:-Suche, Weiterleitungen nur für Besucher aus der Google-Suche, E-Mails der Domain, die plötzlich im Spam landen.

Ist noch unklar, ob überhaupt etwas passiert ist, helfen die sechs Prüfungen in Gehackte Website erkennen. Dieser Beitrag beginnt dort, wo der Befund feststeht.

Die Seite vom Netz nehmen und den Hoster informieren#

Google rät im Leitfaden für gehackte Seiten, die Seite ganz offline zu nehmen, damit sie keine Schadsoftware mehr an Besucher ausliefert und der Angreifer während der Arbeit weniger dazwischenfunkt. Wichtig ist das Wie: Die Antwort soll von außerhalb der befallenen Installation kommen, etwa als Statuscode 503 von einer Wartungsseite, die der Hoster vor die Seite schaltet. Ein Wartungsplugin innerhalb der befallenen Installation ist dafür ungeeignet — es läuft im selben Code, den der Angreifer kontrolliert.

Ein Eintrag in der robots.txt reicht nicht. Er hält nur Suchmaschinen ab, Besucher bekommen den Schadcode weiterhin. Und dass die Seite ein paar Tage offline ist, schadet laut Google dem späteren Ranking voraussichtlich nicht.

Im selben Zug gehört der Hoster informiert. Auf einem geteilten Server kann der Angriff mehr betroffen haben als die eigene Seite, und der Hoster hat die Zugriffsprotokolle, die du für Schritt 6 brauchst. Frag ausdrücklich danach, wie lange er sie aufbewahrt — viele löschen sie nach wenigen Tagen.

Den befallenen Zustand sichern und notieren#

Bevor irgendetwas gelöscht wird, kommt eine vollständige Kopie auf die Seite: Dateien und Datenbank, so wie sie jetzt sind. WordPress.org empfiehlt diesen „Schnappschuss" ausdrücklich, auch wenn er befallen ist — er ist die einzige Grundlage, um später zu verstehen, was passiert ist, und der Rückfall, falls beim Aufräumen etwas Wichtiges verloren geht.

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

Beide Dateien gehören danach weg vom Server, auf den eigenen Rechner oder in einen getrennten Speicher.

Dann aufschreiben, ehe es verschwimmt: was du gesehen hast, wann du es bemerkt hast (mit Uhrzeit), und was in den Tagen davor geändert wurde — neues Plugin, Theme-Anpassung, neuer Benutzer. WordPress.org nennt das die Grundlage eines Vorfallberichts. Der Zeitpunkt des Bemerkens ist auch der, ab dem eine mögliche Meldefrist nach der DSGVO läuft (Schritt 8).

Den eigenen Rechner prüfen, dann alle Zugänge wechseln#

Die Reihenfolge ist Absicht. WordPress.org weist darauf hin, dass ein Angriff oft auf dem Rechner des Betreibers beginnt: Ein Schadprogramm liest FTP- und Admin-Zugangsdaten mit. Wer auf einem solchen Rechner neue Passwörter vergibt, liefert sie gleich mit. Also zuerst einen vollständigen Virenscan auf jedem Gerät, von dem aus die Seite verwaltet wird.

Dann jeden Zugang neu, nicht nur das WordPress-Passwort. WordPress.org zählt auf: FTP oder SFTP, wp-admin, das Kundenmenü des Hosters und die Datenbank — und zwar für alle Personen, die Zugang haben. Dazu das E-Mail-Postfach, an das WordPress Passwort-Links schickt; wer das kontrolliert, setzt jedes Passwort zurück.

# Wer ist Administrator? Jede Zeile muss jemandem gehören, den du kennst.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Neue Passwörter für alle Konten, die Betroffenen bekommen eine E-Mail
wp user reset-password $(wp user list --field=ID)

# Neue Schlüssel in der wp-config.php: wirft alle angemeldeten Sitzungen hinaus
wp config shuffle-salts

Ein fremdes Administratorkonto zuerst notieren (Name, Anlagedatum), dann löschen. Das Anlagedatum grenzt oft ein, seit wann der Angreifer drin war. Nach einem neuen Datenbank-Passwort beim Hoster muss es auch in der wp-config.php nachgezogen werden, sonst steht die Seite mit „Fehler beim Aufbau der Datenbankverbindung" da. Anwendungspasswörter unter „Benutzer → Profil" gehören ebenfalls durchgesehen: Sie gelten für Programme weiter, auch wenn das Konto ein neues Passwort hat.

Das Ausmaß feststellen#

Jetzt wird gesucht. Der schnellste Befund ist der Vergleich mit den Originaldateien von WordPress.org:

# Kern: veränderte Dateien und, mit --include-root, Fremdes im Hauptverzeichnis
wp core verify-checksums --include-root

# Plugins aus dem Verzeichnis auf WordPress.org (gekaufte fallen durchs Raster)
wp plugin verify-checksums --all

Danach die Stellen, an denen sich Schadcode gern versteckt:

# PHP-Dateien im Upload-Ordner — dort gehören nur Medien hin
find wp-content/uploads -type f -name "*.php"

# Alles, was in den letzten 14 Tagen geändert wurde
find . -type f -name "*.php" -mtime -14 -printf "%TY-%Tm-%Td %p\n" | sort

# Must-Use-Plugins und Drop-ins laden ohne Eintrag in der Plugin-Liste
wp plugin list --status=must-use
wp plugin list --status=dropin

# Typische Verschleierung im Code
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content --include=*.php

# Geplante Aufgaben, die niemand angelegt hat
wp cron event list --fields=hook,next_run_relative,recurrence

base64_decode steht auch in harmlosen Plugins. Ein Treffer ist ein Grund hinzusehen, kein Urteil. Verdächtig ist er, wenn er in einer Datei mit sinnlosem Namen steht, in einer einzigen langen Zeile oder am Anfang einer sonst normalen Datei.

Die Datenbank kommt dazu, weil eingeschleuste Skripte oft gar nicht in Dateien liegen, sondern in Beiträgen, Widgets oder Optionen:

wp option get siteurl
wp option get home
wp db search "<script" --all-tables-with-prefix

Und die .htaccess sowie die wp-config.php von Hand ansehen: Weiterleitungen nur für Besucher von Google und zusätzliche include-Zeilen sind dort klassische Muster. Wie die unveränderte .htaccess aussieht, steht in Die Standard-.htaccess von WordPress.

Einen sauberen Stand herstellen#

Hier fällt die wichtigste Entscheidung: zurückspielen oder neu aufsetzen. Eine Sicherung hilft nur, wenn sie nachweislich älter ist als der Einbruch. Den Zeitpunkt grenzen das Anlagedatum eines fremden Kontos, die Änderungsdaten aus Schritt 4 und der Knick in der Search Console ein; wer keinen sicheren Zeitpunkt hat, kann der jüngsten Sicherung nicht trauen.

Ohne verlässliche Sicherung wird neu aufgesetzt, Teil für Teil, mit denselben Versionen, die vorher liefen — WordPress.org warnt, dass eine andere Version die Seite leicht unbenutzbar macht. Und ausdrücklich nicht über die Neuinstallation im Backend: Die läuft im befallenen WordPress selbst.

# Kern: alte Verzeichnisse weg, dieselbe Version frisch von WordPress.org
VERSION=$(wp core version)
rm -rf wp-admin wp-includes
wp core download --version=$VERSION --skip-content --force

# Plugins aus dem Verzeichnis: frisch und in derselben Version
wp plugin install <slug> --version=<version> --force

Gekaufte Plugins und Themes kommen frisch aus dem Kundenkonto beim Hersteller, nicht aus der alten Installation. Was nicht mehr gebraucht wird, kommt gar nicht zurück. Aus wp-content/uploads werden nur Medien übernommen. Die wp-config.php am besten neu schreiben und die Werte von Hand übertragen, statt die alte Datei zu behalten.

Die Lücke finden und schließen#

Ein aufgeräumtes WordPress mit derselben Lücke ist in ein paar Tagen wieder befallen. Google nennt als häufigste Wege hinein: einen verseuchten Rechner des Betreibers, schwache oder mehrfach verwendete Passwörter, veraltete Software und nachlässigen Code. Bei WordPress heißt veraltete Software fast immer ein Plugin — die Zahlen dazu stehen in WordPress-Sicherheit prüfen.

Die Zugriffsprotokolle des Hosters zeigen oft den genauen Weg: eine Anfrage an eine Plugin-Datei kurz vor dem ersten verdächtigen Änderungsdatum, eine Reihe von Anmeldeversuchen, ein Upload. Das Plugin, über das es lief, wird aktualisiert oder — wenn es keine Korrektur gibt oder es nicht mehr gepflegt wird — ersetzt.

Google informieren, wenn Google gewarnt hat#

Ob Google die Seite als gefährlich führt, zeigt der Safe-Browsing-Status im Transparenzbericht für jede Adresse, auch ohne Search Console. Für die eigene Domain steht der genaue Befund in der Search Console im Bericht „Sicherheitsprobleme", daneben unter „Manuelle Maßnahmen".

Die Überprüfung wird dort angefordert, aber erst, wenn die Seite sauber und wieder online ist. Google warnt, dass eine verfrühte Anfrage die Warnung nur verlängert, und bittet um eine kurze Beschreibung, was bereinigt und welche Lücke geschlossen wurde. Zur Dauer nennt Google selbst: Phishing etwa einen Tag, Schadsoftware einige Tage, gehackte Inhalte mit Spam bis zu mehrere Wochen.

Seiten, die der Angreifer angelegt hat, sollen nach dem Aufräumen mit 404 oder 410 antworten. Wer sie schneller aus der Suche haben will, nutzt das Werkzeug „Entfernen" in der Search Console.

Prüfen, ob die DSGVO eine Meldung verlangt#

Liegen auf der Seite personenbezogene Daten — Kundenkonten, Bestellungen in WooCommerce, Anfragen aus Formularen, eine Newsletter-Liste —, muss geklärt werden, ob der Angreifer darauf Zugriff hatte. Ist das der Fall, ist es eine Verletzung des Schutzes personenbezogener Daten.

Art. 33 DSGVO verlangt dann eine Meldung an die Aufsichtsbehörde, unverzüglich und möglichst binnen 72 Stunden, nachdem die Verletzung bekannt wurde. Die Meldung kann unterbleiben, wenn die Verletzung voraussichtlich zu keinem Risiko für die Rechte und Freiheiten der Betroffenen führt. In Österreich ist das die Datenschutzbehörde, die dafür ein Online-Formular bereitstellt. Bei voraussichtlich hohem Risiko sind nach Art. 34 auch die Betroffenen selbst zu benachrichtigen. Dokumentiert werden muss der Vorfall nach Art. 33 Abs. 5 in jedem Fall, auch wenn keine Meldung nötig war — die Notizen aus Schritt 2 sind der Anfang davon.

Ob ein konkreter Vorfall meldepflichtig ist, ist eine Einzelfallfrage. Im Zweifel gehört sie zu jemandem mit rechtlicher Zulassung, und zwar innerhalb der Frist, nicht danach.

Härten und ein paar Wochen genau hinsehen#

Nach dem Aufräumen kommt das, was den nächsten Einbruch verhindern soll: Zwei-Faktor-Anmeldung für jeden Administrator, Plugins mit automatischen Updates oder fester Wartung, ungenutzte Plugins gelöscht, DISALLOW_FILE_EDIT in der wp-config.php, Sicherungen an einem Ort, den ein Angreifer mit den Zugangsdaten der Seite nicht überschreiben kann. Die vollständige Liste mit Befehlen steht in WordPress-Sicherheit prüfen.

In den Wochen danach lohnt der wiederholte Blick auf drei Dinge: die Administratorliste, die Prüfsummen aus Schritt 4 und die site:-Suche. Wer seine E-Mails über denselben Server verschickt, sollte zusätzlich prüfen, ob dessen Adresse auf einer Sperrliste gelandet ist — WordPress.org nennt das als eine der ernsteren Folgen, wenn eine Seite für Spam missbraucht wurde.

Was nicht hilft#

Ein Sicherheitsplugin installieren und auf „Bereinigen" drücken. Ein Scanner im befallenen WordPress läuft im selben Code wie die Schadsoftware; er findet Bekanntes und übersieht, was sich gut versteckt. WordPress.org empfiehlt, Scanner innerhalb der Seite und von außen zu kombinieren — als Hinweisgeber, nicht als Ersatz für den Neuaufbau aus Schritt 5.

Nur die auffällige Datei löschen. Die sichtbare Datei ist meist die Nutzlast. Die Hintertür, die sie wieder anlegt, liegt woanders — in einem Must-Use-Plugin, einer Option in der Datenbank, einer geplanten Aufgabe.

Die Sicherung von gestern zurückspielen, ohne den Zeitpunkt zu kennen. Angreifer warten oft, bevor sie die Seite benutzen. Die Sicherung von gestern kann die Hintertür schon enthalten.

Nur das eigene WordPress-Passwort ändern. Solange Datenbank, SFTP, Hoster-Konto und die Sitzungen gleich bleiben, ändert das für den Angreifer nichts.

Die Überprüfung bei Google sofort anfordern. Ist die Seite dann noch nicht sauber, wird die Anfrage abgelehnt, und die Warnung bleibt länger stehen.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol, und das hier ist eine meiner Leistungen. Wer keinen Shell-Zugang hat, keine Zeit oder einfach nicht sicher ist, ob alles erwischt wurde, kann die Arbeit abgeben.

Die Bereinigung selbst hat keinen Festpreis, weil niemand vorher weiß, wie tief es geht. Ich rechne sie nach Aufwand ab, 60 € pro Stunde, und wir sprechen den Rahmen vorher ab. Danach hält die WordPress-Wartung für 49 € im Monat die Seite aktuell und überwacht sie, damit der nächste Fall gar nicht erst eintritt. Wer nur wissen will, wie es um eine Seite steht, die (noch) nicht brennt, bekommt mit dem Sicherheits-Check für 290 € einen Bericht nach Dringlichkeit, inklusive Plugin-Stand — alle Pakete stehen unter Cybersecurity. Anfragen gehen über die Kontaktseite.

Einen ersten Blick von außen gibt es kostenlos: Der Security-Scan prüft ohne Anmeldung unter anderem, ob Dateien wie /.env oder /backup.sql offen liegen, welche fremden Skripte die Seite lädt und wie die Security-Header stehen. WordPress-Version und Plugins prüft er nicht — dafür sind die Befehle aus Schritt 4 da.

Der ehrliche Schluss#

Die meiste Zeit kostet nicht das Löschen, sondern das Suchen und das Neuaufsetzen — und genau das wird übersprungen, wenn die Seite schnell wieder laufen soll. Die Reihenfolge ist der eigentliche Inhalt dieses Beitrags: erst vom Netz und sichern, dann Zugänge, dann suchen, dann sauber aufbauen, dann die Lücke. Wer einen Schritt weglässt, macht die Arbeit in ein paar Wochen ein zweites Mal.

Quellen#

• WordPress.org — FAQ My site was hacked — Anzeichen („creation of new users"), Dokumentieren, Scanner innerhalb und außerhalb der Seite, lokalen Rechner prüfen, Hoster einbeziehen, Sperrlisten für E-Mail, alle Zugänge („FTP / SFTP, WP-ADMIN, CPANEL … and MYSQL"), neue Schlüssel in der wp-config.php, Schnappschuss vor dem Aufräumen, dieselbe Version neu installieren, nicht über die Neuinstallation in wp-admin
• web.dev (Google) — Quarantine your site — Seite offline nehmen, 503 von außerhalb der befallenen Installation, robots.txt reicht nicht, Hoster informieren, alle Konten und Passwörter
• web.dev (Google) — Identify the vulnerability — infizierter Rechner, schwache Passwörter, veraltete Software, nachlässiger Code
• web.dev (Google) — Clean and maintain your site — neueste Software, ungenutzte Plugins entfernen, Werkzeug „Entfernen", alle Passwörter ändern
• web.dev (Google) — Request a review — Voraussetzungen, Beschreibung der Bereinigung, Bearbeitungsdauer für Spam, Schadsoftware und Phishing
• Google Search Console — Bericht „Sicherheitsprobleme" und Google Transparenzbericht — Safe-Browsing-Status
• Datenschutz-Grundverordnung (EU) 2016/679, Art. 33 und 34 und Österreichische Datenschutzbehörde — Meldung Data Breach — „unverzüglich und möglichst binnen 72 Stunden", Ausnahme bei voraussichtlich keinem Risiko, Online-Formular
• WP-CLI-Befehle — core verify-checksums (--include-root), plugin verify-checksums, core download (--skip-content, --force), plugin install (--force), plugin list (must-use, dropin), user list, user reset-password, config shuffle-salts, db export, db search, cron event list