IT-Sicherheit

Website gehackt: was jetzt in welcher Reihenfolge zu tun ist

Eine gehackte Website ist ein Notfall, aber selten einer, der Hektik verträgt. Woran Sie den Angriff erkennen, welche Schritte in welcher Reihenfolge folgen und wann die 72-Stunden-Frist der DSGVO läuft.

8 Min. Lesezeit
Redaktionell geprüft von Alexander Seidlertwentyonepixels
Kleines Sprossenfenster mit zerbrochener Scheibe in einer dunklen Wand, dahinter eine grüne Wiese
Symbolfoto · Foto: Vladimir Srajber / Pexels

Website gehackt: die ersten drei Schritte

Wenn Ihre Website gehackt wurde, nehmen Sie sie zuerst vom Netz, sichern dann die Protokolle und ändern erst danach Passwörter. Diese Reihenfolge empfiehlt auch das Bundesamt für Sicherheit in der Informationstechnik in seiner Erste-Hilfe-Anleitung für kompromittierte Webseiten: Ruhe bewahren, die Seite offline nehmen und durch eine statische Informationsseite ersetzen, die Logdateien des Webservers und gegebenenfalls der Datenbank sichern.

Der häufigste Fehler in den ersten Minuten ist gut gemeint: Man löscht verdächtige Dateien, spielt sofort ein Backup ein und ist erleichtert, wenn die Startseite wieder normal aussieht. Damit sind aber genau die Spuren weg, die zeigen, wie der Angreifer hineingekommen ist. Die Lücke bleibt offen, und der nächste Einbruch folgt oft innerhalb weniger Tage über denselben Weg.

Offline nehmen heißt dabei nicht, die Domain abzuschalten. Ein Wartungshinweis mit Kontaktmöglichkeit genügt. So erreichen Kunden Sie weiterhin, während Besucher keine manipulierten Inhalte mehr ausgeliefert bekommen.

Woran Sie erkennen, dass Ihre Website gehackt wurde

Eine gehackte Website erkennen Sie meist nicht an der Startseite, sondern an Nebenwirkungen: einer Warnung im Browser, fremden Seiten in den Google-Ergebnissen, plötzlichen Weiterleitungen auf dem Smartphone oder einer Mail Ihres Hosters über ungewöhnlichen Datenverkehr. Ein offensichtliches Defacement, bei dem die Startseite sichtbar überschrieben wird, ist heute die Ausnahme.

Kriminell motivierte Angreifer wollen nicht auffallen. Sie hängen Spam-Seiten in Unterverzeichnisse, die im Menü nie auftauchen, oder liefern manipulierte Inhalte nur an bestimmte Besucher aus – etwa an Suchmaschinen-Crawler oder an Besucher, die über Google kommen. Wer die eigene Seite direkt aufruft, sieht dann nichts Verdächtiges.

Ein schneller Test ist die Google-Suche nach site:ihre-domain.de. Erscheinen dort Titel in fremden Sprachen, Arzneimittel-, Glücksspiel- oder Markenwaren-Angebote, die Sie nie veröffentlicht haben, ist die Seite mit hoher Wahrscheinlichkeit kompromittiert. Die zweite Anlaufstelle ist der Bericht „Sicherheitsprobleme" in der Google Search Console.

Eingeschleuste Spam-Links und versteckte Seiten

Eingeschleuste Spam-Links sind die häufigste Form des Website-Hacks, weil sie dem Angreifer direkt Geld bringen: Er leiht sich das Vertrauen Ihrer Domain, um fremde Shops in den Suchergebnissen nach oben zu schieben. Google beschreibt mehrere typische Muster, darunter den sogenannten Japanese-Keyword-Hack mit automatisch erzeugten Seiten in japanischer Sprache und den Gibberish-Hack mit sinnlosen, keywordgefüllten Texten.

Besonders tückisch ist das Cloaking: Der Schadcode prüft, wer anfragt, und zeigt den Spam nur dem Suchmaschinen-Crawler. Sie sehen eine saubere Seite, Google sieht eine Linkschleuder. Das erklärt, warum betroffene Betreiber oft erst über einen Rankingverlust oder einen Hinweis in der Search Console von dem Angriff erfahren.

