WordPress gehackt? 12 Anzeichen, die Sie kennen sollten

Die wichtigsten Anzeichen dafür, dass Ihr WordPress gehackt wurde, sind selten spektakulär: Admin-Konten, die niemand angelegt hat, PHP-Dateien zwischen Ihren Bildern, Spamseiten oder Weiterleitungen, die Sie selbst nie zu Gesicht bekommen. Angreifer wollen, dass die Website weiterläuft. Deshalb verstecken sie sich vor eingeloggten Administratoren und zeigen ihre Inhalte nur Suchmaschinen oder ausgewählten Besuchern.

Im Folgenden finden Sie 12 Anzeichen, sortiert nach dem Ort, an dem sie auffallen, jeweils mit einer konkreten Prüfung. Einige Prüfungen nutzen WP-CLI, die Kommandozeile für WordPress. Dateimanager und Datenbank-Tool Ihres Hosters funktionieren ebenfalls, nur langsamer.

WordPress gehackt? Anzeichen, die Ihre Besucher bemerken

1. Weiterleitungen nur auf dem Smartphone oder von Google aus

Viele Infektionen leiten nur einen Teil der Besucher um: Menschen am Smartphone oder solche, die über eine Google-Suche kommen. Googles Spamrichtlinien beschreiben beide Tricks: Cloaking (Suchmaschinen sehen andere Inhalte als Menschen) und Weiterleitungen, die nur mobile Nutzer auf eine Spam-Domain schicken. Wer die eigene Adresse am Desktop eintippt, sieht eine ganz normale Website.

So prüfen Sie es: Suchen Sie auf dem Smartphone, im Mobilfunknetz und nicht eingeloggt, nach Ihrer Website und tippen Sie auf das Suchergebnis. Im Terminal vergleichen Sie einen normalen Abruf mit einem „mobilen Besucher von Google“:

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' \
  -e 'https://www.google.de/' https://www.ihre-domain.de/

Ein 301 oder 302 auf eine fremde Domain nur im zweiten Ergebnis ist ein deutliches Warnsignal. JavaScript-Weiterleitungen erkennen Sie auf diese Weise nicht. Prüfen Sie deshalb auch den Quelltext auf unbekannte Skripte.

2. Warnungen von Browser oder Virenscanner

Zeigt der Browser eine rote Vollbild-Warnung oder melden Kunden, dass ihr Virenschutz Ihre Seite blockiert, hat meist schon eine Sperrliste Malware oder Phishing auf Ihrer Domain erkannt. So prüfen Sie es: Fragen Sie Ihre Domain im Safe-Browsing-Websitestatus von Google ab und lassen Sie sich einen Screenshot der genauen Meldung schicken.

Anzeichen in den Google-Suchergebnissen

3. Spamseiten in der site:-Suche

Eingeschleuste Seiten für Casinos, Potenzmittel oder gefälschte Markenware tauchen oft zuerst bei Google auf, bevor Sie sie irgendwo anders bemerken. So prüfen Sie es: Suchen Sie nach site:ihre-domain.de und achten Sie auf fremdsprachige Titel oder Themen, die Sie nie veröffentlicht haben. Mit Zusatzbegriffen wie casino, viagra oder kredit grenzen Sie die Suche ein.

4. Sicherheitsprobleme in der Search Console

Ist Ihre Website in der Google Search Console bestätigt, öffnen Sie dort den Bericht Sicherheitsprobleme. Dort listet Google erkannte Probleme auf, etwa gehackte Inhalte oder Malware. So prüfen Sie es: Stellen Sie sicher, dass die Property bestätigt ist und ihre Nachrichten bei jemandem ankommen, der sie auch liest. Ein leerer Bericht ist eine gute Nachricht, aber kein Beweis.

Anzeichen auf dem Server und im Hosting-Konto

5. Sperrung durch den Hoster oder hohe CPU-Last

Hoster sperren Konten, die Spam versenden, Phishing-Seiten ausliefern oder den Server überlasten. Steigt die CPU-Last, ohne dass mehr Besucher kommen, kann ein Krypto-Miner oder Spam-Skript auf Ihrem Konto laufen. So prüfen Sie es: Lesen Sie die Nachricht des Hosters vollständig, denn oft nennt sie konkrete Dateien, und sehen Sie sich die Ressourcen-Grafiken im Kundenbereich an. Mit SSH-Zugang zeigt ps aux --sort=-%cpu | head die aktivsten Prozesse.

