WordPress gehackt bereinigen: Schritte nach Malware-Fund

Sperren Sie die Site zuerst für Besucher, beenden Sie laufende PHP-Prozesse und sichern Sie den infizierten Stand. Spielen Sie danach WordPress, Plugins und Themes frisch ein, prüfen Sie Dateiberechtigungen, .htaccess-Dateien, Uploads und Datenbank und tauschen Sie alle Zugangsdaten. Einen Rückfall verhindern Sie nur, wenn Sie das Einfallstor schließen, etwa eine ausgenutzte Sicherheitslücke, einen schwachen Login oder ein manipuliertes Plugin. Eine Überprüfung bei Google beantragen Sie erst, wenn alles behoben ist.

Voraussetzungen

Ohne Zugriff auf den Server lässt sich eine Site nicht sauber bereinigen. Klären Sie deshalb vor dem ersten Handgriff, welche Zugänge Sie haben und welche Sie beim Hoster anfragen müssen.

Benötigt werden:

• Zugang per SFTP oder SSH sowie zum Hosting-Panel, damit Sie Dateien ersetzen und Prozesse beenden können. Bei Shared Hosting übernimmt das gegebenenfalls der Support des Hosters.
• Zugriff auf die Datenbank, etwa über das Hosting-Panel.
• Speicherplatz für eine Sicherung des infizierten Stands.
• Optional WP-CLI für den Core-Checksum-Vergleich und einen Scanner wie Wordfence für die Analyse.
• Bei einer Google-Warnung: Zugang zur Search Console der betroffenen Property.

Sicher sein, dass wirklich ein Befall vorliegt, sollten Sie, bevor Sie eingreifen. Die WordPress-Dokumentation nennt eine kompromittierte Website als mögliche Ursache für Fehler, wenn Konfigurationsfehler in der wp-config.php und Hosting-Probleme ausgeschlossen sind. Haben Sie Malware gefunden, etwa durch einen Scanner oder eine Warnung von Google, können Sie direkt mit Schritt 1 beginnen.

Vorgehen in neun Schritten

Die Reihenfolge ist Absicht: Erst stoppen Sie die Ausbreitung, dann sichern Sie Beweise, dann räumen Sie auf, und erst danach geht die Site wieder online. Wer diese Reihenfolge vertauscht, räumt unter Umständen auf einer Site auf, die sich gleichzeitig neu infiziert.

Eindämmen: die ersten Stunden

In den ersten Stunden geht es nicht ums Reinigen, sondern darum, dass nichts mehr passiert, während Sie arbeiten.

1. Website sperren.
   • Zweck: Besucher bekommen keine Schadsoftware ausgeliefert, und während der Bereinigung kommen keine neuen Zugriffe des Angreifers durch. Ich sperre die Website grundsätzlich, bevor ich mit dem Aufräumen beginne. Das gelingt über eine Funktion des Hosters oder einen Zugriffsschutz auf Serverebene, den Sie nicht über eine möglicherweise manipulierte .htaccess der Site selbst einrichten sollten.
   • Prüfpunkt: Rufen Sie die Site von einem fremden Netz aus auf. Sie sehen eine Sperrseite oder einen Zugriffsschutz, keine WordPress-Seite.
2. Laufende PHP-Prozesse beenden.
   • Zweck: Ich hatte es mit selbst replizierender Malware zu tun. Solange ein solcher Prozess läuft, bringt Löschen wenig, weil sich der Schadcode erneut verteilen kann. Ich beende deshalb zuerst den PHP-Prozess und räume erst danach auf.
   • Prüfpunkt: In der Prozessliste läuft kein PHP-Prozess der Site mehr, und gelöschte Testdateien tauchen nicht wieder auf.
3. Den infizierten Stand sichern.
   • Zweck: Wordfence empfiehlt, vor dem Reparieren oder Löschen verdächtiger Dateien eine Sicherung der Datei oder der gesamten Website anzulegen. So können Sie später nachvollziehen, wie der Angreifer vorging, und versehentlich gelöschte Inhalte zurückholen.
   • Prüfpunkt: Dateien und Datenbankexport liegen außerhalb des Webverzeichnisses, und die Sicherung lässt sich nicht über eine URL abrufen.