Die Bereinigung beschränkt sich deshalb nicht auf sichtbare Dateien. Manipulationen stecken häufig in der Datenbank, in der .htaccess-Datei, in Theme-Dateien oder in eigens angelegten Administratorkonten, die nach dem Löschen der Spam-Seiten weiterbestehen.

Warum das Backup erst nach der Ursachenklärung kommt

Ein Backup gehört erst eingespielt, wenn bekannt ist, wie der Angreifer hineingekommen ist, und diese Lücke geschlossen ist. Ein Backup stellt den Zustand vor dem Angriff wieder her – und damit auch die Schwachstelle, die den Angriff ermöglicht hat. Das BSI verlangt ausdrücklich, dass das System vor der erneuten Onlineschaltung auf dem aktuellen Stand ist.

Dazu kommt eine Frage, die in der Hektik gern untergeht: Welches Backup ist überhaupt sauber? Angreifer sind nicht selten Wochen vor dem sichtbaren Schaden im System. Das letzte Backup kann deshalb bereits die Hintertür enthalten. Hilfreich ist ein Abgleich der Dateien zwischen Backup und aktuellem Stand; veränderte und neu hinzugekommene Dateien zeigen, wo gesucht werden muss.

Gibt es kein Backup, raten wir davon ab, auf dem kompromittierten Server weiterzuarbeiten. Die Inhalte werden gesichert, geprüft und auf einer frisch aufgesetzten Umgebung neu eingespielt. Das ist mühsamer als Flicken, aber der einzige Weg, bei dem man hinterher sagen kann, was auf dem Server liegt.

WordPress gehackt: was dort anders ist

Bei einer gehackten WordPress-Website liegt die Ursache meist in einem veralteten Plugin oder Theme, seltener im WordPress-Kern selbst. Das BSI nennt veraltete Content-Management-Systeme und Erweiterungen als einen der zwei Hauptwege, über die Angreifer Zugriff erlangen; der zweite sind erratene oder abgegriffene Zugangsdaten.

Die Verbreitung macht WordPress zum Ziel automatisierter Angriffe. Wie systematisch diese laufen, sehen wir an unserer eigenen Website: In den Zugriffsprotokollen von twentyonepixels.de tauchen laufend automatisierte Abrufe von /wp-login.php und /.git/config auf, obwohl die Seite gar nicht mit WordPress gebaut ist. Niemand hat sich die Seite gezielt ausgesucht – Skripte probieren schlicht jede erreichbare Adresse durch.

Praktisch heißt das für die Bereinigung: Kern, Themes und Plugins aus der offiziellen Quelle neu installieren statt vorhandene Dateien zu reparieren, alle Administratorkonten in der Datenbank prüfen, unbekannte Konten entfernen und nicht genutzte Plugins löschen statt nur deaktivieren. Ein deaktiviertes Plugin liegt weiterhin auf dem Server und kann weiterhin angegriffen werden.

Website gehackt und DSGVO: wann die 72-Stunden-Frist gilt

Eine Meldung an die Datenschutz-Aufsichtsbehörde ist Pflicht, wenn beim Hack personenbezogene Daten betroffen sein können und daraus ein Risiko für die Betroffenen folgt. Artikel 33 DSGVO verlangt die Meldung unverzüglich und möglichst binnen 72 Stunden, nachdem die Verletzung bekannt wurde. Die Frist läuft ab Kenntnis, nicht ab dem Ende der Aufklärung.

Personenbezogene Daten liegen auf mehr Websites, als Betreiber vermuten: Kontaktformular-Einsendungen in der Datenbank, Kundenkonten im Shop, Bewerbungen, Newsletter-Listen. Wurde nur eine statische Seite ohne Formulardaten verunstaltet, entfällt die Meldepflicht in der Regel. Dokumentiert werden muss der Vorfall nach Artikel 33 Absatz 5 trotzdem – auch dann, wenn keine Meldung erfolgt.

Besteht voraussichtlich ein hohes Risiko, etwa weil Passwörter oder Zahlungsdaten abgeflossen sein können, sind nach Artikel 34 zusätzlich die Betroffenen selbst zu informieren. Darauf weist auch das BSI in seiner Anleitung hin. Die Meldung an die Behörde darf unvollständig sein und nachgereicht werden; versäumt werden darf sie nicht.

Die Google-Warnung entfernen: Überprüfung in der Search Console

