Wie ich eine gehackte Website wieder sauber bekomme

Der Anruf kommt meistens so: Google zeigt eine Warnung, oder der Hoster hat die Seite abgeschaltet, oder ein Kunde meldet, dass er auf eine fremde Seite umgeleitet wurde.

Der erste Reflex ist verständlich: aufräumen, damit die Seite wieder läuft. Genau damit fange ich nicht an.

Zuerst verstehen, dann putzen

Wer sofort löscht, was verdächtig aussieht, verliert die Spur — und übersieht fast immer etwas. Angreifer legen mehrere Wege ins System, damit genau dieser Reflex sie nicht aussperrt. Eine Datei entfernen, die sich beim nächsten Aufruf selbst wiederherstellt, hilft niemandem.

Deshalb sichere ich zuerst den Ist-Zustand: Dateien und Datenbank, so wie sie sind. Das ist Beweismaterial und Rückversicherung zugleich — falls beim Aufräumen etwas Falsches erwischt wird, komme ich zurück.

Dann suche ich den Eintritt. Wann hat es angefangen? Die Antwort steht meistens in den Zugriffsprotokollen des Servers und in den Änderungszeitpunkten der Dateien. Ein Verzeichnis, in dem plötzlich alles denselben Zeitstempel trägt, ist ein guter Anfang.

Was ich in dieser Phase konkret ansehe

Benutzerkonten. Neu angelegte Administratoren sind das häufigste erste Zeichen. Oft mit unauffälligen Namen, oft mehrere über Tage verteilt — das zeigt, dass jemand wiederholt Zugang hatte, nicht nur einmal.

Geänderte Dateien. Vor allem an Stellen, an denen sich normalerweise nichts ändert: Kernverzeichnisse, Uploads-Ordner, Konfigurationsdateien. Ein Bilderordner, der plötzlich ausführbaren Code enthält, ist kein Zufall.

Geplante Aufgaben. Ein beliebter Trick: Der Schadcode trägt sich in die Zeitsteuerung ein und stellt sich selbst wieder her. Wer die Datei löscht, ohne die Aufgabe zu entfernen, hat das Problem am nächsten Tag zurück.

Erweiterungen, die niemand installiert hat. Manchmal getarnt als Werkzeug mit plausiblem Namen, manchmal als Kopie einer echten Erweiterung mit einer zusätzlichen Zeile.

Dann erst aufräumen — und zwar ersetzen statt reparieren

Alles, was zum Kernsystem oder zu einer Erweiterung gehört, wird ersetzt, nicht bereinigt. Ich lade die Originalversionen neu und überschreibe. Das ist schneller und sicherer, als in fremdem Code nach eingefügten Zeilen zu suchen.

Nur was individuell ist — Theme-Anpassungen, hochgeladene Dateien, die Datenbank — muss von Hand durchgesehen werden. Hier ist die Sicherung von vorhin nützlich: Ein Vergleich mit einem Stand von vor dem Vorfall zeigt Unterschiede sofort.

Danach: alle Zugänge erneuern. Administratoren, Datenbank, Server, Anwendungskennwörter. Nicht nur die, bei denen ein Missbrauch belegt ist — man weiß nie, was abgeflossen ist.

Die unbequeme Erkenntnis aus dem letzten größeren Fall

In einem Bestand, den ich betreue, war vor Kurzem ein Teil der Websites betroffen. Es wäre bequem gewesen, das auf eine unsichere Erweiterung zu schieben. Die Ursache lag woanders: eine kritische Lücke im Kern.

Und — das ist der eigentliche Punkt — die Korrektur war seit fünf Tagen verfügbar. Sie war nur nicht eingespielt worden, weil die Update-Anzeige in der Verwaltungsoberfläche ausgeblendet war und es keine Frühwarnung gab.

Der Angriff war also kein besonders raffinierter. Er war schnell. Zwischen „Lücke öffentlich bekannt” und „automatisierte Angriffe laufen” liegen heute Stunden, nicht Wochen. Wer einmal im Monat aktualisiert, hat in genau diesem Fenster keine Chance.

Daraus habe ich drei Dinge geändert: Sicherheitsrelevante Kern-Updates werden zeitnah eingespielt, nicht im Monatsrhythmus. Neue Administratorkonten lösen eine Meldung aus. Und ich verlasse mich nicht mehr darauf, dass eine Verwaltungsoberfläche mir schon anzeigt, wenn etwas offen ist — ich prüfe den Stand direkt.

Was ich nicht verspreche

Eine bereinigte Website ist nicht dieselbe wie eine, die nie betroffen war. Es bleibt ein Restrisiko, dass etwas übersehen wurde. Deshalb beobachte ich betroffene Seiten anschließend eine Zeit lang genauer.

Und: Ob Daten abgeflossen sind, lässt sich im Nachhinein oft nicht sicher beantworten. Wenn personenbezogene Daten betroffen sein könnten, ist das eine Meldefrage mit Fristen — dafür gehört jemand mit an den Tisch, der das rechtlich beurteilen kann. Ich liefere die technischen Feststellungen, nicht die Bewertung.

Wenn es Sie gerade erwischt hat

Schalten Sie die Seite offline, statt sie schnell zu reparieren. Sichern Sie den Zustand, bevor Sie etwas löschen. Und ändern Sie noch nichts an den Zugängen, bevor jemand die Protokolle gesehen hat — sonst ist die Spur weg.

Wenn Sie Unterstützung brauchen: Schreiben Sie mir. In solchen Fällen antworte ich so schnell ich kann.