6. Spam-Versand und Sperrlisten

Kommen Ihre eigenen E-Mails plötzlich zurück oder erhalten Sie Unzustellbarkeitsmeldungen zu Mails, die Sie nie geschrieben haben? Dann verschickt womöglich ein Skript Spam über Ihren Server. So prüfen Sie es: Fragen Sie Ihren Hoster, ob sich das ausgehende Mailvolumen verändert hat, und prüfen Sie die IP-Adresse Ihres Servers mit einem öffentlichen Blacklist-Check.

7. PHP-Dateien in wp-content/uploads

In den Upload-Ordner gehören Bilder und Dokumente, kein Code. Eine PHP-Datei dort ist häufig eine Webshell, also eine Hintertür, über die Angreifer Befehle ausführen. So prüfen Sie es:

find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

Manche Plugins legen eine leere index.php in ihre Ordner, damit keine Verzeichnisliste erscheint. Öffnen Sie jeden Treffer und sehen Sie nach, was er tatsächlich enthält.

8. Veränderte Kerndateien

Angreifer verstecken Code gern in den Kerndateien von WordPress, weil die niemand liest. So prüfen Sie es: wp core verify-checksums vergleicht Ihre Kerndateien mit den offiziellen Prüfsummen von WordPress.org und meldet jede Abweichung (Befehlsreferenz). wp plugin verify-checksums --all leistet dasselbe für Plugins, allerdings nur für solche aus dem Verzeichnis auf WordPress.org.

9. Unerwartete Änderungen an .htaccess oder wp-config.php

Ein paar zusätzliche Zeilen in der .htaccess genügen, um Besucher abhängig von Herkunft oder Browser umzuleiten. Eine Zeile in der wp-config.php oder eine auto_prepend_file-Einstellung in der .user.ini kann Schadcode laden, bevor WordPress überhaupt startet. So prüfen Sie es: Vergleichen Sie beide Dateien mit Ihrem letzten sauberen Backup und suchen Sie nach typischen Verschleierungs- und Prepend-Tricks:

grep -rnE --include='*.php' 'eval\(|base64_decode\(|gzinflate\(|str_rot13\(' . | head -50
grep -rn 'auto_prepend_file' --include='.htaccess' --include='.user.ini' --include='php.ini' .

Auch seriöse Plugins nutzen einige dieser Funktionen. Treffer sind also Hinweise, keine Urteile.

Anzeichen im WordPress-Dashboard

10. Unbekannte Admin-Konten

Ein neues Administratorkonto ist der Klassiker, um sich den Zugang zu sichern, und manche Malware blendet ihr Konto in der Benutzerliste aus. So prüfen Sie es:

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

Die beiden --skip-Optionen verhindern, dass Code aus normalen Plugins und Themes, also auch dort versteckte Malware, die Liste filtert. Must-Use-Plugins und die wp-config.php werden trotzdem geladen; prüfen Sie diese also ebenfalls (Anzeichen 9 und 11). Zeigt WP-CLI mehr Administratoren als die Benutzerübersicht im Dashboard, versteckt etwas ein Konto. Prüfen Sie in jedem Admin-Profil auch die Anwendungspasswörter: Gibt es welche, die niemand aus Ihrem Team angelegt hat?

11. Plugins, die niemand installiert hat

Achten Sie auf Plugins mit nichtssagenden Namen, ohne Autor oder Beschreibung, an deren Installation sich niemand erinnert. Must-Use-Plugins in wp-content/mu-plugins werden automatisch geladen und leicht übersehen. So prüfen Sie es: wp plugin list zeigt die normalen Plugins zusammen mit Must-Use-Plugins und Drop-ins wie object-cache.php; wp plugin list --status=must-use,dropin zeigt nur diese beiden Gruppen.

12. Seltsame Cron-Jobs

Schadcode plant sich gern selbst neu ein, um nach dem Löschen zurückzukehren. So prüfen Sie es:

wp cron event list --fields=hook,next_run_relative,recurrence

Recherchieren Sie jeden Hook, den Sie keinem Ihrer Plugins zuordnen können. Auch Cron-Jobs auf Serverebene zählen: crontab -l oder der Cron-Bereich Ihres Hosting-Panels zeigt sie an.