Eine Google-Warnung zu einer gehackten Website verschwindet erst, wenn Sie nach der Bereinigung in der Search Console eine Überprüfung anfordern und Google die Seite als sauber bewertet. Der Bericht „Sicherheitsprobleme" unterscheidet gehackte Inhalte, Malware und unerwünschte Software sowie Social Engineering und nennt teilweise betroffene Beispiel-URLs.

Laut Googles eigener Hilfeseite dauern die meisten erneuten Überprüfungen mehrere Tage oder Wochen. Der Antrag sollte beschreiben, was das Problem war, was dagegen unternommen wurde und woran sich der Erfolg zeigt. Mehrfaches Absenden vor einer Entscheidung beschleunigt nichts, sondern verlängert die Bearbeitung.

Eine Überprüfung lohnt sich deshalb erst, wenn die Ursache wirklich behoben ist. Wird eine Seite nach der Freigabe erneut kompromittiert, wird die nächste Prüfung nicht leichter.

Was danach verhindert, dass es wieder passiert

Der wirksamste Schutz gegen den nächsten Hack sind regelmäßige Updates, Zwei-Faktor-Anmeldung für alle Administratorzugänge und Backups, die außerhalb des Servers liegen und deren Wiederherstellung tatsächlich getestet wurde. Diese drei Punkte decken die beiden Einfallswege ab, die das BSI als typisch beschreibt: veraltete Software und kompromittierte Zugangsdaten.

Ein oft übersehener Schritt betrifft die Rechner der Administratoren. Das BSI empfiehlt, sie vor der nächsten Anmeldung auf Schadsoftware zu prüfen. Stammen die Zugangsdaten von einem infizierten Büro-PC, liest der Angreifer das neue Passwort genauso mit wie das alte.

Zur Grenze der Sache gehört auch: Keine Maßnahme macht eine Website unangreifbar. Ziel ist, dass ein Angriff schnell bemerkt wird, wenig anrichtet und in Stunden statt Wochen behoben ist. Ein Sicherheitsaudit zeigt, wo eine bestehende Anwendung heute steht; eine laufende Wartung sorgt dafür, dass sie dort bleibt.

Rechtsgrundlagen

Häufige Fragen

Nehmen Sie die Seite offline und ersetzen Sie sie durch einen Wartungshinweis, sichern Sie anschließend die Server- und Datenbank-Protokolle und ändern Sie danach alle Zugangsdaten. Diese Reihenfolge empfiehlt auch das BSI. Spielen Sie nicht sofort ein Backup ein, denn damit gehen die Spuren verloren, die zeigen, wie der Angreifer eingedrungen ist.

Ja, wenn personenbezogene Daten betroffen sein können und daraus ein Risiko für die betroffenen Personen entsteht. Die Meldung muss nach Artikel 33 DSGVO unverzüglich und möglichst binnen 72 Stunden nach Kenntnis erfolgen. Typische Fälle sind gespeicherte Kontaktanfragen, Kundenkonten oder Bewerbungen. Auch ohne Meldepflicht muss der Vorfall intern dokumentiert werden.

Nach Angaben von Google dauern die meisten erneuten Überprüfungen mehrere Tage oder Wochen. Die Überprüfung wird im Bericht „Sicherheitsprobleme" der Google Search Console angefordert, nachdem die Website vollständig bereinigt ist. Mehrere Anträge hintereinander verlängern die Bearbeitung, statt sie zu beschleunigen.

Viele Hacks arbeiten mit Cloaking: Der eingeschleuste Code zeigt den Spam nur Suchmaschinen-Crawlern oder Besuchern, die über eine Suchmaschine kommen. Wer die Seite direkt aufruft, sieht den normalen Inhalt. Eine Google-Suche mit site:ihre-domain.de und der Bericht „Sicherheitsprobleme" in der Search Console zeigen, was Google tatsächlich sieht.

Nein, nicht ohne vorherige Ursachenklärung. Ein Backup stellt auch die Sicherheitslücke wieder her, über die der Angriff gelaufen ist, und kann bereits manipulierte Dateien enthalten, wenn der Angreifer schon länger im System war. Erst wenn die Lücke gefunden und geschlossen ist, sollte ein geprüftes Backup auf eine aktualisierte Umgebung eingespielt werden.