Achtung: Löschen Sie nichts, bevor die Sicherung aus Schritt 3 vollständig vorliegt.

Bereinigen: Dateien, Plugins, Datenbank

Im Kern ersetzen Sie, was sich ersetzen lässt, und prüfen von Hand, was nicht ersetzbar ist.

4. Dateiberechtigungen und .htaccess-Dateien prüfen.
   • Zweck: Angreifer verändern Berechtigungen und legen eigene .htaccess-Dateien an oder manipulieren vorhandene. Ich suche deshalb gezielt nach geänderten Dateiberechtigungen und nach .htaccess-Dateien. Prüfen Sie dabei die gesamte Installation, nicht nur das Hauptverzeichnis. Google nennt Verzeichnisse mit zu weitreichenden Berechtigungen ausdrücklich als typischen Weg für Hacks.
   • Prüfpunkt: Sie haben eine Liste aller .htaccess-Dateien und können jede Regel erklären. Berechtigungen weichen nirgends ohne Grund von den übrigen Verzeichnissen ab.
5. Frisches WordPress einspielen.
   • Zweck: Statt einzelne Core-Dateien zu flicken, ersetzen Sie die Core-Dateien vollständig durch eine frische Kopie. Das betrifft wp-admin, wp-includes und die Dateien im Hauptverzeichnis. Die wp-config.php prüfen Sie von Hand, den Ordner wp-content gesondert (Schritte 6 und 7).
   • Prüfpunkt: wp core verify-checksums meldet keine veränderten, fehlenden oder zusätzlichen Core-Dateien. Beachten Sie die Grenze: Der Befehl prüft den Core, nicht automatisch Plugins, Themes, Uploads, Datenbank oder Serverkonfiguration.
6. Frische Plugins einspielen, alte löschen.
   • Zweck: Ich lösche die vorhandenen Plugin-Verzeichnisse und spiele frische Versionen ein, statt sie zu überschreiben. Beim Überschreiben bleiben zusätzliche, vom Angreifer abgelegte Dateien im Plugin-Ordner liegen. Plugins, die Sie nicht brauchen, kommen gar nicht mehr zurück. Raubkopierte Premium-Plugins und -Themes („nulled“) beschreibt Wordfence als mögliche Quelle von Backdoors. Beziehen Sie Premium-Produkte nur vom Hersteller. Themes mit eigenem Code vergleichen Sie mit Ihrem Entwicklungsstand.
   • Prüfpunkt: Im Plugin-Ordner liegen nur frisch eingespielte Plugins aus einer Quelle, die Sie benennen können.
7. Uploads und Datenbank prüfen.
   • Zweck: Schadcode sitzt nicht nur in Dateien. Wordfence beschreibt, dass er auch in WordPress-Optionen oder in Plugin- und Theme-Optionen der Datenbank gespeichert sein kann. Suchen Sie außerdem im Upload-Ordner nach PHP-Dateien, die dort nicht hingehören. Ein Scanner hilft, aber nicht jeder Fund ist Schadcode: Auch legitime Plugins, vor allem Backup-Plugins mit Wiederherstellungs-Installern, enthalten Code, der einem Scanner verdächtig erscheint.
   • Prüfpunkt: Der Scan zeigt keine ungeklärten Funde mehr. Jeden verbliebenen Fund haben Sie einzeln bewertet und dokumentiert.

Absichern und freigeben

Erst wenn die Site sauber ist, tauschen Sie die Zugänge und geben sie wieder frei. Würden Sie die Passwörter früher ändern, könnte der Angreifer sie über noch vorhandene Hintertüren erneut abgreifen.

8. Zugangsdaten ersetzen.
   • Zweck: Der Angreifer kennt möglicherweise Passwörter, und Brute-Force-Angriffe probieren automatisiert Benutzername-Passwort-Kombinationen, bis eine funktioniert. Ersetzen Sie die Passwörter aller WordPress-Konten, der Datenbank, von SFTP/SSH und des Hosting-Panels. Erneuern Sie die Schlüssel (Salts) in der wp-config.php und löschen Sie unbekannte Administratorkonten.
   • Prüfpunkt: Jedes Benutzerkonto hat einen bekannten Besitzer, und alle Zugangsdaten sind neu und einzigartig.
