WordPress gehackt: die ersten Stunden entscheiden

Wenn Sie das hier gerade im Ernstfall lesen: Die nächsten Stunden entscheiden weniger darüber, ob die WordPress-Website wieder läuft — das tut sie meistens —, sondern darüber, wie teuer der Vorfall wird und wie lange er nachwirkt.

Der häufigste Fehler passiert in den ersten fünf Minuten: Backup einspielen, Seite ist wieder da, aufatmen. Drei Tage später ist sie erneut infiziert, über denselben Weg — und die Spuren, die gezeigt hätten, welcher Weg das war, sind überschrieben.

Deshalb steht hier eine Reihenfolge. Sie ist wichtiger als jedes einzelne Werkzeug.

Erst feststellen: Ist es überhaupt ein Angriff?

Bevor Sie etwas abschalten, klären Sie, womit Sie es zu tun haben. Nicht jede Auffälligkeit ist ein Einbruch — und die Gegenmaßnahmen unterscheiden sich erheblich.

Typische Anzeichen eines Angriffs

• Weiterleitungen auf fremde Seiten. Oft selektiv: nur vom Smartphone, nur bei Aufruf über einen Google-Treffer, nur für Besucher, die nicht angemeldet sind. Dass es bei Ihnen funktioniert, heißt nichts.
• Unbekannte Benutzerkonten mit Administrator-Rechten in der Benutzerliste.
• Fremde Seiten in der Google-Suche. Suchen Sie site:ihre-domain.de — tauchen dort Seiten auf, die Sie nie angelegt haben, ist das ein deutliches Zeichen.
• Eine Warnung von Google direkt in den Suchergebnissen oder im Browser.
• Beschwerden über Spam von Ihrer Domain, oder E-Mails, die plötzlich nicht mehr ankommen.
• Unerklärliche Serverlast oder Hinweise Ihres Hosters.
• Geänderte Dateien, besonders index.php, .htaccess und die Theme-Dateien header.php und footer.php.

Was wie ein Hack aussieht, aber keiner ist

• Spam-Einträge über das Kontaktformular. Lästig, aber harmlos: Das Formular funktioniert genau so, wie es soll — jemand füllt es nur automatisiert aus. Das ist kein Zugriff auf Ihre Website.
• Die Browser-Warnung „Nicht sicher“ in der Adresszeile. Das ist in aller Regel ein abgelaufenes oder fehlendes SSL-Zertifikat. Ärgerlich, schnell behoben, kein Einbruch.
• Eine weiße Seite oder „Es gab einen kritischen Fehler“ direkt nach einem Update. Meist ein Plugin-Konflikt, kein Angriff.
• Ein Virenscanner auf Ihrem eigenen Rechner schlägt an. Prüfen Sie, ob er die Website meint oder eine Datei auf Ihrem Gerät.

Wenn Sie nach dieser Liste unsicher sind, behandeln Sie es vorsorglich als Angriff. Der Aufwand ist überschaubar, der umgekehrte Irrtum teuer.

Die ersten Stunden — in dieser Reihenfolge