Die erste Stunde: Was Sie jetzt tun sollten

Deuten eines oder mehrere Anzeichen auf einen Angriff hin, entscheidet die nächste Stunde darüber, wie viel Sie noch herausfinden können. Gehen Sie ruhig und in dieser Reihenfolge vor:

1. Nicht hektisch löschen. Wer die verdächtige Datei oder den unbekannten Admin sofort entfernt, vernichtet Spuren und erwischt selten die ganze Infektion, denn Angreifer hinterlassen oft mehr als einen Weg zurück.
2. Beweise sichern. Erstellen Sie einen vollständigen Snapshot oder ein Backup von Dateien und Datenbank im gehackten Zustand und laden Sie die Access- und Error-Logs des Webservers herunter, die viele Hoster nur begrenzte Zeit aufbewahren. Lagern Sie die Kopie offline und kennzeichnen Sie sie als infiziert.
3. Passwörter von einem sauberen Gerät ändern. Zuerst das Hosting-Konto, dann SFTP/SSH, die Datenbank und alle WordPress-Administratoren. Könnte Ihr eigener Rechner betroffen sein, nehmen Sie ein anderes Gerät, und aktivieren Sie die Zwei-Faktor-Authentifizierung für alle Admins.
4. Den Hoster informieren. Er sieht Server-Logs, andere Websites im selben Konto und den Mailversand und kann die Website oft schnell isolieren.
5. Den Zeitpunkt notieren. Halten Sie fest, wann Sie zum ersten Mal von dem Angriff erfahren haben und was Sie bisher beobachtet haben.

Der letzte Punkt ist für die DSGVO wichtig. Konnte der Angreifer auf Kundendaten, Formulareinträge, Benutzerkonten oder Bestellungen zugreifen, liegt in der Regel eine Datenpanne vor. Nach Art. 33 DSGVO müssen Sie diese unverzüglich und möglichst binnen 72 Stunden, nachdem sie Ihnen bekannt wurde, der zuständigen Aufsichtsbehörde melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko. In Deutschland ist das für Unternehmen in der Regel die Datenschutzaufsichtsbehörde des Bundeslandes, in dem das Unternehmen seinen Sitz hat. Wie Sie das einschätzen, erklärt unser Ratgeber Datenpanne in 72 Stunden melden.

Sobald die Beweise gesichert sind, geht es mit unserer Schritt-für-Schritt-Anleitung zum Entfernen von WordPress-Malware weiter: Website eindämmen, Einfallstor finden, aus sauberen Quellen ersetzen und sämtliche Zugangsdaten ändern.

Security Audit & Compliance, das WordPress-Plugin von secaudit.eu, prüft mehrere dieser Anzeichen für Sie, darunter versteckte Admin-Konten, verdächtige Cron-Events, die Prüfsummen der Kerndateien, Dateiänderungen gegenüber einer Baseline und versteckten SEO-Spam. Es erkennt und meldet; die Bereinigung bleibt Ihre Aufgabe oder die eines Profis.

Häufige Fragen

Kann eine Website gehackt sein, ohne dass man etwas sieht?

Ja. Viele Infektionen sind darauf ausgelegt, für den Betreiber unsichtbar zu bleiben: Sie ignorieren eingeloggte Nutzer, zielen nur auf Suchmaschinen oder laufen ausschließlich auf dem Server. Deshalb reicht ein Blick auf die Startseite nicht aus.

Ist jeder Hack eine Datenpanne nach DSGVO?

Nicht jeder, aber viele. Wurden personenbezogene Daten eingesehen, verändert, gelöscht oder unzugänglich gemacht, handelt es sich um eine Datenpanne. Dokumentieren Sie Ihre Einschätzung in jedem Fall: Art. 33 Abs. 5 verlangt eine Dokumentation jeder Verletzung, auch wenn Sie sie nicht melden.

Soll ich sofort das Backup von gestern einspielen?

Erst wenn Sie den infizierten Zustand gesichert haben und ungefähr wissen, wann der Angriff begann. Ein Backup, das nach dem Einbruch entstanden ist, enthält die Hintertür ebenfalls. Und ohne geschlossenes Einfallstor ist der Angreifer schnell wieder drin.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.