9. Freigeben und beobachten.
   • Zweck: Heben Sie die Sperre auf und beobachten Sie die Site eng. Scannen Sie erneut, prüfen Sie die Core-Checksums und kontrollieren Sie, ob neue Dateien oder Prozesse auftauchen. Bei einer Google-Warnung folgt nun die Überprüfung (siehe unten).
   • Prüfpunkt: Nach der Freigabe erscheinen keine neuen verdächtigen Dateien, Konten oder Prozesse.

Typische Fehler und wie man sie erkennt

Rückfälle entstehen oft durch unvollständige Bereinigung. Die folgenden Fehler fallen oft erst auf, wenn die Warnung oder der Schaden zurückkehrt.

• Bereinigung nur an den sichtbaren URLs: Google weist darauf hin, dass die Beispiel-URLs im Sicherheitsbericht nur eine Stichprobe sind und keine vollständige Liste betroffener Seiten. Erkennbar ist der Fehler, wenn die Warnung nach dem Prüfantrag bestehen bleibt.
• Prozess läuft noch: Sie löschen Dateien, und sie erscheinen kurz darauf wieder. Beenden Sie den PHP-Prozess (Schritt 2), bevor Sie weiterarbeiten.
• Checksummen als Freigabe verstehen: wp core verify-checksums sagt nichts über Plugins, Uploads oder Datenbank. Ein grünes Ergebnis bedeutet nur, dass der Core unverändert ist.
• Scanner-Funde ungeprüft löschen: Legitime Plugins können Fehlalarme auslösen. Erkennbar ist das daran, dass nach dem Löschen eine Funktion ausfällt. Deshalb zuerst sichern (Schritt 3).
• Datenbank vergessen: Schadcode in Optionen übersteht jede Dateibereinigung. Erkennbar ist das an Weiterleitungen oder fremden Inhalten, obwohl alle Dateien sauber sind.
• Ein altes Backup zurückspielen, ohne die Lücke zu schließen: Die Site ist dann zwar kurz sauber, aber derselbe Weg steht offen. Der Fehler zeigt sich, wenn der Befall wiederkehrt.
• Überprüfung zu früh beantragen: Google verlangt, dass alle aufgeführten Probleme auf allen betroffenen Seiten behoben sind. Eine Teilbereinigung führt nicht zu einer teilweisen Aufhebung der Warnung.

Was nach der Bereinigung kommt

Nach der Bereinigung geht es darum, die Ursache zu finden und zu schließen, und bei einer Google-Warnung, den Eintrag aufheben zu lassen. In den ausgewerteten Quellen findet sich keine einzelne verbindliche Checkliste für alle Maßnahmen nach der Bereinigung, weder von WordPress noch von Wordfence. Die folgende Reihenfolge ist deshalb eine Empfehlung, keine Vorgabe.

Das Einfallstor schließen

Solange Sie nicht wissen, wie der Angreifer hereinkam, ist ein Rückfall wahrscheinlich. Google, WordPress und Wordfence nennen übereinstimmend wenige typische Wege. Der Wordfence-Threat-Report bezieht sich auf Daten aus dem Jahr 2020, die Aussagen sind also nicht tagesaktuell.

Einfallstor	Quelle	Maßnahme nach der Bereinigung
Brute-Force-Angriffe auf den Login		Einzigartige starke Passwörter, nicht benötigte Konten löschen
Ausgenutzte Sicherheitslücken in WordPress, Plugins, Themes		Updates zeitnah einspielen, ungenutzte Plugins und Themes entfernen
Verzeichnisse mit zu weitreichenden Berechtigungen		Berechtigungen prüfen und so eng wie möglich setzen
Kompromittierte Drittanbieter-Plugins		Plugins nur aus vertrauenswürdigen Quellen beziehen
Raubkopierte („nulled“) Plugins und Themes	(Daten von 2020)	Keine Premium-Produkte aus inoffiziellen Quellen verwenden