1. Schreiben Sie auf, was Sie sehen. Was genau fällt auf, seit wann, mit Uhrzeit. Was wurde zuletzt geändert — ein Plugin installiert, ein Update eingespielt, ein Zugang vergeben? Diese Notizen sind später die halbe Ursachenforschung, und im Stress erinnert sich niemand an Details.
2. Informieren Sie Ihren Hoster. Er sieht Serverprotokolle, die Sie nicht sehen, und er muss ohnehin wissen, dass auf seinem System etwas läuft — bei geteiltem Hosting betrifft es auch andere. Viele Hoster sperren den Zugang von sich aus, wenn sie Spam-Versand bemerken; dann ist es besser, Sie waren zuerst da.
3. Nehmen Sie die Website vom Netz, solange Schadsoftware ausgeliefert werden könnte. Eine schlichte Wartungsseite ist unangenehm für ein paar Stunden. Eine Google-Warnung begleitet Sie Wochen.
4. Sichern Sie den infizierten Zustand — bevor Sie etwas ändern. Das klingt widersinnig, ist aber die ausdrückliche Empfehlung der offiziellen WordPress-Dokumentation: Legen Sie eine Kopie von Dateien und Datenbank an, so wie sie jetzt sind. Diese Kopie wird nie wieder online gehen, aber sie ist Ihre einzige Chance herauszufinden, was passiert ist. Sobald Sie bereinigen oder ein Backup einspielen, ist sie weg.
5. Prüfen Sie Ihren eigenen Rechner. Der Punkt, den fast alle überspringen. Wenn Zugangsdaten gestohlen wurden, dann oft nicht vom Server, sondern von einem infizierten Arbeitsplatz — über einen FTP-Client, der Passwörter im Klartext speichert. Ein voller Virenscan gehört deshalb zur Ursachensuche, nicht zur Kür.
6. Setzen Sie alle Zugänge zurück, von einem Gerät aus, bei dem Sie sicher sind: WordPress-Benutzer, FTP/SFTP, Datenbank, Hosting-Konto. Und löschen Sie Konten, die niemand mehr braucht, statt nur ihre Rolle herabzustufen.
7. Erneuern Sie die Sicherheitsschlüssel in der wp-config.php. Das ist der Schritt, den die meisten Anleitungen auslassen — und ohne ihn war Schritt 6 möglicherweise umsonst. Ein Passwortwechsel beendet keine laufende Sitzung: Wer bereits angemeldet ist, bleibt angemeldet. Erst wenn die acht Schlüssel und Salts in der wp-config.php durch neue ersetzt werden, werden alle Sitzungen ungültig und jeder Eindringling fliegt raus. Die offizielle WordPress-Dokumentation beschreibt das Vorgehen in ihrer FAQ zu gehackten Websites.

Erst danach beginnt das Aufräumen.

Der teuerste Fehler: sofort das Backup einspielen

Der Reflex ist verständlich. Die Website ist weg oder entstellt, es gibt eine Sicherung, also zurück auf den Stand von gestern. In den meisten Fällen macht das die Lage schlechter, aus drei Gründen.

Die Spuren sind weg. Mit dem Zurückspielen überschreiben Sie genau die Dateien und Zeitstempel, an denen sich der Einstieg hätte ablesen lassen. Danach wissen Sie nicht mehr, worauf Sie achten müssen — weder technisch noch für die Frage, ob Daten abgeflossen sind.

Die Lücke ist noch offen. War es eine Schwachstelle in einem Plugin, dann ist sie im Backup-Stand ebenfalls enthalten. Die Website ist wieder da, angreifbar wie vorher, und der Bot kommt in der nächsten Runde wieder vorbei. Oft dauert das keine Woche.

Das Backup kann selbst infiziert sein. Ein Zugriff fällt selten am selben Tag auf. Lag er drei Wochen zurück, enthalten auch drei Wochen Sicherungen bereits die Hintertür. Genau deshalb ist die Aufbewahrungsdauer so wichtig: Mit sieben Tagen Historie haben Sie in diesem Fall gar keinen nachweislich sauberen Stand mehr.

Die richtige Reihenfolge lautet: verstehen, schließen, dann wiederherstellen. Ein Backup ist das Mittel, mit dem Sie den Betrieb wieder aufnehmen — nicht das Mittel, mit dem Sie den Vorfall lösen.

Und eine Warnung zu Hintertüren: Sie sitzen nicht immer in den Programmdateien. Angreifer legen sie gern als zusätzliches Administrator-Konto an, als Eintrag in der Datenbank oder als unscheinbare PHP-Datei im Upload-Ordner zwischen Ihren Bildern. Ein Core-Update allein entfernt davon nichts.

Die 72-Stunden-Frage

Parallel zur Technik läuft eine Frist, die viele übersehen, weil sie an den Vorfall nicht als Datenschutzthema denken.

Art. 33 DSGVO verlangt: Bei einer Verletzung des Schutzes personenbezogener Daten meldet der Verantwortliche diese der zuständigen Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde. Ausgenommen sind Fälle, in denen die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Lässt sich die Frist nicht einhalten, ist die Verzögerung zu begründen.

Zwei Punkte daran sind praktisch wichtig.

Die Uhr läuft ab Kenntnis, nicht ab dem Einbruch. Wer seine Website nicht überwacht, erlangt Kenntnis spät — was die Frist nicht verlängert, sondern nur die Zeit verkürzt, die danach zum Aufklären bleibt.

