Wenn Ihre Firmenwebsite gehackt wurde, zählt zuerst die Reihenfolge: Seite in den Wartungsmodus versetzen oder offline nehmen, alle Zugangsdaten ändern, mit einem sauberen Backup oder einer manuellen Bereinigung die Ursache schließen, danach bei Google die Sicherheitswarnung zurücksetzen lassen und prüfen, ob eine Meldung an die Datenschutz-Aufsichtsbehörde nötig ist. Wer diese Schritte in der falschen Reihenfolge angeht, zum Beispiel zuerst aufräumt und erst danach die Zugangsdaten ändert, riskiert eine zweite Infektion über dieselbe Lücke.
Die ersten 60 Minuten
Sobald ein Verdacht besteht, zählt Tempo vor Perfektion. Versetzen Sie die Website in den Wartungsmodus oder nehmen Sie sie komplett offline, damit Besucher nicht auf Schadcode treffen und Google nicht zusätzliche kompromittierte Seiten indexiert. Ändern Sie anschließend alle Zugangsdaten, die mit der Website zu tun haben: CMS-Login, FTP- oder SFTP-Zugang, Datenbank-Passwort und, falls dasselbe Passwort an anderer Stelle wiederverwendet wurde, auch dort. Sichern Sie zusätzlich den aktuellen, kompromittierten Stand als Kopie, bevor Sie etwas löschen. Das dient später sowohl der Fehlersuche als auch als Nachweis, sollte eine Meldung an eine Behörde nötig werden.
Prüfen Sie parallel, seit wann der Zustand besteht. Das Hosting-Protokoll oder die Google Search Console zeigen häufig ein Datum, ab dem sich ungewöhnlicher Traffic, neue Admin-Benutzer oder veränderte Dateien nachweisen lassen. Dieses Datum brauchen Sie später, um einzugrenzen, welche Formular-Einsendungen oder Kundendaten potenziell betroffen waren.
Woran Sie einen Hack sicher erkennen
Ein Einbruch zeigt sich selten mit einer offensichtlichen Meldung auf dem Bildschirm. Typische Anzeichen sind eine Warnung direkt in den Google-Suchergebnissen, etwa “Diese Website wurde eventuell gehackt”, eine E-Mail des Hosting-Anbieters wegen ungewöhnlicher Serverlast oder ausgehender Spam-Mails, unbekannte Admin-Benutzer im CMS, sowie fremde Weiterleitungen, die nur auftauchen, wenn man die Seite im Inkognito-Fenster ohne Login öffnet. Auch ein Kunde, der anruft und von einer verdächtigen Weiterleitung oder einer Warnmeldung des eigenen Virenschutzes berichtet, ist ein verlässliches Signal.
Ein einfacher Test: Öffnen Sie die eigene Domain in einem privaten Browserfenster und suchen Sie danach separat bei Google. Fremde Werbung, ein anderer Seitentitel im Browser-Tab als gewohnt oder eine automatische Weiterleitung auf eine unbekannte Domain sind eindeutige Warnsignale, auch wenn die Startseite auf den ersten Blick normal aussieht.
Bereinigung: Backup-Restore oder manuelle Reinigung
Ein nachweislich sauberes Backup von vor dem Einbruch ist in den meisten Fällen der schnellste Weg zurück online. Wichtig dabei: Das Backup muss wirklich vor dem Infektionszeitpunkt liegen, sonst spielen Sie den Schadcode einfach erneut ein. Fehlt ein brauchbares Backup, bleibt nur die manuelle Bereinigung: CMS-Kern komplett neu installieren, alle Plugins und Themes durch frische Originaldateien ersetzen, die Datenbank auf eingeschleuste Skripte oder fremde Benutzerkonten prüfen und verdächtige Dateien wie veränderte Kernfunktionen, eine manipulierte wp-config.php oder eine fremde .htaccess-Datei einzeln entfernen.
In beiden Fällen gehört das Schließen der eigentlichen Ursache zwingend dazu. Ein wiederhergestelltes Backup ohne aktualisiertes Plugin oder ohne neue Zugangsdaten ist keine Lösung, sondern eine Verzögerung: Die gleiche Lücke, über die der erste Einbruch lief, öffnet in der Regel auch den zweiten.
| Schritt | Backup-Restore | Manuelle Bereinigung |
|---|---|---|
| Voraussetzung | Sauberes Backup von vor dem Hack vorhanden | Kein brauchbares Backup vorhanden |
| Typischer Zeitaufwand | Wenige Stunden | Ein bis mehrere Tage |
| Risiko | Erneute Infektion bei zu jungem Backup | Übersehene Schadcode-Reste |
| Zwingend danach | Ursache schließen, Zugangsdaten erneuern | Ursache schließen, Zugangsdaten erneuern |
Google Search Console: Sicherheitsproblem melden und Review beantragen
Zeigt Google eine Sicherheitswarnung an, reicht die technische Bereinigung allein nicht aus, um sie zu entfernen. Öffnen Sie in der Google Search Console den Bericht “Sicherheitsprobleme” und stellen Sie dort nach abgeschlossener Bereinigung einen Antrag auf erneute Überprüfung. Beschreiben Sie darin möglichst konkret, was Sie getan haben, etwa welche Dateien entfernt und welche Lücke geschlossen wurde, eine detaillierte Beschreibung beschleunigt die Bearbeitung. Nach Angaben von Google kann die Prüfung je nach Umfang und Art des Vorfalls einige Tage bis mehrere Wochen dauern. Stellt Google fest, dass die Seite sauber ist, verschwinden Warnhinweise in Browsern und Suchergebnissen üblicherweise innerhalb weniger Tage nach der Bestätigung. Ein unvollständig bereinigter Antrag wird abgelehnt und verlängert den gesamten Vorgang, ein zweiter Anlauf lohnt sich deshalb erst nach einer gründlichen zweiten Prüfung der eigenen Bereinigung.
Wann eine Meldung an die Datenschutz-Aufsichtsbehörde nötig wird
Sind über ein Kontaktformular, eine Kundendatenbank oder ein Login-System personenbezogene Daten betroffen gewesen oder könnten betroffen gewesen sein, greift Art. 33 DSGVO. Der Verantwortliche, also in der Regel der Betrieb selbst, muss die Verletzung unverzüglich und möglichst binnen 72 Stunden nach Kenntnisnahme der zuständigen Aufsichtsbehörde melden, außer die Verletzung führt voraussichtlich zu keinem Risiko für die Rechte und Freiheiten der Betroffenen. Diese Ausnahme wird von Aufsichtsbehörden eng ausgelegt: Bei einer gehackten Kundendatenbank mit Namen, E-Mail-Adressen oder Telefonnummern ist in der Regel von einem Risiko auszugehen, eine Meldung ist dann Pflicht. Wird die Frist überschritten, muss die verspätete Meldung eine Begründung enthalten. Dokumentieren Sie auch dann, wenn Sie am Ende zu dem Schluss kommen, dass keine Meldung nötig ist, wie Sie zu dieser Einschätzung gekommen sind.
Einen erneuten Hack verhindern
Ein bereinigter Zustand ist ein Zwischenstand, keine dauerhafte Lösung. Aktualisieren Sie CMS-Kern, Plugins, Themes und die PHP-Version regelmäßig, denn ein Großteil der Einbrüche läuft über bekannte, längst gepatchte Lücken in veralteter Software. Vergeben Sie neue, individuelle Passwörter für alle Zugänge und aktivieren Sie, wo verfügbar, eine Zwei-Faktor-Anmeldung für den Admin-Bereich. Legen Sie einen wiederkehrenden Backup-Rhythmus mit getrennter Speicherung fest und testen Sie mindestens einmal jährlich, ob sich ein Backup tatsächlich zurückspielen lässt. Statisch gebaute Websites ohne Datenbank und ohne öffentlich erreichbares Admin-Login reduzieren die Angriffsfläche von vornherein deutlich, weil es schlicht weniger Bauteile gibt, über die sich ein Zugriff erschleichen lässt.
Praxisbeispiel: Elektrobetrieb nach einem WordPress-Hack
Ein Elektrobetrieb aus dem Rheinland bemerkt an einem Montagmorgen eine Google-Warnung im Suchergebnis für die eigene Domain. Der Inhaber versetzt die Seite umgehend in den Wartungsmodus über das Hosting-Panel und ändert das WordPress-Admin-Passwort sowie das FTP-Passwort, beide waren seit der Erstellung der Seite vor drei Jahren nicht mehr geändert worden. Eine Prüfung im Hosting-Protokoll zeigt, dass ein veraltetes Kontaktformular-Plugin die Lücke war, über die vier Tage zuvor ein fremder Admin-Benutzer angelegt wurde.
Weil das letzte Backup zwei Tage vor dem ersten auffälligen Zugriff liegt, entscheidet sich der Betrieb für den Restore statt für eine manuelle Bereinigung. Nach der Wiederherstellung wird das betroffene Plugin sofort aktualisiert, alle weiteren Plugins folgen im selben Zug, und ein zusätzlicher Admin-Zugang mit Zwei-Faktor-Anmeldung ersetzt den alten Einzel-Login. Am selben Tag stellt der Betrieb in der Google Search Console einen Antrag auf erneute Überprüfung mit einer kurzen, konkreten Beschreibung der durchgeführten Schritte. Die Warnung verschwindet nach acht Tagen aus den Suchergebnissen.
Parallel prüft der Betrieb, ob über das kompromittierte Kontaktformular in den vier Tagen zwischen Einbruch und Entdeckung Kundendaten wie Namen, Telefonnummern oder Adressen eingegangen sind. Da das der Fall war, dokumentiert der Betrieb die Risikoeinschätzung und meldet den Vorfall vorsorglich der zuständigen Landesdatenschutzbehörde, innerhalb der 72-Stunden-Frist nach Art. 33 DSGVO. Der gesamte Vorfall, vom ersten Warnhinweis bis zur bereinigten und wieder vertrauenswürdigen Seite, zieht sich über etwas mehr als eine Woche, deutlich kürzer als bei einer rein manuellen Bereinigung ohne brauchbares Backup.
Der nächste Schritt
Ein Hack lässt sich nicht rückwirkend verhindern, sobald er einmal passiert ist, aber die richtige Reihenfolge entscheidet darüber, ob die Seite nach Stunden oder erst nach Wochen wieder sauber und sichtbar dasteht. Mr.Site betreut mehrere hundert Unternehmens-Websites laufend mit, inklusive Updates, Backup-Tests und Ansprechpartner im Ernstfall. Details zu diesem Modell zeigt die Seite Website-Betreuung. Wie sich ein solcher Vorfall durch laufende Wartung von vornherein vermeiden lässt, beschreibt der Artikel Risiken einer ungepflegten Website, und wie oft ein Backup wirklich nötig ist, damit im Ernstfall überhaupt ein sauberer Wiederherstellungspunkt existiert, zeigt Wie oft sollte eine Website ein Backup bekommen?.