Dazu empfiehlt es sich, Backups getrennt vom Webserver aufzubewahren und regelmäßig zu scannen. Auch die Core-Checksum-Prüfung lässt sich regelmäßig wiederholen. Lässt sich das Einfallstor nicht eindeutig bestimmen, behandeln Sie alle Zeilen der Tabelle als möglich.

Google-Warnung aufheben lassen

Google beschreibt für gehackte Websites die Abfolge: Problem feststellen, Website bereinigen, Sicherheitslücke beheben, Website absichern und anschließend eine Überprüfung beantragen. Öffnen Sie in der Search Console den Bericht Sicherheitsprobleme, prüfen Sie die dort beschriebenen Bereiche und beheben Sie die Ursache auf der gesamten Website. Wählen Sie danach Überprüfung beantragen.

In der Anfrage beschreiben Sie die konkrete Ursache, die durchgeführten Bereinigungsmaßnahmen und das Ergebnis. Google nennt für Malware-Prüfungen einige Tage, für gehackte Spam-Seiten gegebenenfalls mehrere Wochen. Das sind unterschiedliche Prüfarten, kein Widerspruch.

Verwechseln Sie den Bericht nicht mit Manuelle Maßnahmen. Dieser betrifft überwiegend Verstöße gegen Suchrichtlinien und ist nicht mit einer Malware-Warnung gleichzusetzen.

Häufige Fragen

Reicht ein Scanner, oder muss ich WordPress neu einspielen?

Ein Scanner findet Auffälligkeiten, garantiert aber keine vollständige Bereinigung. Ich spiele WordPress und Plugins deshalb frisch ein und lösche die alten Plugin-Verzeichnisse, statt einzelne Dateien zu reparieren. Der Scanner bleibt als Kontrolle sinnvoll, vor allem für die Datenbank, in der Schadcode ebenfalls liegen kann. Beachten Sie, dass Funde auch Fehlalarme sein können, etwa bei Backup-Plugins mit Wiederherstellungs-Installern.

Kann ich einfach ein Backup zurückspielen?

Nur wenn Sie sicher wissen, dass das Backup vor dem Befall entstand, und die Lücke danach geschlossen ist. Andernfalls spielen Sie den Schadcode oder das offene Einfallstor gleich mit zurück. Ein Backup ist kein Ersatz für die Ursachenklärung. Aktualisieren Sie nach dem Zurückspielen alles, tauschen Sie die Zugangsdaten und prüfen Sie Dateien und Datenbank wie in den Schritten oben.

Reicht wp core verify-checksums zur Prüfung?

Nein. Der Befehl vergleicht WordPress-Core-Dateien mit den offiziellen Checksums der geprüften Version und macht veränderte, fehlende oder zusätzliche Core-Dateien sichtbar. Plugins, Themes, Uploads, Datenbankinhalte und Serverkonfiguration prüft er nicht automatisch. Nutzen Sie ihn als einen Baustein, zusammen mit der Prüfung von Berechtigungen, .htaccess-Dateien, Plugins und Datenbank.

Wie lange dauert die Überprüfung durch Google?

Google nennt für Malware-Prüfungen typischerweise einige Tage. Bei bestimmten gehackten Spam-Seiten kann es mehrere Wochen dauern. Beantragen Sie die Überprüfung erst, wenn alle Sicherheitsprobleme auf allen betroffenen Seiten behoben sind. Ein zu früher Antrag kostet Zeit, weil die Warnung bei verbliebenen Problemen bestehen bleibt.

Was ist der Unterschied zwischen Sicherheitsproblemen und manuellen Maßnahmen?

Der Bericht Sicherheitsprobleme betrifft gehackte oder potenziell schädliche Inhalte. Der Bericht Manuelle Maßnahmen betrifft überwiegend Verstöße gegen die Richtlinien der Google-Suche und ist nicht mit einer Malware-Warnung gleichzusetzen. Prüfen Sie daher beide Berichte getrennt und beantragen Sie die Überprüfung im jeweils passenden Bericht.