Personenbezogene Daten sind schneller betroffen, als man denkt. Eine Website, die „nichts speichert“, hat trotzdem meist: Einträge aus dem Kontaktformular, eine Newsletter-Liste, Kommentare, Benutzerkonten — und Serverprotokolle mit IP-Adressen.

Die eigentliche Schwierigkeit ist nicht die Meldung, sondern ihre Grundlage. Um zu beurteilen, ob ein Risiko besteht, müssen Sie wissen, seit wann der Zugriff bestand und worauf er reichte. Ohne Serverprotokolle und ohne eine Backup-Historie, die weit genug zurückreicht, ist diese Frage schlicht nicht zu beantworten — und dann steht am Ende eine Meldung, in der „Umfang unbekannt“ steht.

Das ist der unangenehme Rückschluss dieses Artikels: Ob dieser Abschnitt für Sie bearbeitbar ist, entscheidet sich Wochen vor dem Vorfall.

Hinweis: Wir sind keine Rechtsanwälte und leisten keine Rechtsberatung. Wir beschreiben die technische Seite. Ob und wie in Ihrem Fall zu melden ist, klären Sie mit einem Anwalt oder Ihrem Datenschutzbeauftragten — und zwar früh, nicht am dritten Tag.

Bereinigen — und prüfen, ob es gereicht hat

Was Sie selbst machen können

Das Grundprinzip: ersetzen statt reparieren. Infizierte Dateien einzeln zu säubern ist Arbeit für Spezialisten. Alles, was sich aus einer sauberen Quelle neu beziehen lässt, wird neu bezogen.

• WordPress-Kern austauschen. Die Verzeichnisse /wp-admin und /wp-includes lassen sich gefahrlos durch frische Kopien der passenden WordPress-Version ersetzen — per SFTP, nicht über die Update-Funktion im Backend, die bei einer kompromittierten Installation nicht vertrauenswürdig ist.
• Themes und Plugins neu installieren, nicht bereinigen. Vorher löschen, dann frisch aus der Originalquelle einspielen. Was Sie ohnehin nicht brauchen, installieren Sie gar nicht erst wieder.
• .htaccess prüfen. Laut der offiziellen WordPress-Dokumentation die Datei, die bei Angriffen am häufigsten manipuliert wird — dort sitzen die Weiterleitungen.
• Den Upload-Ordner nach PHP-Dateien durchsuchen. In /wp-content/uploads/ gehören Bilder und Dokumente. Eine .php-Datei zwischen den Urlaubsfotos von 2023 ist immer falsch.
• Die Benutzerliste aufräumen und unbekannte Konten löschen, nicht herabstufen.
• Erst wenn alles sauber ist: Passwörter ein zweites Mal ändern. Die erste Änderung geschah, während der Angreifer möglicherweise noch Zugriff hatte. Auch das steht so in der WordPress-Dokumentation.

Woran Sie erkennen, dass es sauber ist

Ein einzelner Test genügt nicht. Drei Blickwinkel zusammen geben ein brauchbares Bild:

1. Von außen scannen. Externe Dienste rufen Ihre Website so auf, wie ein Besucher es tut, und sehen damit auch, was nur bestimmten Besuchern ausgeliefert wird. Welche dafür in Frage kommen, listet die WordPress-Dokumentation.
2. site:ihre-domain.de bei Google suchen. Sind die fremden Seiten verschwunden? Das dauert ein paar Tage, aber die Richtung muss stimmen.
3. Search Console öffnen, Bereich Sicherheitsprobleme. Solange dort etwas steht, ist die Sache für Google nicht erledigt.

Und die ehrliche Einschränkung: Dass kein Scanner etwas findet, ist kein Beweis für Sauberkeit — nur ein Hinweis. Beobachten Sie die Website in den Tagen danach, und achten Sie besonders auf neue Benutzerkonten und geänderte Dateien.

Wann Sie aufhören und jemanden holen sollten

Es gibt einen Punkt, an dem Weitermachen teurer wird als Abgeben. Diese Anzeichen sprechen dafür:

• Die Website ist nach dem Bereinigen erneut infiziert. Dann ist der eigentliche Einstieg noch offen, und weiteres Suchen auf gut Glück kostet nur Zeit.
• Es gibt Veränderungen in der Datenbank, nicht nur in Dateien.
• Sie haben keine Backup-Historie, die weit genug zurückreicht.
• Sie können die Frage aus dem vorigen Abschnitt — seit wann und worauf reichte der Zugriff — nicht beantworten.
• Der Hoster meldet, dass weitere Websites auf demselben Konto betroffen sind.

Danach: der Teil, der am längsten nachwirkt

Die Website ist sauber und wieder online. Damit ist der technische Vorfall beendet — die Folgen nach außen sind es nicht.

Die Google-Warnung aufheben lassen

Wurde die Domain als schädlich markiert, verschwindet die Warnung nicht automatisch, wenn Sie bereinigt haben. Sie müssen in der Search Console unter Sicherheitsprobleme eine Überprüfung beantragen und dabei beschreiben, was Sie konkret behoben haben.

Google nennt dafür eine Dauer, die man kennen sollte, bevor man sie dem Geschäftsführer erklären muss: „A review can take from a few days to a few weeks to complete.” (Search Console-Hilfe) In dieser Zeit sehen Besucher weiterhin die Warnung.

Zwei Dinge dabei: Beantragen Sie die Prüfung erst, wenn die Website wirklich sauber ist — Google weist ausdrücklich darauf hin, dass ein verfrühter Antrag die Bearbeitung des nächsten verlängert. Und reichen Sie nicht nach, solange eine Prüfung läuft.

Blacklists und E-Mail-Zustellbarkeit prüfen

Wurde über Ihren Server Spam versendet, steht Ihre Domain oder die Server-IP auf Sperrlisten der E-Mail-Anbieter. Die Folge merken Sie an einer unerwarteten Stelle: Nicht nur der Spam kommt nicht mehr an, sondern auch Ihr Angebot an den Kunden, der gestern angefragt hat.

Testen Sie den Versand an mehrere Anbieter — ein eigenes Postfach bei einem großen Freemail-Dienst genügt — und sprechen Sie mit Ihrem Hoster über die Austragung. Bei einer geteilten Server-IP liegt das ohnehin bei ihm.

Die Ursache festhalten

Solange nicht feststeht, über welchen Weg der Zugriff erfolgte, ist der Vorfall nicht abgeschlossen, sondern nur unterbrochen. Halten Sie schriftlich fest, was Sie gefunden haben, was Sie geändert haben und was offengeblieben ist. Beim nächsten Mal — oder für denjenigen, der die Website später übernimmt — ist das die wertvollste Datei im ganzen Projekt.

Damit es nicht wieder passiert

Wer einmal durch diesen Ablauf gegangen ist, stellt meistens dieselbe Frage: Was hätte das verhindert?

In den seltensten Fällen eine bessere Abwehr. Fast immer eine kürzere Reaktionszeit — weniger Abstand zwischen bekannter Lücke und eingespieltem Update, und jemand, der merkt, dass etwas passiert, bevor ein Kunde anruft. Warum das so ist und welche fünf Maßnahmen tatsächlich etwas ändern, haben wir in einem eigenen Artikel aufgeschrieben: WordPress-Sicherheit.

Zwei Punkte aus diesem Artikel hier wirken dabei direkt nach:

• Überwachung verkürzt die Zeit bis zur Kenntnis. Und davon hängt nicht nur der Schaden ab, sondern auch, wie viel von den 72 Stunden zum Aufklären übrig bleibt.
• Backup-Historie entscheidet, ob Sie einen sauberen Stand haben. 30 oder 50 Tage statt sieben sind kein Komfortmerkmal, sondern genau der Unterschied, der im Ernstfall zählt.

Was wir anbieten — und was nicht

Damit hier keine falsche Erwartung entsteht: Wir sind kein Notdienst. Es gibt bei uns keine Hotline rund um die Uhr. Unsere Servicezeiten sind Montag bis Freitag von 9 bis 18 Uhr, die zugesagte Reaktionszeit liegt bei einem Werktag — im Premium-Paket bei vier Stunden. Wenn Ihre Website gerade jetzt Schadsoftware ausliefert, ist Ihr Hoster der schnellere Weg, nicht wir.

Was wir übernehmen, ist die Zeit davor und danach:

• Laufende Betreuung mit wöchentlichen Updates, Schwachstellen-Überwachung, Backups mit echter Historie und 24/7-Monitoring — ab 190 € im Monat, netto zzgl. MwSt. Der vollständige Vergleich steht auf Pakete & Preise.
• Einmalige Absicherung einer bestehenden Website, wenn Sie keine laufende Betreuung möchten: Sicherheit & DSGVO ab 390 €, zu finden unter Leistungen.

Und wenn Sie erst einmal nur wissen möchten, wie Ihre Website dasteht: Unser kostenloser Website-Check prüft sechs Bereiche und kommt als PDF innerhalb von 48 Stunden — ohne Telefonat, ohne Verkaufsgespräch, ohne Zugangsdaten. Für einen akuten Vorfall ist er das falsche Werkzeug; für die Bestandsaufnahme danach genau das richtige.

Schreiben Sie uns über das Kontaktformular oder rufen Sie an: +49 157 54071854. Wenn wir nicht die Richtigen sind, sagen wir Ihnen das — das ist in diesem Fall schneller für Sie.

Häufige Fragen

Reicht es nicht, einfach das Passwort zu ändern?

Nein. Ein Passwortwechsel beendet keine laufende Sitzung — wer bereits angemeldet ist, bleibt es. Erst das Erneuern der Sicherheitsschlüssel in der wp-config.php macht alle Sitzungen ungültig. Ohne diesen Schritt kann der Angreifer das neue Passwort in aller Ruhe mitlesen oder sich ein weiteres Konto anlegen.

Kann ich nicht einfach ein Backup von vorgestern einspielen?

Das stellt den Betrieb wieder her, löst aber den Vorfall nicht — und kann ihn verschlimmern: Die Spuren sind danach überschrieben, die Schwachstelle ist im Backup-Stand enthalten, und wenn der Zugriff schon länger bestand, ist die Hintertür dort ebenfalls mit gesichert. Erst verstehen und schließen, dann wiederherstellen.

Wie lange dauert es, bis die Google-Warnung verschwindet?

Google gibt an, dass eine Überprüfung „from a few days to a few weeks“ dauern kann. Sie startet nicht automatisch: Sie müssen sie in der Search Console beantragen, nachdem die Website sauber ist.

Muss ich einen Hack melden?

Das hängt davon ab, ob personenbezogene Daten betroffen sind und ob daraus voraussichtlich ein Risiko für die Betroffenen entsteht. Die Frist aus Art. 33 DSGVO beträgt möglichst 72 Stunden ab Kenntnis. Die Einschätzung selbst ist eine rechtliche Frage — klären Sie sie mit einem Anwalt oder Ihrem Datenschutzbeauftragten, und beginnen Sie damit am ersten Tag, nicht am dritten.

Kann mein Hoster die Website für mich bereinigen?

Manche bieten das als kostenpflichtige Leistung an, andere nicht — fragen Sie direkt. Unabhängig davon ist der Hoster immer die erste Adresse: Er sieht Protokolle, die Ihnen nicht zugänglich sind, und bei geteiltem Hosting muss er ohnehin prüfen, ob weitere Konten betroffen sind.

Die Website läuft wieder — ist die Sache damit erledigt?

Nicht ganz. Offen bleiben in der Regel drei Dinge: die Google-Warnung, die gesondert aufgehoben werden muss; mögliche Einträge auf E-Mail-Sperrlisten; und die Frage nach der Ursache. Solange nicht feststeht, wie der Zugriff erfolgte, ist der Vorfall nur unterbrochen.

Quellen

• WordPress.org: FAQ – My site was hacked — offizielle Schritt-für-Schritt-Anleitung: Vorfall dokumentieren, eigenen Rechner prüfen, Hoster informieren, Zugänge und Sicherheitsschlüssel erneuern, Kopie des infizierten Zustands anlegen, /wp-admin und /wp-includes ersetzen, .htaccess prüfen, Passwörter nach der Bereinigung erneut ändern.
• Google Search Console-Hilfe: Bericht zu Sicherheitsproblemen — Überprüfung beantragen nach der Bereinigung; „A review can take from a few days to a few weeks to complete.“
• Art. 33 DSGVO — Meldung von Verletzungen des Schutzes personenbezogener Daten an die Aufsichtsbehörde — Meldung unverzüglich und möglichst binnen 72 Stunden ab Kenntnis, außer wenn voraussichtlich kein Risiko für die Rechte und Freiheiten natürlicher Personen entsteht.
• BSI: Prävention und Erste Hilfe bei Webseiten-Kompromittierung oder Defacement — Handreichung des Bundesamts für Sicherheit in der Informationstechnik.